11 replies to this topic

[Dyara]

Something different but might have the same reason (and is perhaps real disadvantage):
In our d file we have

IF ~~ THEN BEGIN P7J2
  SAY @995
  IF ~~                                                 THEN REPLY @996 GOTO P7N
  IF ~OR(2)
        Class(Player1,PALADIN_ALL)
        Class(Player1,CLERIC_ALL)
      !Kit(Player1,16389)~                              THEN REPLY @997 GOTO P7O
...

I´ve used a number instead of 'INQUISITOR' because on most BG2 installations the KIT.IDS is wrong. When WeiDU compiles the dialogue it exchanges the 16389 with something it finds in the KIT.IDS. No problem but what happens if the player replaces the KIT.IDS without uninstalling/reinstalling our mod? Most likely our transition trigger is wrong then... (and it took me hours to find the proper value for the inquisitor kit ).

I would prefer that WeiDU don´t replace numbers with entries of IDS files. There´s no advantage doing this but it could cause some problems.

[weimer]

Remembering for each particular symbol whether you entered it as a number or as a symbol would take a bit of extra work. However, I could easily add a switch to have WeiDU always emit numbers instead of IDS symbols. Would that suffice?

[Dyara]

Hmmm... I guess the dlg files would become very difficult to read if WeiDU *allways* emit numbers instead of symbols.

Some other ideas:

A) a switch that tells WeiDU to keep the actions/triggers as they are in the d file,

or

B) a keyword that can be used inside a d file or a global switch that tells WeiDU to use allways numbers for a specific argument and a specific trigger.

Example:

USE_ALLWAYS_NUMBER Kit 2

would tell WeiDU to use allways numbers for the second argument of Kit(..).

C) Something that tells WeiDU to keep a specific trigger/action. Example:

IF ~~ THEN BEGIN P7J2
SAY @995
IF ~~ THEN REPLY @996 GOTO P7N
IF DONT_CHANGE_THAT ~OR(2)
Class(Player1,PALADIN_ALL)
Class(Player1,CLERIC_ALL)
!Kit(Player1,16389)~ THEN REPLY @997 GOTO P7O
...

or

IF ~~ THEN BEGIN P7J2
SAY @995
IF ~~ THEN REPLY @996 GOTO P7N
IF ~OR(2)
Class(Player1,PALADIN_ALL)
Class(Player1,CLERIC_ALL)
!Kit(Player1,KEEP_THE_NUMBER:16389)~ THEN REPLY @997 GOTO P7O
...


D) I guess the problem occurs only with the second argument of the trigger Kit(...) since the KIT.IDS is the only wrong IDS file (in BG2). Most likely a keyword or a switch

DONT_USE_SYMBOLS_IN_SECOND_ARGUMENT_OF_TRIGGER_KIT

would suffice.

E) Don´t use symbols for the second argument of Kit(...) at all.

However, it´s not very urgent (I´m sure we won´t release in the next weeks ).

[cirerrek]

D) I guess the problem occurs only with the second argument of the trigger Kit(...) since the KIT.IDS is the only wrong IDS file (in BG2).

Astyle.ids might be another one. At least the only one that ever seems to work is DEFAULT

Just an observation.

Thanks,
Cirerrek

[weimer]

After a bit of thought, here is my proposed solution:

Since this problem only comes up when you write a mod (baf/d) on machine A with IDS files IDS-A and then ship it to someone with machine B and IDS files IDS-B, I will allow you to specify a set of IDS files in a TP2 file and then WeiDU will merge all of those IDS file entries into the files that are already present (effectively taking the union of the user's settings and yours). This ensures that their old stuff and the new mod both work.

What do you think?

[Dyara]

I don´t think that mixing IDS files is a good idea. What happens if a second Mod uses the same IDS file but another version of that file?

I guess the problem is this:

Going from BAF to BCS and back to BAF usually doesn´t result in the same BAF file ('BCS' -> 'BAF' -> 'BCS' is save!). So imho the only really good solution is... keep the original 'baf'.

In a dialogue we have now ('BAF'/'BCS' means uncompiled/compiled actions/triggers):

Writing the Mod: 'BAF' (checked & tested)
Installing the Mod: 'BAF' -> 'BCS' -> 'BAF' (created by WeiDU, depends on players environment during installation)
Playing the Mod: 'BAF' -> 'BCS' (depends on the *current* environment)

Problems occur when the environment on the player´s machine changes between installation and playing the Mod.


And there´s also another problem: What happens if there´s a bug in the dialogue that needs fixing? But I don´t want to make a new version, I just want to write a patch? But how can I do that? I´ve 'no idea' what WeiDU has really written in the action/trigger lists (and it could be different on different machines). And since the environment on the players machine might have changed it´s impossible to remake the steps that were made during first installation.


I don´t see the advantage in doing this 'BAF' -> 'BCS' -> 'BAF' step. I guess you do the 'BAF' -> 'BCS' step to check the actions/triggers, but why don´t you keep the original actions/triggers? Checking the actions/triggers and giving warnings/error messages is a very good feature but inmy opinion it´s not in WeiDU´s responsibility to fix actions/triggers. That´s the job of the writer of the Mod (imho).

Maybe it´s possible to make this replacement (or that 'not replacing') a feature?


Of course what I describe is really the worst case but I´m very sure that these problems will occur... not often but sometimes.

[Rassadihn]

And there´s also another problem: What happens if there´s a bug in the dialogue that needs fixing? But I don´t want to make a new version, I just want to write a patch? But how can I do that? I´ve 'no idea' what WeiDU has really written in the action/trigger lists (and it could be different on different machines).

Oh, wow, Dyara makes a great point. I KNEW there was a legitimate reason I was weirded out by WeiDU changing my IsValid to IfValid, and this is it.

REPLACE_ACTION_TEXT_PROCESS should do the job. :-D

Of course, that doesn't work for trigger lists, and it replaces things globally.

I'm going to go out on a limb here and propose to always compile scripts under the hood, and deprecate simple textual replacement altogether. This works only as long as the BAF -> BCS conversion is invertible, and as we've seen, situations where this is not true are too easy to imagine.

This still doesn't solve the "WeiDU doesn't give me *my* BAF back" problem, nor the "what if the IDS files get changed" problem. The only sure-fire way to solve those is to never *decompile* on *your* system (and work on BAFs only) and never to *compile* on *someone else's* system (and work with BCSs only).

OTOH, such draconic measures may be overdoing it in most situations. If only Baldurdash could be retrofitted with all the relevant IDS fixes...