Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
WeiDU / Re: Make HANDLE_AUDIO function silent ?
« Last post by Gwendolyne_FP on October 17, 2020, 10:34:47 AM »
The issue seems to come from AT_NOW command. I solved it using this:

Code: [Select]
AT_NOW ~%oggdec_path%/oggdec.exe -Q "%BASH_FOR_FILESPEC%" 2> nul~
22
WeiDU / Re: WeiDU 247 seems to have broken Generalized Biffing installation
« Last post by Gwendolyne_FP on October 15, 2020, 03:17:44 PM »
Thanks for looking at it.

I also could not reproduce it with a vanilla ToB + ToBEx + BG2 Fixpack game.
23
WeiDU / Re: WeiDU 247 seems to have broken Generalized Biffing installation
« Last post by Wisp on October 15, 2020, 02:51:44 PM »
I am unable to reproduce this problem. Steps were: start from original games, install fixpack, install BGT (I chose not to biff), install gen_biff with 247: biff everything. The game works the same with or without gen_biff. As you have observed, none of the changes for 247 should have impacted MAKE_BIFF (which is not to say none did, and there are also changes in the compile environment).
24
WeiDU / Make HANDLE_AUDIO function silent ?
« Last post by Gwendolyne_FP on October 14, 2020, 03:16:00 PM »
 Is there a way to make it run silently, without prompting any information in WeiDU installer window?

I tried with a homemade clone function of HANDLE_AUDIO, adding -Q (then --quiet) options, but the result was the same...  ???
25
WeiDU / WeiDU 247 seems to have broken Generalized Biffing installation
« Last post by Gwendolyne_FP on October 14, 2020, 11:56:15 AM »
Hi, wisp.

Everything is said in the title and I can't find in the change-log which WeiDU 247 new feature may cause this. Could you have a look at this please ?
26
WeiDU / Re: Version 247 has been released
« Last post by Sam. on October 13, 2020, 12:04:39 AM »
This isn't new to v247, but I have a request and a question.  In one of my mods, I have the following code:
Code: [Select]
<<<<<<<< BGEEClassicMovies-inlined/AR0705.baf
IF
  Global("EnteredElfsong","GLOBAL",0)
THEN
  RESPONSE #100
    StartMovie("TAVERN")
    SetGlobal("EnteredElfsong","GLOBAL",1)
END
>>>>>>>>

EXTEND_TOP AR0705.bcs ~BGEEClassicMovies-inlined/AR0705.baf~
With the MODDER flag turned on, this gives me two warnings.

1)
Quote
WARNING: POSSIBLE ERROR: file TAVERN.mve is not found in action 167.
Presumably this warning is given because the referenced resource "TAVERN.mve" isn't found.  However, this is being installed on an EE game and "TAVERN.wbm" DOES exist.  My request is that this (very useful) check be extended to account for all possible (accounting for engine variant) file extensions for any resource in question.

2)
Quote
WARNING: EXTEND* BGEEClassicMovies-inlined/AR0705.baf with strings from setup.tra
This is warning me that I haven't specified a specific TRA to use?  No TRA is necessary.  Can I make WeiDU happy without specifying (an unused) TRA like so:
Code: [Select]
EXTEND_TOP AR0705.bcs ~BGEEClassicMovies-inlined/AR0705.baf~ USING ~BGEEClassicMovies/lang/%s/setup.tra~
27
WeiDU / Re: Allow for defining MOD_FOLDER - 'immutable' mod design without hacks
« Last post by AL|EN on October 12, 2020, 02:30:27 PM »
Regardless of what 247 fixed, I'm still getting: "SET %MOD_FOLDER% = ~weidu_external~" from SCS when I use --debug-assign in order to get MOD_FOLDER value.
That's an oddity in --debug-assign and/or your install configuration, then. If you just install SCS via the standard installer, MOD_FOLDER gets set correctly.
Well, I've checked this by launching weidu 247 two-ways:

1) Direct
$weiduPath = "C:\Users\ALIEN\Downloads\PI-Test\Tools\WeiDU\247.00\weidu.exe"
$workingDirectory = 'E:\Mods-Extracted-0\SwordCoastStratagems'
$tp2 = 'E:\Mods-Extracted-0\SwordCoastStratagems\stratagems\setup-stratagems.tp2'

SET %MOD_FOLDER% = ~E:~

2) Relative
$weiduPath = "C:\Users\ALIEN\Downloads\PI-Test\Tools\WeiDU\247.00\weidu.exe"
$workingDirectory = 'E:\Mods-Extracted-0\SwordCoastStratagems'
$tp2 = 'stratagems\setup-stratagems.tp2'

SET %MOD_FOLDER% = ~stratagems~

So it's because direct vs relative tp2 argument.

The thing is, since I'm operating on the 'extracted mods' folder, where the correct $workingDirectory (and thus tp2-relative path) cannot be provided before getting 'mod data folder' value.

@wisp, does %MOD_FOLDER% can be set correctly when '--debug-assign' is used with direct path to tp2 ?
28
WeiDU / Re: Allow for defining MOD_FOLDER - 'immutable' mod design without hacks
« Last post by DavidW on October 12, 2020, 12:10:09 PM »
Regardless of what 247 fixed, I'm still getting: "SET %MOD_FOLDER% = ~weidu_external~" from SCS when I use --debug-assign in order to get MOD_FOLDER value.
That's an oddity in --debug-assign and/or your install configuration, then. If you just install SCS via the standard installer, MOD_FOLDER gets set correctly.

Quote
The 'BACKUP' keyword is not always at the begging of the file. You need to read it and apply regex. 100+ tp2 files = 20 seconds or more of waiting time during application startup before you can do anything.
But the point stands. Whatever your parser is doing, WEIDU itself has to do that and more. Unless the code you're using is really inefficient relative to whatever WEIDU is doing, it shouldn't be able to be slower than WEIDU.
29
WeiDU / Re: Allow for defining MOD_FOLDER - 'immutable' mod design without hacks
« Last post by AL|EN on October 12, 2020, 12:01:00 PM »
some mods are using 'immutable' mod design-B with workaround. First, set the backup outside of 'mod data folder' via 'BACKUP' keyword. But it also sets MOD_FOLDER variable thi the value of it, so they need to overwrite MOD_FOLDER variable back to proper 'mod data folder'.
This is actually one of the things WEIDU v247 fixes. If you look at how MOD_FOLDER is now defined, it's equal to the folder in which the tp2 file exists if there is one; it's set from the BACKUP variable only for old mods where the tp2 file lives outside the mod folder. It's no longer necessary to set MOD_FOLDER explicitly (if you look at SCS v33.5, it doesn't do this any more.)

Regardles of what 247 fixed, I'm still getting: "SET %MOD_FOLDER% = ~weidu_external~" from SCS when I use --debug-assign in order to get MOD_FOLDER value.

Quote
No matter how fast tp2 scanning is (not possible to use something like yeld return), the reality of having to scan 100+ mods makes this approach impossible for mod manager: people put crazy things into their tp2, some tp2 are huge and there are some tp2 which aren't mods at all. Launching WeiDU and getting the keyword values is the fastest and most error-safe way.
I'm confused how this can be. WEIDU can't extract these variables without parsing the whole tp2 file, whereas you can extract the keywords just by parsing the beginning of the tp2 file. OCAML doesn't have some magic ability to parse way faster than another language.
The 'BACKUP' keyword is not always at the begging of the file. You need to read it and apply regex. 100+ tp2 files = 20 seconds or more of waiting time during application startup before you can do anything.
30
WeiDU / Re: Allow for defining MOD_FOLDER - 'immutable' mod design without hacks
« Last post by DavidW on October 12, 2020, 10:58:54 AM »
some mods are using 'immutable' mod design-B with workaround. First, set the backup outside of 'mod data folder' via 'BACKUP' keyword. But it also sets MOD_FOLDER variable thi the value of it, so they need to overwrite MOD_FOLDER variable back to proper 'mod data folder'.
This is actually one of the things WEIDU v247 fixes. If you look at how MOD_FOLDER is now defined, it's equal to the folder in which the tp2 file exists if there is one; it's set from the BACKUP variable only for old mods where the tp2 file lives outside the mod folder. It's no longer necessary to set MOD_FOLDER explicitly (if you look at SCS v33.5, it doesn't do this any more.)

Quote
No matter how fast tp2 scanning is (not possible to use something like yeld return), the reality of having to scan 100+ mods makes this approach impossible for mod manager: people put crazy things into their tp2, some tp2 are huge and there are some tp2 which aren't mods at all. Launching WeiDU and getting the keyword values is the fastest and most error-safe way.
I'm confused how this can be. WEIDU can't extract these variables without parsing the whole tp2 file, whereas you can extract the keywords just by parsing the beginning of the tp2 file. OCAML doesn't have some magic ability to parse way faster than another language.
Pages: 1 2 [3] 4 5 ... 10