1168 replies to this topic

[Gwendolyne]

There is also a little glitch I forgot to mention.

 

It's the same I noticed when testing NI bam converter:

 

1. When exporting a session without mentioning an ext, NI save it "session" without extension.

2. When importing  session without mentioning "sectionname".ini, NI refuses to import it.

 

It would be cool to correct this behavior the same way you did with bam files : automatically import "sectionname" if "sectionname.ini" exists even if I don't type the extension. And why not, automatically save "sectionname" as "sectionname.ini".

Edited by Gwendolyne, 28 January 2017 - 09:10 AM.

[Argent77]

There is also a little glitch I forgot to mention.

 

It's the same I noticed when testing NI bam converter:

 

1. When exporting a session without mentioning an ext, NI save it "session" without extension.

2. When importing  session without mentioning "sectionname".ini, NI refuses to import it.

 

It would be cool to correct this behavior the same way you did with bam files : automatically import "sectionname" if "sectionname.ini" exists even if I don't type the extension. And why not, automatically save "sectionname" as "sectionname.ini".

That's easily fixed.

[nullset]

This file is displayed perfectly fine on my system. It looks like you have the Beamdog version of the game, so it is no DLC issue.

 

Please enable Options -> Show Strrefs in View tabs and select the same dialog (BDVALIS.DLG) again. The view tab should now display the respective string references next to lines of text.

 

The line of state 4 (the topmost one) should be Strref 47515. Open the StringRef Lookup dialog (via Ctrl+L or menu Search -> StringRef...) and enter this number into the StringRef field. It should display the text that is used for this state: "Hah! The light of truth is my shield and my sword and they have struck the traitor down!". Does everything work as described?

Can you also open the Debug Console (via Ctrl+D or Tools -> Show Debug Console) and tell me if there are any messages?

Do you have any mods installed that could have made changes to SoD dialogs?
 

The Show Strrefs definitely caused the strref to show, but the string was still not showing and the tree showed a strref of -1 with no string.

 

This got me thinking of a corrupted dialog.tlk file. Turns out, I had a dialog.tlk in the user game directory, which was required for earlier WeiDU updates. I deleted that file, and not only is NI now working as described, but Weidu was still working with the dialog.tlk in the lang folder. All good now. Thank you for your patience. I am next door to a tyro and feeling stupid at the moment, but that's normal.

[Sam.]

Being able to view the BAM Properties is a really nice feature, but could it give a bit more info?  Here is a screenshot from an abandoned project I started a few years back that is similar to what I have in mind.  Note the bit in parenthesis is the frame offset expressed as a coordinate pair.

[K4thos]

Being able to view the BAM Properties is a really nice feature, but could it give a bit more info?  Here is a screenshot from an abandoned project I started a few years back that is similar to what I have in mind.  Note the bit in parenthesis is the frame offset expressed as a coordinate pair.

This would be a nice feature. But imo rather than external viewer I would prefer presenting BAM files exactly the same as any other file format (you know, the 'edit' tab).

[Argent77]

The Properties dialog is mainly intended to quickly look up basic information. If more detailed information about frame or cycle structures are needed you can open the file in the BAM Converter (via "Edit BAM" button). A new tab with more detailed BAM structure information would effectively provide the same information. I don't think this is really needed.

[K4thos]

Not sure if this was already requested but I think it would be a convenient feature to add "Find -> Reference to this file -> CRE" in INI viewer. In such case NI would check 0x28 offset of CRE files and print all CRE files that currently uses specific animation INI file.

Edited by K4thos, 16 February 2017 - 10:39 PM.

[Argent77]

I agree. That sounds like a useful feature. I'll see what I can do.

[Salk]

Argent77,
 
it seems there is some problems when NI is trying to display actions.
 
I attached two screenshots.
 

 
If I click on the arrow to see the next Response (Action 8 ) it will show another blank window and the arrow back option won't be available either.


 
As you can see the Tree correctly reports the action at Response 17 (18 too).

[Argent77]

In my own installations this file displays fine without issues. It sounds like the DLG file has been corrupted by some mod. Can you check if the Debug Console (Tools -> Show Debug Console) shows anything when? It would also help to attach the affected DLG file, so I can take a look.

The screenshot is too small to make it out correctly, but it looks like the action list contains an unlisted or unsupported script action IG("D0Chg2",0,1).

Edited by Argent77, 19 February 2017 - 02:56 AM.

[Salk]

The screenshot is too small to make it out correctly, but it looks like the action list contains an unlisted or unsupported script action IG("D0Chg2",0,1).

It's Virtue that adds IG:
 

// SET UP CUSTOM VERSION OF INCREMENTGLOBAL
// THIS VERSION, CALLED "IG", TAKES EITHER 0, 1 OR 2 IN PLACE OF "GLOBAL", "LOCALS" AND "MYAREA" RESPECTIVELY
APPEND ~ACTION.IDS~
~163 IG(S:GLOBAL*,S:Area*D0VTYPE,I:Value*)~
UNLESS ~163 IG(S:GLOBAL*,S:Area*D0VTYPE,I:Value*)~

COPY ~virtue/system/d0vtype.ids~ ~override~

 

I suppose that does not agree with NI?

Edited by Salk, 20 February 2017 - 12:31 AM.

[Argent77]

It was just a guess that IG() might be the culprit. However, if this action is properly defined in ACTION.IDS it should not cause any trouble.

Without the requested debug messages or the the affected DLG file itself I can't say more.
 

[Salk]

Hello again!
 
Thanks for your help! I have just checked the console and it gives me no error message.
 
About the files being affected, they are actually several and they all have IG() in common so I would say it is more than suspicious.
 
This is the relevant code from Virtue:
 

// SET UP CUSTOM VERSION OF INCREMENTGLOBAL
// THIS VERSION, CALLED "IG", TAKES EITHER 0, 1 OR 2 IN PLACE OF "GLOBAL", "LOCALS" AND "MYAREA" RESPECTIVELY

APPEND ~ACTION.IDS~
~163 IG(S:GLOBAL*,S:Area*D0VTYPE,I:Value*)~
UNLESS ~163 IG(S:GLOBAL*,S:Area*D0VTYPE,I:Value*)~

COPY ~virtue/system/d0vtype.ids~ ~override~

and this is what d0vtype.ids looks like in NI:



Perhaps there is indeed something wrong with how IG() is declared or even in the d0vtype.ids file itself?

Edited by Salk, 21 February 2017 - 01:51 AM.

[Argent77]

I can't reproduce it even with Virtue installed. All script commands are displayed correctly in both tabs "View" and "Tree".

Which NI version are you using?
 

[Salk]

Which NI version are you using?

I am using the latest version: v2.0-20171016.

Does it matter that I am on Windows XP or what Java version I am running?

[Argent77]

No, the Java version shouldn't matter. NI wouldn't run at all if your Java Runtime was too old. I could reproduce this bug only in older NI version (v1.36-20160214 or older). More recent versions work fine in this regard, even in my Windows XP VM.

However, the IG() script action uses a very unconventional interpretation of the script format specification and wouldn't compile in WeiDU or NI if it were used in regular BCS scripts. So there could also be issues in DLG files under specific circumstances.

[Salk]

I see.

I can report this issue not existing when using a very old version of NI (v1.33 Beta 19).

Truth to be told, I have no idea why this new IG() action was introduced but SimDing0 has not been around for too long to ask him directly...

Edited by Salk, 21 February 2017 - 05:17 AM.

[Argent77]

As a workaround you could open ACTION.IDS and change the entry
  163 IG(S:GLOBAL*,S:Area*D0VTYPE,I:Value*)
into
  163 IG(S:GLOBAL*,I:Area*D0VTYPE,I:Value*)

It is possible that it's having unexpected effects in the game though.

[Salk]

I've done that first but then I have been asking myself why SimDing0 did not do it in the first place and became a bit worried about the possible consequences.

 

He wrote a tutorial about IDS files so he'd have been aware of such trivial remedy. But I guess NI was not that picky at that time...

Edited by Salk, 21 February 2017 - 08:14 AM.

[Argent77]

I have recently begun to design a new BCS script compiler and decompiler from scratch as the current version is very limited, slow and difficult to maintain.

 

My goal is a compiler and decompiler that works flawlessly with BCS scripts of any IE games, is more configurable and faster than the current one, handles illegal or buggy scripts gracefully and is fully compatible with WeiDU's own script compiler (which includes support for artificial constructs such as TriggerOverride()).

It may still take some time before it is in a working state. Are there any features you think may be useful to be included in the new compiler?