Dynaheir LT 16

[Kulyok]

When Kulyok has finished her full playtest and review of code

 

What? I gave you the working code for Branwen and Dynaheir both.

[Guest Yuri]

You know, You sound like a gods, speaking to each other about these codes and staff, what mortals doesn't understand!

Anyway, thank you.For a moment it's working. I even Wrote nice ,,Thank You'' speech, But My romance with Dynaheir is only halfway, and Branwen and Shar-teel are ahead, so I save it for a later, because I'm afraid, we gonna meet eacother in this forum very soon.

But thank you again for that project and for helping me.

[Kulyok]

Sure enough, you're welcome - this is what this forum is for. (And, hey, you've got a working Branwen Romance, wow!)

[Edwyn]

FYI, I'm presently playing the Dynaheir Romance with v14 & Easytutu & last night I received LTs 15, 16 & 17 with absolutely no problem. I have Minsc in my party & lots of other Mods installed & all is fine.

 

PS: By the three, thy Ladies & Gentlemen hath created a Wonderful Mod & I bow to thee & Thank thee for all thou Impressive work !!

[cmorgan]

Coolness Glad to hear it is working. We still are going to want to tweak it to try to make sure that it is as robust as it can be, but it is nice to hear confirmation that it is working as planned with your install.

 

(Miloch, if you do hit Civ3, send info my way on what mods you are doing - I expect this summer will see Civ3 hit my harddrive again, probably with DYP or another big mod, as I have been away from Apolyton for way too long - but don't drop the BG stuff, for goodness sake - I haven't either, just scaled back a bit to allow my wife, dogs, relatives, and students a bit more time! I found my lunch hours, free time, and what would usually constitute "inetract with RL" was getting crowded out, so had to back off on the BG/BG1NPC hours, that's all! My hardrive is getting backed up. New JA2 inventory mod released, the HDCP for MechWarrior:Mercenaries, a whole huge workd of Morowind stuff, and I still really haven't got off the ground on what I want to do with BG2 - I gotta stop researching and pick a place to concentrate on for awhile, or I will drown in good stuff to do.)

 

(Kulyok - yep, good stuff - I wouldn't mind you doing a full run of all code; it has been done by several heavy duty folks from both Tutu and BGT sides, and your stuff has also been gone over by others to recheck against original code and check for stuff; so just think of the kudos you get when you find what all of us have missed! A win - win situation. You get to show your skills off, and BG1 NPC gets another layer of fine-tuning done!)

[Kulyok]

(Kulyok - yep, good stuff - I wouldn't mind you doing a full run of all code; it has been done by several heavy duty folks from both Tutu and BGT sides, and your stuff has also been gone over by others to recheck against original code and check for stuff; so just think of the kudos you get when you find what all of us have missed! A win - win situation. You get to show your skills off, and BG1 NPC gets another layer of fine-tuning done!)

 

It is futile. Take it from a long-time professional tester: the best we can do is fix what is repored now, and update after serious enough bug reports as fast as we can. When you update the beta with the recent changes, I'll test it together with the others, but "why don't we overhaul these three mb of code one more time, it's fun" won't go over well.

 

(One thing I thought of was reverting _all_ variable changes, because I do not doubt some of them got wrong prefixes, just like that Aldeth variable. I don't doubt it's impossible, though.)

 

But, okay, I'll look over pieces of code that look problematic to me.

(I'll post a few pieces here so I won't forget, then we'll continue it in the workroom).

 

x#addial.d

ADD_TRANS_ACTION ~%tutu_var%KEEPER~ BEGIN 4 END BEGIN END

~SetGlobal("X#GainedEntryCandlekeep","GLOBAL",1) RealSetGlobalTimer("X#InsideCandlekeep","GLOBAL",200)~

 

x#ajint

- Two interjections' names miss X# prefixes;

 

/* Ardrouine (looks for her son threatend by Worgs) */

I_C_T2 ~%tutu_var%ARDROU~ 0 X#AjantisArdrouine

== ~%AJANTIS_JOINED%~ IF ~InParty("ajantis") InMyArea("ajantis") !StateCheck("ajantis",CD_STATE_NOTVALID)~ THEN @57 DO ~SetGlobal("J#ArdTalk","GLOBAL",1)~

END

 

J#ArdTalk?

 

x#kaqst.d

SetGlobal("X#KagainCaravan","GLOBAL",3) and

SetGlobal("KagainCaravan","GLOBAL",3) - no X# needed.

 

... will continue later. Sometimes I'm really surprised they haven't fired me from my day job, yet. I would.

[Miloch]

(One thing I thought of was reverting _all_ variable changes, because I do not doubt some of them got wrong prefixes, just like that Aldeth variable. I don't doubt it's impossible, though.)

One could output all the variables from the unmodded game in one list, then all the variables from BG1NPC without the prefixes in another and then run a query (in SQL or even MS Access or Excel) to see if there are any matches. If you really think it's a possibility, it might be worth all of 5 or 10 minutes it takes to do that.

[berelinde]

J#ArdTalk is necessary to preserve compatibility with Sirene's Call, so the one in x#ajint.d is all right.

[Kulyok]

Cool! I thought J# was familiar.

 

[bOne could output all the variables from the unmodded game in one list[/b], then all the variables from BG1NPC without the prefixes in another and then run a query (in SQL or even MS Access or Excel) to see if there are any matches. If you really think it's a possibility, it might be worth all of 5 or 10 minutes it takes to do that.

 

Output all the variables from the unmodded game in five or ten minutes? Would you show how it is done?

[cmorgan]

I've already done this multiple times using both winmerge and sevearl other tools (including all Cam's debugger stuff), but it is always worth materials going over again!

 

The KagainCaravan stuff needs doublechecking, as we clean out all KagainCaravan values and use X#KagainCaravan for the new quest resolution.

 

Keep 'em coming!

[Miloch]

Output all the variables from the unmodded game in five or ten minutes? Would you show how it is done?

Fire up DLTCEP, go to Settings > Logging > File, then Tools > Scan variables

(And yes, Tutu is messed up royally compared to the other platforms.)

 

That takes about a minute or two. Fire up chitem.log in Excel, sort it and delimit it so that the sort puts all variables in one section and the delimit cuts off everything before a tab set, keeping only the variable names (and whether they're LOCALS or GLOBAL if you want). That takes another couple minutes. Then I'd import that into Access, discard any duplicates and run a match query vs. your other list. That'd take another few minutes, tops.

 

But if cmorgan's already done it multiple times, eh... I guess he just missed one...

[Miloch]

Eh. Well I went ahead and did this query and a bunch of others while I was at it.

 

These are BG1NPC variables that would duplicate vanilla Tutu variables if their prefixes were removed (some may be valid, some maybe not):

Possible inaccurate variable references in BG1NPC v14

Scope   BG1NPC Variable   Tutu Variable
GLOBAL  x#ajantisleave	ajantisleave
GLOBAL  x#aldethmove	  aldethmove	[CORRECTED]
GLOBAL  p#aloraloots	  aloraloots
GLOBAL  p#coranreward	 coranreward
GLOBAL  p#coranwyvern	 coranwyvern
GLOBAL  x#edwinabandoned  edwinabandoned
GLOBAL  x#kagaincaravan   kagaincaravan
GLOBAL  p#rain			rain

• There is one Tutu variable apparently removed by the install of BG1NPC (mactazokbelt)
  
• There is one unique used BG1NPC variable defined as both a LOCALS and GLOBAL (x#yeka4)
  
• There are about 194 apparently unused BG1NPC variables (referenced only once - some are also defined as both LOCALS and GLOBAL)
  
• All told, there are about 3541 variables added by BG1NPC (many of these have no unique prefixes - subtract the unused to get the used)
  

And here is the list of all variables in unmodded Tutu if anyone wants it.

[Kulyok]

Oh wow. This is impressive - much better than my old eyes. And there's an "GLOBAL j#alorainactive" in the list of unmodded Tutu variables, too - hey, Bioware used Ghreyfain's preeeefix!

[berelinde]

That's cool, Miloch! Using that list, I see that many of the unprefixed variables have prefixed equivalents, which probably bears looking into. Coolness.

[cmorgan]

This is what CamDawg was talking about with the statename variables, too - when we (meaning 99% of the i.e. modding world) name a CHAIN state or interjection <<something>> and then set

X#<<something>>

we are actually duplicating effort, because the materials set a global.

The problem is that unless you install the project and then run Camdawg's variable tools, checking everything, it makes it much harder to track where that first variable is set, because the lists usually are generated by a regexp search that is centered around "lobal"...

 

Miloch, i was doing it the hard way. I should have thought of DLTCEP and your hard work on this - I was running comparisons and diffs of tutu vanilla decompiled .dlg vs project added ones; using CamDawg's variable extraction tp2 on vanilla tutu and then on installed project code and diffing the results; using TextPad and creating regexp lists of everything with lobal in it and diffing vanilla to project, etc. - and then looking through NI scans.

 

It would have been so much easier and given me back hundreds (literally0 of hours of time if i had just thought of it - from bnow on, when I think of a good way of cleaning and researching a mod, i am going to post the idea before i do it, and get you guys to help me refine the technique before i spend hours upon hours combing through code.

 

The good news is that I can donate an archive of clean EasyTutu and BG2 .dlg and .baf decompiled, up on my website. It might save folks a few minutes.