9 replies to this topic

[oopsilon]

I wouldn't know if this was possible or not, but could we expect to see the Weidu -automate flag expanded to also patch area pointers?

  For example, say I wanted to plug in an area from Icewind Dale into BG2.  Currently, if I wanted to keep the area in line with the spirit of Weidu in theory I would need to find the hex offset in the area file, patch that offset in a .tp2 with a dummy variable, then do a textual replace  of that variable to the new string ref.  Not too bad for a few areas, but for more than that it's a real pain.

I'll happily eat crow if this can't be done, but if it can, can you (Weimer) please consider this?

[weimer]

It could be done, but it would be an immense (well, kinda) amount of work for me because I would have to add the ability to parse ARE files to WeiDU. It already understands ITM, SPL and CRE (to a degree, at least to fine the names (which are at a fixed offset) and look through the effects for "display string").

In addition, I would have to include support for multiple formats (IWD2 uses AREv9.1, BG2 uses AREv1.0). However, if we kept things simple (e.g., "only automate the single main string reference in an Info/Trigger/ExitPoint) it could be done. If that's good enough for you *and* you can find one other person who wants this feature, I'll do it.

[japheth]

Well, area support is really the only big thing missing to give WeiDU the "total package" feel.

Perhaps another useful feature would be the ability to import areas to the .wmp file, and have the area entries/area links kept intact.

(ie, There are 24 area entries in the unmodified SOA .wmp, I import my area, and it become area entry 25 with the appropriate exit regions appended as well, and then another person imports their area and their area entry becomes 26).

But the problem with area compatibility is mapicons.bam as well. If I want to add an area and have it look totally new, I need to add new sequences to mapicons.bam so that a new icon is displayed on the worldmap for my area.

So I guess total area support with WeiDU would consist of appending non-destructively to the .wmp and figuring out a way to append sequences to mapicons.bam.

Non of this is crucial by any means, but it would certainly give WeiDU even more of an edge in the mod distribution arena where compatibility is concerned.


Oh yeah, and a side note that is totally off topic. Wes, in the WeiDU docs for the LANGUAGE part of the .tp2 it says this: The languageName is the name of the language as it is presented to the user. "American English" and "Traducción al Español" are examples. The languageDirectory is the name of the subdirectory in which you have stored the TRA files for that language. Examples include "american" and "spanish". Finally, all of the TRA files in the defaultLanguageTRA list are loaded as soon as the user selects a language.

So my question is, why in your Solaufein mod do you specify the subdirectory as ~american~, when from reading the docs it should be ~solarom/american~?

Is there some fuzzy logic I don't know about?

[oopsilon]

If you're willing to do the main string reference for triggers then that's more than good enough for me. The creatures and other triggers aren't nearly as painful since those are mostly done through Near Infinity or some other .are editing program anyway.

I'll have to agree with Japheth on the "total package" feel. Even limited area editing and support would go a long way to Weidify-ing mods that contain many areas to add in.

[weimer]

I'm tempted to reply that all of WeiDU is a hideous hack filled with fuzzy logic. Anyway, the "subdirectory" there means "subdirectory of your main mod directory". Actually, what it really means is "this is the value I will use to replace %s when it comes up in a COMPILE-USING or AUTO_TRA path".

So you could have EITHER:

LANGUAGE "American English" "american"
LANGUAGE "French" "french"
COMPILE "this.d" USING "mymod/%s/this.tra"

OR:

LANGUAGE "American English" "mymod/american"
LANGUAGE "French" "mymod/french"
COMPILE "this.d" USING "%s/this.tra"

Anyway. Since we seem to have two votes for ARE support I'll look into it over this weekend.

[japheth]

Yeah, I figured it would be a variable of some sort. It just struck me as odd, that's all.

[oopsilon]

Wes, a bit THANK YOU for adding in some area support! You rock! Now to go play with --automate some...

[oopsilon]

Okay, just grabbed Weidu 89 and gave --automate a spin. To test it out, I put a bunch of .are files converted from icewind dale to test directory, then ran "weidu --automate test --textout test.tp2". It didn't put any patch offsets in the .tp2 file, instead just having a bunch of COPY statements. Next, I put all of the .are files from my override directory into the test directory, deleted the old .tp2 file, and ran weidu again. This time it sorta worked. Maybe I'm missing something, but for now --automate seems to be really selective about which area files it could extract the information pointers from. From a cursory glance at the pointers in NI and the patched offsets in the .tp2 it looks like when it works it does a grand job of it.

[oopsilon]

A little more info so you (Wes) can try this locally. It works on ar5505.are but not ar0603.are. The ar0603 file is from the tactics mod, while the ar5505 file I'm assuming is from one of the many Wei-mods I've installed -- I've installed practically all of them except for selected chunks of Ease of Use and Spell50.

[oopsilon]

Damn do I feel stupid or what! After puzzling over this "bug" for a while, I suddenly discovered the --automate-min command. My fault for not RTFM.