Pocket Plane Group
Friends and Neighbors => Weimer Republic (WeiDU.org) => WeiDU => Topic started by: Wisp on January 13, 2013, 01:07:12 PM
-
New beta: link (http://dl.dropbox.com/u/78949477/WeiDU-Windows-23107.zip).
New since last version:
- A regression in LAUNCH_*_FUNCTION STR_VAR was fixed.
- This beta does not warn about triggers being invalid actions.
- The standard library of functions and macros should work correctly on BGEE.
- An override directory is created if none exists.
- The documentation and function of ADD_AREA_ITEM were corrected.
- WeiDU uses BG2's TLK format and scripting style for BGEE (previously, things like <CHARNAME> etc would not work).
This version should be mostly, really, hopefully functional on BGEE, save for the need to hardlink to dialog.tlk and making sure the text is correctly encoded. I will have a look at providing BGEE's location for save files etc, since it looks pretty straightforward. The new functions will hopefully also make it in, but after that I'm thinking it is time for version 232. The issues with dialog.tlk and text encoding can be circumvented fairly easily until I can provide WeiDU/other solutions.
-
I just wanted to try out the new WeiDU.exe but I got a warnung from my Kaspersky Antivirus program that it found PDM.Worm.P2P.generic and it deleted WeiDU.exe immediately from my computer.
-
Based on virustotal.com, and on WeiDU's past history with anti-virus heuristics, what you have there is a false positive from your anti-virus vendor.
-
I just wanted to try out the new WeiDU.exe but I got a warnung from my Kaspersky Antivirus program that it found PDM.Worm.P2P.generic and it deleted WeiDU.exe immediately from my computer.
Kaspersky is the problem. It is renowned for finding false positives everywhere.
PS Do you think PHP_EACH could define custom key names, instead of fixed key_[0-9]+:
PHP_EACH array AS key , index , trigger , whatever => value BEGINinstead of
PHP_EACH array AS key => value BEGIN
index = key_1
trigger = key_2
whatever = key_3It's almost aesthetic, as you can guess, so ignore this request if it requires more work than it's worth.
-
PS Do you think PHP_EACH could define custom key names, instead of fixed key_[0-9]+:
PHP_EACH array AS key , index , trigger , whatever => value BEGINinstead of
PHP_EACH array AS key => value BEGIN
index = key_1
trigger = key_2
whatever = key_3It's almost aesthetic, as you can guess, so ignore this request if it requires more work than it's worth.
It looks like it would require an alternative implementation of PHP_EACH. I can probably give it a more thorough treatment once things have quieted down.
-
I just had annother problem with this WeiDU:
Once started it begun to auto-update the existing WeiDUs, then it stuck. (Kaspersky was paused)
[K:\BGII - SvA\setup-bp-bgt-worldmap.exe] WeiDU version 23107
This is a non-stable version. Unless you're sure about what you're doing, consid
er downgrading.
{Setup-#yoshi.exe} Queried (pid = 124) version = 23106
{Setup-Yasraena.exe} Queried (pid = -1)
Oddly enough, the ReplaceWeiDU.bat included in the BWP Installpack works despite running Kaspersky.
I don't know whether the update failed with former versions of WeiDU, because I always use ReplaceWeiDU.bat.
-
By the way, it failed once for me, too, with a 201 version from weidu.org.
EDIT: I think I know why it happened for me: for some reason, I had a 20k exe file instead of Setup-EdwinRomance.exe. When Weidu tried to update this file, it obviously failed, hence the -1 thingy. When I deleted it, everything updated to v231 beautifully.
Maybe it happens once it sees a Setup-Mymod-like file which is, well, faulty.
-
Autoupdating not always working right is a problem that crops up from time to time. Judging by the code, it happens because the running WeiDU fails to create a process in which to run the WeiDU to be queried [if it needs to be updated] (this is what "pid = -1" means). I'll (eventually) see if I can maybe get WeiDU to handle failure more gracefully, or something.
-
{Setup-Yasraena.exe} Queried (pid = -1)
Erhm, the file might have the ReadOnly -flag on, which prevents the update... or it's going to take some extra time.
-
I am sure everyone would love to hear more new from your end Wisp. Not that you actually need to...
-
No recent progress. Before the dry spell I implemented a SAVE_DIRECTORY variable, which will let Miloch et al. access save files of enhanced and original versions in a platform-independent manner. I have since also decided I should get WeiDU working with BGEE's multiple TLKs. After this much time it would be silly releasing without it, or maybe it would have been silly all along.
-
It's a great idea(not that you don't know that)!
I have a perhaps silly question: as of today, all BG-EE-compatible mods are released with two Weidu.exe copies attached, be it DavidW's SCS v22-beta or BG-EE compatible XanBG1Friendship Kaeloree coded for me. It's obviously not the best decision and weighs 700kb extra. Can a new version of Weidu(maybe not the next one, but eventually) make it unnecessary?
-
I think the BGEE batch script can simply copy the setup-mod.exe into weidu.exe and then run it as usual?
-
It's a great idea(not that you don't know that)!
I have a perhaps silly question: as of today, all BG-EE-compatible mods are released with two Weidu.exe copies attached, be it DavidW's SCS v22-beta or BG-EE compatible XanBG1Friendship Kaeloree coded for me. It's obviously not the best decision and weighs 700kb extra. Can a new version of Weidu(maybe not the next one, but eventually) make it unnecessary?
In the case of SCSv22, I'm just being lazy. One version is the standard copy, one is for the auto-install program that ships with SCS. It's nothing to do with BG:EE per se. I could probably get the install file to duplicate it but I didn't want to muck around with that kind of thing at the beta-testing stage.
-
As much as I cherish the AUTO_EVAL_STRINGS flag, what happens when you explicitly do NOT want something evaluated?
Also, can we have REARRANGE_ARRAY array_name patch (and action too, perhaps), that will restructure an array into numeric and alphabetic order by its keys?
This is the third time I found myself wanting it, so I went ahead and wrote this for single-keyed typesDEFINE_PATCH_MACRO rearrange_array BEGIN
SPRINT ag#ra_max ~~
CLEAR_ARRAY ag#ra_aux
CLEAR_ARRAY ag#ra_aux2
PHP_EACH ~%rearrange_array%~ AS ag#ra_i => ag#ra_r BEGIN
SPRINT $ag#ra_aux("%ag#ra_i%") ~%ag#ra_r%~
SET $ag#ra_aux2("%ag#ra_i%") = 1
PATCH_IF (~%ag#ra_i%~ STRING_COMPARE_CASE ~%ag#ra_max%~) > 0 BEGIN
SPRINT ag#ra_max ~%ag#ra_i%~
END
END
CLEAR_ARRAY EVAL ~%rearrange_array%~
PHP_EACH ag#ra_aux AS ag#ra_i => ag#ra_r BEGIN
SPRINT ag#ra_min ~%ag#ra_max%~
PHP_EACH ag#ra_aux2 AS ag#ra_i2 => ag#ra_r2 BEGIN
PATCH_IF ((~%ag#ra_min%~ STRING_COMPARE_CASE ~%ag#ra_i2%~) > 0) && (ag#ra_r2) BEGIN
SPRINT ag#ra_min ~%ag#ra_i2%~
END
END
SPRINT $ EVAL "%rearrange_array%"("%ag#ra_min%") $ag#ra_aux("%ag#ra_min%")
SET $ag#ra_aux2("%ag#ra_min%") = 0
END
END
SPRINT rearrange_array array_name
LPM rearrange_arrayexcept an innate WeiDU command may be better, because it then would be safe from AUTO_EVAL_STRINGS. Plus I don't know how to catch properly multi-keyed arrays in the open variable environment.
-
As much as I cherish the AUTO_EVAL_STRINGS flag, what happens when you explicitly do NOT want something evaluated?
What with WeiDU's crazy evaluation scheme I am not at all sure it would be possible. I'll keep it in mind for when I have sufficiently unwound the eval code.
It should be possible to add something for sorting arrays.
-
Before the dry spell I implemented a SAVE_DIRECTORY variable, which will let Miloch et al. access save files of enhanced and original versions in a platform-independent manner. I have since also decided I should get WeiDU working with BGEE's multiple TLKs. After this much time it would be silly releasing without it, or maybe it would have been silly all along.
Along these lines, I noticed the current beta creates save and mpsave in the game folder if they don't exist. Should it not be looking for them in the SAVE_DIRECTORY or do you have to explicitly set that (i.e. there isn't a default where it can get the user's documents folder from the registry or something)?
-
Along these lines, I noticed the current beta creates save and mpsave in the game folder if they don't exist. Should it not be looking for them in the SAVE_DIRECTORY or do you have to explicitly set that (i.e. there isn't a default where it can get the user's documents folder from the registry or something)?
I'll look into it. It's probably some automatic stuff to make the dirs if they don't exist.
But I suppose we shall need an MPSAVE_DIRECTORY variable as well, and sc#wmpAre and the GAM stuff needs to be updated to use them..
-
Along these lines, I noticed the current beta creates save and mpsave in the game folder if they don't exist. Should it not be looking for them in the SAVE_DIRECTORY or do you have to explicitly set that (i.e. there isn't a default where it can get the user's documents folder from the registry or something)?
What sort of TP2 code are you running when the save and mpsave directories are created? WeiDU does not contain anything general for creating the directories. Only a few specific bits of functionality seem to do so (the aforementioned two).
-
Most likely GET_DIRECTORY_ARRAY on "save" and "mpsave" folders. IIRC sc#wmpAre does that.
-
Well, I fixed sc#addWmpAre (and COPY_ALL_GAM_FILES) last night.
-
Well, I fixed sc#addWmpAre (and COPY_ALL_GAM_FILES) last night.
As in, you fixed them to work with EE saved games? If so, can we get a new beta?
-
Along these lines, I noticed the current beta creates save and mpsave in the game folder if they don't exist. Should it not be looking for them in the SAVE_DIRECTORY or do you have to explicitly set that (i.e. there isn't a default where it can get the user's documents folder from the registry or something)?
Still an issue in v232.
-
Along these lines, I noticed the current beta creates save and mpsave in the game folder if they don't exist. Should it not be looking for them in the SAVE_DIRECTORY or do you have to explicitly set that (i.e. there isn't a default where it can get the user's documents folder from the registry or something)?
Still an issue in v232.
What sort of TP2 code are you running when the save and mpsave directories are created?
I still can't reproduce your problem. It is perhaps also worth noting that on GNU/Linux, I have defined the game dir to be the user dir (so that is where %SAVE_DIRECTORY% is) because it was easier for me that way. If it should be elsewhere (e.g., for Wine support), I need to know where that is.
-
What sort of TP2 code are you running when the save and mpsave directories are created?
Missed that earlier somehow. Just regular sc#addWmpAre usage. It creates/looks for save and mpsave in the game folder rather than in .../User/Documents/BGEE/etc on WinXP.
LAUNCH_ACTION_FUNCTION sc#addWmpAre
INT_VAR mapIcon = 29 // map icon
xCoord = 1000 // x coordinate
yCoord = 250 // y coordinate
tTime = 2 // travel time *4, so two means eight hours
inclSv = 1 // include saved games bool: 1 means yes and 0
STR_VAR areName = "AX0950" // area reference
strName = "" // area name
strDesc = "" // area description
RET areNum = areNum
END
-
Missed that earlier somehow. Just regular sc#addWmpAre usage. It creates/looks for save and mpsave in the game folder rather than in .../User/Documents/BGEE/etc on WinXP.
Unfortunately, I don't think I am able to install BGEE on my WinXP system. But there are two potential points of failure in the code: either your game is not detected as BGEE, or WeiDU reads the wrong path from the registry. Does ADD_JOURNAL work on your BGEE game? (If so, it's detected as BGEE.) Can you also confirm that the actual value of %SAVE_DIRECTORY% is incorrect (e.g., by PRINTing the value)? Are you able to navigate the Windows registry and look up the value WeiDU is using? If so, it is "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders"->"Personal" (sorry, I don't know what terminology is used when referring to the Windows registry). The value of "Personal" should be your Documents directory.