54 replies to this topic

[cmorgan]

[SHORTEST ANSWER]
Problems? No problems. Pay no attention to the man behind the Emerald Green Curtain... what you don't see can't hurt you
[/SHORTEST ANSWER]

[SHORT VERSION]
It means that despite all the testing, there are some few interjections and materials on "non-vanilla" BGT installs that are working with the wrong stuff.
In a Mega or Fixpacked install of BGT, there will occasionally be things on Jaheira's J and P, Edwin's J and P, and especially Viconia's B and J that will block someone else's addition from completing, or stick a strange comment where it was not designed to go.
As has been seen in practice, this has had little noticeable effect on gameplay; I chalk that up to the vast majority of content on a Mega and the incredibly small (97 out of literally thousands) number of possible content items available. For me, if it were just "wow, that comment was out of the blue", I wouldn't care - technically, we only support "vanilla" Tutu, EasyTutu, and BGT.
But we actually stop some other mod added states on non-vanilla installs from firing [the HappinessLT(0) states in particular *need* to be stopped, and they aren't getting stopped] and that is just wrong/bad/against my personal philosophy of "do no harm - unless you meant to, in which case nuke 'em 'til they glow and shoot 'em in the dark".
[/SHORT VERSION]



[LONG-WINDED EXPLANATION]
OK, let me give it a shot.

Think about BG and BG2 as building frameworks. Now, they are built up of timbers. These are called "states". And for the most part, it is very, very difficult for a modder to cut large parts of them away without radically altering the building, so that no other person can use it. If I come along and wall over a window, well, that can be found and rolled back, but if I knock out a structural beam and then change the front entry into an indoor pool, suddenly all the folks creating beautiful doorknobs end up tossing them into the pool instead of replacing the existing doorknob.

Now most mods operate by finding the timbers and buiding new structures off of them. In fact, most mods look, see the timber, and say "way cool - if someone steps on this timber, I will let a whole ton of cool things happen afterwards!". The base structures are a framework that we can hang or gently alter in a way that allows other folks to set things in the same area. Obviously, if I paint a section of timbers red and turn it into a bedroom, and then someone else comes along and paints part of it green and turns it into a bathroom, well, that is a possible "conceptual incompatibility" as some other forums put it... but it is not a change in the actual structure, just the paint and fixtures. Heck, I can even cut a new window, and change it into a darned TV room, and have someone else come and put a dining set, etc - and everything is still good. Perhaps a little odd, but still good.

This works because the base states remain the same. And it is why you can even have modding - all these are fixed.

Now we come to Ascension64's BGT and Japheth's Tutu. In both cases, the idea in play is to create BG content in BG2 engine. In both cases, every attempt was made to keep the base states, or structural timbers the same.

BUT.

Tutu and BGT are mods. Both convert the original resources; in the vast majority of cases, they take the building structures intact, and move them over a few streets to a new neighborhood, into BG2 town. No big deal; with a few tweaks, mostly so that the game engine (Post Office) can recognize that there is a BG building with BG occupants there, we are all good on both BGT and tutu.

EXCEPT -

the Post Office will not recognize that Jaheira in BG is not Jaheira in BGT. And you know how hard it is to convince the Post Office of anything. For future reference, read Going Postal by Terry Prachet. Or some of the internal publications at your local Post Office.

SO -

BGT has to take the BG buildings Jaheira, Edwin, etc (all the NPCs that can join up with <CHARNAME> in BG and again in BG2) and stack the BG building ON TOP of the BGT building.

For most mods, especally anything designed for BG2, this is a non-issue. Heck, the building just got taller - I was going to repaint that front door red, and it is still the front door, so no biggie. Who cares about the upstairs neighbors. Besides, most modding just adds new timbers, or diverts existing ones - for almost all mod added stuff, there is little which actually goes back and latches onto the old timbers - most of the time we just build right on top of the old ones.

NOW - wait for it - comes the problem we are discussing here.

It seems simple (and it is for 99% of modding) - if I have a Tutu timber I want to fix on a BGT converted building, I just go ahead and count up the number of timbers in the BG2 building, and there I am, right at BG's front door, on the second level. I can fix what I want to fix, change what I want to change, and everything is cool. Basically, cross-platform modding takes the addresses, changes them, and where needed changes the design plan to take into account that we need to send the construction crew to the second floor instead of the first floor.

Exept for one minor, nagging little point. Exactly how many timbers are in the BGT building?

Since BGT (and vanilla Tutu v4, for that matter) is a mod, and often placed on other mods, it has a whole ton of special things that Ascension64 has spent hundreds of hours of modding time to create to make things work. On a clean, straight BGT/Tutu v4 install, the building is a known number of timbers, and we can just add up our count and proceed with construction/demolotion as we see fit. On EasyTutu, nothing can be put before the Tutu install, so we *know* that the buildings are absolutely secure, and we don't have the addressing problem. So when we built out interjections, we (well, Pro5 and Chevalier, really) looked at BGT and said "cool - Edwin timber 0 on Tutu = Edwin timber 976 on BGT". Voila, mod finished, mission accomplished, c'est fini, c'est tout.

For BGT that has NeJ, or the Fixpack, or actually any other mods that add to those very specific addresses BEFORE BGT is insalled, then Ascension64 takes it into account, and builds a clean foundation, then drops the BG building in place - and in a very few cases, has to deal with the Post Office by putting the BG building as a second story. But those mods/fixpacks/etc. may or may not have added timbers...

ce n'est pas de fini, quel dommage, ce n'est pas tout, c'est yucky.

and now when I send the construction guys to lop off Timber 0 on Tutu, translated into Timber 976 on BGT, I find that I am cutting into 976 {Magical Pool Of Radience} rather than timber 976 {Front Door That Is Always Open And Needs To Be Shut Because It Is Cold Outside}. This leads to a magical gusher that turns my construction team into blue squirrels, and the BG Front Door is still open, leading to bug reports about people accidentally falling out and dropping like stones to the cobblestones a floor below...

What has happened is that the BG building has gone from "fixed" states, where everything is in order, to "fluid" states, where the state number is dependent on how many extra states have been added to the BG2/BGT building.

(Salk - for you, this is kind of like sttrefs - a strref on SoA vs one on ToB vs one on Tutu [added to the top of either SoA or ToB] vs one on BGT...)

Crossmod content has the same problem, as where Keto says "You are a cutie" changes with every different install order. So the bigg coded up a special command that ignores this "fluid state" problem by doing the equivalent of a "reverse lookup" - STATE_WHICH_SAYS looks for the actual string contents, and backtracks to the building, and says "Yo! She says this right HERE>>>" and points to the correct building timber that has her words painted on. The problem with doing this on the original dialogues is, well, they ain't original. There is Baldurdash GTU, there is the original, there is the Fixpack GTU, there are all the variants on these that have crept into people's installs; heck, how do I find out if someone is using the v1 of a certain GTU, or another modder has used SET_STRING or something to change the contents of the string to reflect that Imoen is starting her own Magical Pilates Workout Emporium - on crossmod content, the modder updates their mod, and those things stay pretty much the same from version to version. This is a big problem for me, because
a. I don't have all those installs to tra out and collect, and
b. even if I did, I can't keep up with all the changes, and
c. I can't troubleshoot on that many variants of installs, which means I can't support it.

So Ascension 64 came up with a really good, simple idea - find out how many states there were pre-BGT install, by counting them in the Backup folder, which reflects the pre-BGT states, and then BGT slaps the buiding on top, then just do some simple math, and voila - you know where State 0, BG's Front Door, resides - regardless of language, install order, etc.

The problem is that on a clean install of BGT, there appears to be no backup of those dialog files. So nothing to read/count.

I think we have solved it, at least temporarily -

Between the bigg, Ascension64, and Nythrun all pounding ideas into my brain, we have one possible solution to test out (I am still working with Nythrun to recheck the code). Nythrun sent this codeblock back after my last round of questions/attempts to understand and mangle other people's code.

We know that most pre-BGT install mods *will* create a backup; the Fixpack definitely causes a backup to be made by BGT, as does NeJ, etc. But vanilla BGT does not appear to (it must - Ascension64 or someone will let me know where my logic is wrong eventually ) and probably it is safest to look at the files after each combination of pre-BGT mods are installed and count the differences in states before the BG ones get put on...


so this one looks for a backup,
uses it if it exists,
and sets the value to Tutu/BG original if BGT is *not* installed,
counts the backup if BGT is installed and a backup exists,
or sets a "hardcoded" value if no backup exists for whatever reason and a specific mod that adds a known number of states to this particular file is installed.

*whew. i gotta go have a scotch.*

/* Nythrun's, Ascension64's, and the bigg's Fluid State Solution: EdwinJ */
OUTER_SET edwinj_num_states = 0
ACTION_IF FILE_EXISTS_IN_GAME ~AR7200.are~ THEN BEGIN
  ACTION_IF FILE_EXISTS ~bgt/backup/0/edwinj.dlg~ THEN BEGIN
	COPY - ~bgt/backup/0/edwinj.dlg~ ~nowhere~ //or inlined/BGT/etc??
	  READ_LONG 8 edwinj_num_states
  END ELSE BEGIN
	OUTER_SET edwinj_num_states = 188
	ACTION_IF MOD_IS_INSTALLED ~setup-bg2fixpack.tp2~ "0" THEN BEGIN
	   OUTER_SET edwinj_num_states = edwinj_num_states + 3
	END
  END
END
OUTER_FOR (i1 = 0; i1 < 378; i1 += 1) BEGIN
  SET EVALUATE_BUFFER ~BGTEdwinJState%i1%~ = i1 + edwinj_num_states
END

The *only* folks who really need to mess with this are folks who are tapping into BG states (usually I_C_Ts) on the small list of party-joinable NPCs files given by Ascension64 a few posts back.

As far as I know right now, that is a constituency of exactly one - me.

Edited by cmorgan, 15 January 2008 - 02:23 PM.

[Ascension64]

Nice analogy on buildings. If only floors all had trivial names the world would be so much easier to deal with.

We know that most pre-BGT install mods *will* create a backup; the Fixpack definitely causes a backup to be made by BGT, as does NeJ, etc. But vanilla BGT does not appear to (it must - Ascension64 or someone will let me know where my logic is wrong eventually smile.gif ) and probably it is safest to look at the files after each combination of pre-BGT mods are installed and count the differences in states before the BG ones get put on...

If an existing file exists only in a BIFF, a BACKUP IS NOT MADE. That's as simple as it gets. So, if EDWINJ is still the BioWare stock version that you can find in dialog.bif, and I APPEND to it, you won't see a backup being made. However, if Fixpack decided to change EDWINJ first, you'll find it in the override. If an existing file exists in the override, a BACKUP IS MADE.

I was thinking that if a file does not existin the backup directory, you could somehow query a BIFFed version of the file: problem is, BGT would BIFF EDWINJ, and so querying the BIFFed version would only give you the post-BGT version and not the pre-BGT version.

Another problem is that if someone decides to BIFF their override before installing BGT (voluntarily or involuntarily), you won't get a backup either. Here's an easy fix, though -- I can force COPY_EXISTING in the next version of BGT, which will guarantee you will find the files you need. They won't necessarily be in BGT/backup/0, because that might muddle with real backups, but it will solve all your problems...OR I could do a massive DV change as Kulyok suggested. Preferences?

[CamDawg]

Why not just drop a file in the BGT directory that can be INCLUDEd by other mods? Something consisting of

OUTER_SET "edwinj_start_state" "87"

or are the states not explicitly known by the BGT installer during processing?

And nice building analogy cmorgan.

Edited by CamDawg, 15 January 2008 - 04:55 PM.

[cmorgan]

Thanks guys - it is nice to finally (think that I) understand this stuff myself.

@Ascension64 - I wish I could give you a balanced opinion, but either way is a PITA for you.

I just don't know about the change DV thing -

To start with, we all know Kulyok is correct about the fundamental strength of keeping the files separated. We also know you are right, Ascension64, on the simplicity/need of keeping the pdialog.2da etc. clean.

The problem with changing DVs is

#1, it is a helluvu mess for dealing with NeJ et al (all the normal Mega stuff that makes BGT attractive to a strong segment of BG players). It means you have to (let's face it, it would have to be you, as most of those are not supported directly by their authors) re-engineer/detect/patch/change all the stuff already installed before BGT - and that is a massive hornet's nest. I still can't figure out how you managed to get BGT set up to figure out what to rebuild as it is, and I have been staring at your code for over a year now. SO, no backwards/Mega compatibility, and a whole garbage load of extra work that you could be using to mod, rather than tweak a stable, consitent platform. Basically, you rip one leg out of your own mod, taking away a whole segment of your audience .

#2 moving BGT to an EasyTutu-like system might seem like an answer, locking everything down, but see #1 only 10-fold - less work for you, but absolutely NO compatability for Megas/Pre BGT Fixpacking, at all. (Or, of course, the joy of multiple installers by mod wanted pre-BGT, with the added joy of you having to do what Macready has to: install the Fixpack fixes manually on the master install... err.... forget this idea completely).

#3 the number of BG content mods that specifically hook into BG states in joinable NPCs needing this treatment seems small. Gavin, a project or two in the works, and Jastey's extended quests do come to mind, plus the mods you currently handle as the BGT captain (Sirine's Call, Indira, etc, most of which do not jump into those Joined NPCs at all.)

The only reason I can see you wanting to do this is if you see a whole ton of BG content mods that are just on the horizon, which are going to I_C_T and such into BG content states on those files. I don't know about that.

That being said, if you do decide to chaneg the structures, I volunteer to assist those mods with a new set of libraries and variables ready-made, so people can just do an INCLUDE and set up a whole raft of
%BG_VICONIA_DV% %BG2_VICONIA_DV% %BG2_VICONIA_J% %BG_VICONIA_J% etc., and help Jastey and berelinde rework their mods to match.

@CamDawg - I better leave that idea to Ascension64. I am still struggling with the codes for more advanced reads Nythrun gave me, and this just about smashed my brains up against the top level of my ability (and considerably beyond, with the iteration. Copying and using is one thing - truly understanding and being able to manipulate it is another).

Edited by cmorgan, 15 January 2008 - 08:29 PM.

[Ascension64]

Why not just drop a file in the BGT directory that can be INCLUDEd by other mods? Something consisting of

OUTER_SET "edwinj_start_state" "87"

or are the states not explicitly known by the BGT installer during processing?

Either way works, the only difference between handing cmorgan the cooked state numbers on a platter and handing cmorgan raw dialogues on a not-so-friendly dish is who works out what the state numbers are. I can easily do this with nary more ado than copying dialogues to the nooks of BGT folders.

@cmorgan: basically, in v1.06, I can give you the equivalent state 0s of all the fluid dialogues so you can then work out the 'base pointer' for the states you want to patch. It will simply be a .tpa file you can INCLUDE if BGT is detected, and can replace the state number variables you have in the bgt_cpm_vars.tph file.

To start with, we all know Kulyok is correct about the fundamental strength of keeping the files separated. We also know you are right, Ascension64, on the simplicity of keeping the pdialog.2da etc. clean.

The problem with changing DVs is

#1, it is a helluvu mess for dealing with NeJ et al (all the normal Mega stuff that makes BGT attractive to a strong segment of BG players). It means you have to (let's face it, it would have to be you, as most of those are not supported directly by their authors) re-engineer/detect/patch/change all the stuff already installed before BGT - and that is a massive hornet's nest. I still can't figure out how you managed to get BGT set up to figure out what to rebuild as it is, and I have been staring at your code for over a year now. SO, no backwards/Mega compatibility, and a whole garbage load of extra work that you could be using to mod, rather than tweak a stable, consitent platform. Basically, you rip one leg out of your own mod, taking away a whole segment of your audience sad.gif .

#2 moving BGT to an EasyTutu-like system (see #1 only 10-fold - less work for you, but absolutely NO compatability for Megas/Pre BGT Fixpacking, at all.)

#3 the number of BG content mods that specifically hook into BG states seems small. Gavin, a project or two in the works, and Jastey's extended quests do come to mind, plus the mods you currently handle as the BGT captain (Sirine's Call, Indira, etc, most of which do not jump into those Joined NPCs at all.)

Touche. I agree that we shouldn't really involve modders who really have nothing to do with this topic by asking them to bend to our will or suffer a loss of mod compatibility with BGT. Either way, there is no good way of working out fluid states without marking every state with some kind of trivial/symbolic marker, like useless triggers of Global("<ModPrefix><DialogueFile>STATE<Value>","GLOBAL",0). Hmm, I wonder if you substitued "GLOBAL" for "SYMBOL", would the script still compile? Cluttery, but would solve all problems with fluid states - as long as you don't go on to set those variables to something else.

Edited by Ascension64, 15 January 2008 - 08:35 PM.

[Salk]

I just want to thank you cmorgan for the splendid analogy which made things much more clear (for me, at least). I'd pick you as teacher at school, dear boy. It seems to me you have also a great deal of patience and with me, well... that's mandatory...

I have only one question: why did you guys think of such a problem now? I mean, BG1 NPC has been officially compatible with BGT for a long time and the BG2 Fixpack has also been out for over one year.

[Ascension64]

I just want to thank you cmorgan for the splendid analogy which made things much more clear (for me, at least). I'd pick you as teacher at school, dear boy. It seems to me you have also a great deal of patience and with me, well... that's mandatory...

I have only one question: why did you guys think of such a problem now? I mean, BG1 NPC has been officially compatible with BGT for a long time and the BG2 Fixpack has also been out for over one year.

It took that long to get bug reports from mega-mod players...?

[Ascension64]

@cmorgan: here is what I got for you. The state 0 equivalents are dynamic based on the number of states in total before the BG1 stuff is appended onto them. Are the variables alright, or should I name them better? You can use Nythrun's method to work out the rest of the states from the state 0 equivalents (whatever BGT-WeiDU determines them to be).

BGT/Compat/BG1NPC/FluidStates.tpa (what it looks like on vanilla BGT install)

//Dialogues always appended
OUTER_SET BGTBEDWINState0 = 106
OUTER_SET BGTBJAHEIState0 = 461
OUTER_SET BGTBMINSCState0 = 99
OUTER_SET BGTBVICONIState0 = 575
OUTER_SET BGTEDWINState0 = 74
OUTER_SET BGTEDWINJState0 = 188
OUTER_SET BGTEDWINPState0 = 9
OUTER_SET BGTIMOENState0 = 26
OUTER_SET BGTIMOENJState0 = 111
OUTER_SET BGTIMOENPState0 = 16
OUTER_SET BGTJAHEIJState0 = 531
OUTER_SET BGTJAHEIPState0 = 74
OUTER_SET BGTMINSCJState0 = 241
OUTER_SET BGTMINSCPState0 = 10
OUTER_SET BGTVICONIJState0 = 183
OUTER_SET BGTVICONIPState0 = 14

//Never Ending Journey 2 compatibility appending
OUTER_SET BGTXANState0 = 0

//The Darkest Day compatibility appending
OUTER_SET BGTKAGAIPState0 = 0
OUTER_SET BGTKIVANPState0 = 0
OUTER_SET BGTSHARTPState0 = 0
OUTER_SET BGTXZARPState0 = 0
OUTER_SET BGTYESLIPState0 = 0

//Tortured Souls compatibility appending
OUTER_SET BGTBCORANState0 = 0
OUTER_SET BGTCORANState0 = 0
OUTER_SET BGTCORANJState0 = 0
OUTER_SET BGTCORANPState0 = 0
OUTER_SET BGTDYNAHJState0 = 0
OUTER_SET BGTDYNAHPState0 = 0

I neglected to mention the compatiiblity appending earlier, so you might need to incorporate those as well. If it is going to be too difficult to remember which dialogues need special treatment, I can set variables for all original, B, J, and P dialogues, if you like.
If BGT is installed, you would simply INCLUDE ~BGT/Compat/BG1NPC/FluidStates.tpa~ and you are off.
I also drop copies of the unappended dialogues into BGT/Compat/BG1NPC with their BG1 names (e.g. IMOEN2J -> IMOENJ, JAHEIRAJ -> JAHEIJ) -- just in case you want to do something with them.

Edited by Ascension64, 16 January 2008 - 04:12 AM.

[cmorgan]

I have only one question: why did you guys think of such a problem now? I mean, BG1 NPC has been officially compatible with BGT for a long time and the BG2 Fixpack has also been out for over one year.

Well a couple of reasons, Ascension64's being the primary - because we built for vanilla EasyTutu and then translated to vanilla BGT, everything worked fine! (Take a look at Ascension64's fndings on all those states for NeJ2, TS, TDD - no state changes before appending, so Tutu=BGT, and all the vanilla BGT states match my clean install of BGT and therefore Pro5's and Chevalier's installs).

Other reasons:
1. The number of states changed is so small it amounts to a tiny fraction of the available states;
2. to get those states can be difficult {example - Hoppy's findings that jsome NPCs leave when they are ticked off when the player clicks on them to initiate a Player Initiated Dialogue. The conditions needed to have the bug were a. have Jaheira in the party, b. have the Fixpack installed, c. have a pretty low reputation, d. have the PID component of BG1 NPC installed, e. click on the PID while all these are met.}
3. The states accidentally shut down were actual Fixpack fixes to BG2; basically, rolling back a fix that added interjections to Watcher's Keep in SoA. To get that to be found, someone had to a. know that the interjections were supposed to fire, b. go to SoA Watcher's Keep on a big install that was Fixpacked, c. recognize that it didn't fire, and d. recognize that the reason it didn't fire was because BG1NPC had inserted a blocking variable there (and how, unless you were me, could you tell it was a blocking variable? I use blocking variables so that they can be "rolled back" via CLUAConsole, part of that "do no harm" thing - most intelligent modders would just put ~False()~ and remove it permanently. False is easy to spot - "X#JCleanViconia"=1 could just be someone else tagging onto Viconia's content, and setting a variable )


Ascension64 - way cool - for backwards compatibility I will set the states manually, but set up the code so it looks first for the .tpa/tph, that way it will work on pre-1.06 and on 1.06 and greater! The variable names are fine, I will use them however you set them up; and I am so glad to see all those "0"s...

I will try to get a Fixpacked set for you, too - I can compare manually with your list for inclusion in your work.

I think this might just do the trick!

[Ascension64]

Ascension64 - way cool - for backwards compatibility I will set the states manually, but set up the code so it looks first for the .tpa/tph, that way it will work on pre-1.06 and on 1.06 and greater! The variable names are fine, I will use them however you set them up; and I am so glad to see all those "0"s...

I will try to get a Fixpacked set for you, too - I can compare manually with your list for inclusion in your work.

I think this might just do the trick!

When you set up states manually, will that account for all combinations of previous compatibility (TDD, NeJ2, TS, BG2Fixpack) as well? There are gonig to be a lot of IFs there, I think.

Also, if you alter fluid states in IMOENJ, or IMOENP in any way, manually setting states isn't going to work so nicely (just trickier) for versions smaller than v1.06. This is because in v1.05b and lower, IMOEN2J and IMOEN2P are appended TWICE (once with all the BG2 dialogue of the IMOENJ and IMOENP equivalents, and once with the BG dialogue), and the order of things can go crazy when you append a dialogue twice in different files. In v1.06, I have changed this so that the BG stuff always goes after the BG2 stuff.

Basically, it is going to be tough to cater for mega-mod installs involving BGT v1.05b or less. It should be OK though to cater for a vanilla BGT v1.05b or lower install only though.

About all those "0"s, just remember they won't be 0 if someone installed NeJ2, TDD, and TS before BGT.

[cmorgan]

Ouch. Hadn't followed that thought all the way through.

Well, I guess it can't get *worse* for non-vanilla BGT players, so I guess just looking forwards will do the job.

Let me think.

I can leave things as they are with an approximation for v15, and release, and then begin building towards pre-BGT materials for v16, if you are a month or longer away from a v1.06 release.

By that, I mean I can change the in-project variables to match your variable names, and then set them as in Nythrun's code, taking into account regular and Fixpacked BGT. This puts us up one leg towards the goal.

For TDD, NeJ2, TS, they were not taken into account before, and instead install order and extra fixes were applied by Mega folks; given enough time, or some Mega people willing to follow some install directions and decompile files, I could create the same sort of "compatibility fixes" you have to in order to make things easier. Or I could just use Nythrun's implementation of your idea, and expand the variables to incorporate/look for those mods... wait a sec - if they are installed, then BGT will back them up and APPEND, because they won't be the same as in the BIF, right? If they create backups when BGT installs - well then we just solved that, right?

I'd better test.

As for Imoen, since Imoen only has one "fix" (the HappinesLT(0) thing pops up and stops her PID instead of triggering via BreakingPoint() on the P file), I can remove that fix and do the patching another way, probably an R_T or something on her file.

Then, when you release v1.06, I can release a v16 that uses your .tpa, and we can just say "hey - the best solution we can offer you is use BGT v1.06+, and BG1 NPC v16+, on any installs that place mods before the BGT installation".


What do you think, does this sound like it accounts for what we can do at the present time?


Only one suggestion - what do you think of changing the .tpa to something like

~BGT/Compat/TUTU/FluidStates.tpa~ or ~BGT/Compat/BG/FluidStates.tpa~ ?

I say this because I expect berelinde, Jastey, you, and I at the very least will want to be using this to make sure Tutu/BG stuff ends up on the right states in any cross-platform installers. I don't mind at all having the BG1NPC moniker in play, but it seems more open if it is not single mod directed.

[Edit>> ]
Here is what I was thinking might work for v15, as a temporary measure - including a base copy of your Fluidstates.tpa in BG1NPC for one version, until you have one that has it distributed:

INCLUDE ~BG1NPC/LIB/FluidStates.tpa~

/* Nythrun's, Ascension64's, and the bigg's Fluid State Solution: EdwinJ */
OUTER_SET BGTEDWINJState0 = 0
ACTION_IF FILE_EXISTS_IN_GAME ~AR7200.are~ THEN BEGIN
  ACTION_IF FILE_EXISTS ~bgt/backup/0/edwinj.dlg~ THEN BEGIN
	COPY - ~bgt/backup/0/edwinj.dlg~ ~nowhere~ //or inlined/BGT/etc??
	  READ_LONG 8 edwinj_num_states
  END
  ACTION_IF MOD_IS_INSTALLED ~setup-bg2fixpack.tp2~ "0" THEN BEGIN
	   OUTER_SET BGTEDWINJState0 = edwinj_num_states + 3
  END
END
OUTER_FOR (i1 = 0; i1 < 378; i1 += 1) BEGIN
  SET EVALUATE_BUFFER ~BGTEDWINJState%i1%~ = i1 + BGTEDWINJState0
END

It gets trickier with added stuff, but a sequence of stuff, I guess? It looks like they don't overlap,

BGTBCORANState0 = 0


oh heck. Yeah. To get everything going with a Mega, it would involve checking *ALL* the files this way.

Yuck.

Let me think about this again. I can get the vanilla/BGT stuff going, anyways, based on your FluidStates (this is alot faster than teh way i was doing it, installing and then decompiling anf then using WinMerge to diff thefiles...)

Edited by cmorgan, 16 January 2008 - 04:12 PM.

[Ascension64]

Ouch. Hadn't followed that thought all the way through.

Well, I guess it can't get *worse* for non-vanilla BGT players, so I guess just looking forwards will do the job.

Let me think.

I can leave things as they are with an approximation for v15, and release, and then begin building towards pre-BGT materials for v16, if you are a month or longer away from a v1.06 release.

By that, I mean I can change the in-project variables to match your variable names, and then set them as in Nythrun's code, taking into account regular and Fixpacked BGT. This puts us up one leg towards the goal.

I was actually thinking of being very crude to the mega-modders: release BGT v1.06 and BG1NPC v15 together, and say "you've gotta use these, or things just won't work out". I believe it is the simplest method without causing too much coding agony. Plus, you mentioned the mega-modders currently have their own fixes around, so they already have their bases covered. Anyway, v1.06 isn't far off -- there isn't much to do anymore. I'm waiting for some feedback on some Trad. Chinese language testing, but other than that, that's about it (apart from a few translators I'm not going to stop at the lights for).

For TDD, NeJ2, TS, they were not taken into account before, and instead install order and extra fixes were applied by Mega folks; given enough time, or some Mega people willing to follow some install directions and decompile files, I could create the same sort of "compatibility fixes" you have to in order to make things easier. Or I could just use Nythrun's implementation of your idea, and expand the variables to incorporate/look for those mods... wait a sec - if they are installed, then BGT will back them up and APPEND, because they won't be the same as in the BIF, right? If they create backups when BGT installs - well then we just solved that, right?

I would cash in on the possibility that the files end up being BIFFed. Certainly, for TDD and TS, the files are probably BIFFed. Again, probably easier to enforce mutual requirement of BGT v106+ with BG1NPCv15+.

As for Imoen, since Imoen only has one "fix" (the HappinesLT(0) thing pops up and stops her PID instead of triggering via BreakingPoint() on the P file), I can remove that fix and do the patching another way, probably an R_T or something on her file.

Then, when you release v1.06, I can release a v16 that uses your .tpa, and we can just say "hey - the best solution we can offer you is use BGT v1.06+, and BG1 NPC v16+, on any installs that place mods before the BGT installation".


What do you think, does this sound like it accounts for what we can do at the present time?

Yep, I like to KISS this goodbye!

Only one suggestion - what do you think of changing the .tpa to something like

~BGT/Compat/TUTU/FluidStates.tpa~ or ~BGT/Compat/BG/FluidStates.tpa~ ?

I say this because I expect berelinde, Jastey, you, and I at the very least will want to be using this to make sure Tutu/BG stuff ends up on the right states in any cross-platform installers. I don't mind at all having the BG1NPC moniker in play, but it seems more open if it is not single mod directed.

If you put the variables in tutu_cpm_vars.tph and simply set them all to 0, then that would do same thing, would it not? Just remember that when people are using Tutu, they aren't going to extract BGT to their directory...

[Edit>> ]
Here is what I was thinking might work for v15, as a temporary measure - including a base copy of your Fluidstates.tpa in BG1NPC for one version, until you have one that has it distributed:

INCLUDE ~BG1NPC/LIB/FluidStates.tpa~

/* Nythrun's, Ascension64's, and the bigg's Fluid State Solution: EdwinJ */
OUTER_SET BGTEDWINJState0 = 0
ACTION_IF FILE_EXISTS_IN_GAME ~AR7200.are~ THEN BEGIN
  ACTION_IF FILE_EXISTS ~bgt/backup/0/edwinj.dlg~ THEN BEGIN
	COPY - ~bgt/backup/0/edwinj.dlg~ ~nowhere~ //or inlined/BGT/etc??
	  READ_LONG 8 edwinj_num_states
  END
  ACTION_IF MOD_IS_INSTALLED ~setup-bg2fixpack.tp2~ "0" THEN BEGIN
	   OUTER_SET BGTEDWINJState0 = edwinj_num_states + 3
  END
END
OUTER_FOR (i1 = 0; i1 < 378; i1 += 1) BEGIN
  SET EVALUATE_BUFFER ~BGTEDWINJState%i1%~ = i1 + BGTEDWINJState0
END

It might not be useful to even have this, since I'm pretty close to releasing v1.06. Trouble not worth pursuing, since mega-modders already have their bases covered.

It gets trickier with added stuff, but a sequence of stuff, I guess? It looks like they don't overlap,

BGTBCORANState0 = 0


oh heck. Yeah. To get everything going with a Mega, it would involve checking *ALL* the files this way.

Yuck.

Let me think about this again. I can get the vanilla/BGT stuff going, anyways, based on your FluidStates (this is alot faster than teh way i was doing it, installing and then decompiling anf then using WinMerge to diff thefiles...)

Gets pretty repetitive, so I reckon one shouldn't bother with this and go straight for mutual compatibility.

[erebusant]

Well this topic is waaayyyyyyyy over my depth as far as dialogs are concerned, but as far as mega-mods are concerned, I don't really see an issue with some sort of a basic install requirement that BGT be the 1st big mod installed after either Fixpack or Baldurdash. After all, BGT is pretty much the tie point for being able to play from Candlekeep thru to the Throne, and if you don't have BGT in your install, you're not going to have BG1NPC. Frankly, if people are installing non-WeiDUized mods prior to BGT and WeiDU mods anymore, they really are asking for problems and serious bugs that can't be easily remedied. That's why in my installs I refuse to install anything that I know overwrites instead of patches, and why I spend so much time repairing overwriting mods so they will patch instead of overwriting, unless they are a known situation such as NEJ that I know overwrites and has some compatibility patches already in place and I can compensate for it.

[cmorgan]

Just to check, erebusant, that means that current "best practice" Megas place only Fixpack or Baldurdash before BGT?

If so, that massively simplifies some stuff

@Asension64, just to check, I think I missed something *huge* - when you are building the FluidStates.tpa, are you doing it dynamically, based on install?

In other words, are you doing all my work for me, so I don't have to look for a Fixpack number, all I have to do is do

//If Tutu
INCLUDE ~BG1NPC/Core/TutuFluidStates.tpa~ //everything set to 0

//If BGT
INCLUDE ~BGT/Compat/BG1NPC/FluidStates.tpa~

//Dialogues always appended
//OUTER_SET BGTBEDWINState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTBEDWINState%i1%~ = i1 + BGTEDWINJState0
END

//OUTER_SET BGTBJAHEIState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTBJAHEIState%i1%~ = i1 + BGTBJAHEIState0
END

//OUTER_SET BGTBMINSCState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTBMINSCState%i1%~ = i1 + BGTBMINSCState0
END

//OUTER_SET BGTBVICONIState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTBVICONIState%i1%~ = i1 + BGTBVICONIState0
END

//OUTER_SET BGTEDWINState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTEDWINState%i1%~ = i1 + BGTEDWINState0
END

//OUTER_SET BGTEDWINJState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTEDWINJState%i1%~ = i1 + BGTEDWINJState0
END

//OUTER_SET BGTEDWINPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTEDWINPState%i1%~ = i1 + BGTEDWINPState0
END

//OUTER_SET BGTIMOENState0 //Imoen's Pre-Joining file, right?
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTIMOENState%i1%~ = i1 + BGTIMOENState0
END

//OUTER_SET BGTIMOENJState0
Hey - I currently have this as OUTER_SPRINT "IMOEN_JOINED" "IMOEN2J" - is this heading for imoenJ.dlg or imoen2J.dlg???
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTIMOENJState%i1%~ = i1 + BGTIMOENJState0
END

//OUTER_SET BGTIMOENPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTIMOENPState%i1%~ = i1 + BGTIMOENPState0
END

//OUTER_SET BGTJAHEIJState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTJAHEIJState%i1%~ = i1 + BGTJAHEIJState0
END

//OUTER_SET BGTJAHEIPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTJAHEIPState%i1%~ = i1 + BGTJAHEIPState0
END

//OUTER_SET BGTMINSCJState0 = 241
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTMINSCJState%i1%~ = i1 + BGTMINSCJState0
END

//OUTER_SET BGTMINSCPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTMINSCPState%i1%~ = i1 + BGTMINSCPState0
END

//OUTER_SET BGTVICONIJState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTVICONIJState%i1%~ = i1 + BGTVICONIJState0
END

//OUTER_SET BGTVICONIPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTVICONIPState%i1%~ = i1 + BGTVICONIPState0
END

//Never Ending Journey 2 compatibility appending
//OUTER_SET BGTXANState0 = 0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTXANState%i1%~ = i1 + BGTXANState0
END

//The Darkest Day compatibility appending
//OUTER_SET BGTKAGAIPState0 = 0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTKAGAIPState%i1%~ = i1 + BGTKAGAIPState0
END

//OUTER_SET BGTKIVANPState0 = 0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTKIVANPState%i1%~ = i1 + BGTKIVANPState0
END

//OUTER_SET BGTSHARTPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTSHARTPState%i1%~ = i1 + BGTSHARTPState0
END

//OUTER_SET BGTXZARPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTXZARPState%i1%~ = i1 + BGTXZARPState0
END

//OUTER_SET BGTYESLIPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTYESLIPState%i1%~ = i1 + BGTYESLIPState0
END

//Tortured Souls compatibility appending
//OUTER_SET BGTBCORANState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTBCORANState%i1%~ = i1 + BGTBCORANState0
END

//OUTER_SET BGTCORANState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTCORANState%i1%~ = i1 + BGTCORANState0
END

//OUTER_SET BGTCORANJState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTCORANJState%i1%~ = i1 + BGTCORANJState0
END

//OUTER_SET BGTCORANPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTCORANPState%i1%~ = i1 + BGTCORANPState0
END

//OUTER_SET BGTDYNAHJState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTDYNAHJState%i1%~ = i1 + BGTDYNAHJState0
END

//OUTER_SET BGTDYNAHPState0
OUTER_FOR (i1 = 0; i1 < #of DialogueStatesNeededFromOriginal ; i1 += 1) BEGIN
SET EVALUATE_BUFFER ~BGTDYNAHPState%i1%~ = i1 + BGTDYNAHPState0
END


?? Do I understand correctly, that I would need no additional checks for anything installed -
(and does that code look correct, where we take a variable and then add to it and toss it back on, or do I need another manipulation?)

If so, I owe you a bottle of scotch...

Edited by cmorgan, 16 January 2008 - 07:10 PM.

[erebusant]

Just to check, erebusant, that means that current "best practice" Megas place only Fixpack or Baldurdash before BGT?

As far as I'm concerned. When beginning something, it's always "best practice" to begin at the beginning,,, .

Basic 26498 patched install + Fixpack fixes, then BG1 via BGT's engine conversion, then NEJ if it's going to be added, because even using v691 there has been at least a little bit of effort to be compatible with BGT, and is in fact at this point even supported on Vlad's forum with BGT as a part of it's core install (with certain installation constraints). Follow that immediately with BG1NPC and any associated mods, then anything else of a WM6 and above type flavor to complete your core install, then your quest, itm, npc, & AI mods of any type that will make changes to the beginning of your game (ie;BG1 portion) then quest, itm, npc and AI mods of any type that will make changes to the BG2 portion of your game, followed by BP and ending with any tweaks and late install recommended mods, and ending with the WM.

I think that at some point it needs to become inherent upon other mods and their makers to create their mods in as compatible a manner as possible, but also bear in mind that it just makes sense to install particular mods in a particular order.

[Ascension64]

Just to check, erebusant, that means that current "best practice" Megas place only Fixpack or Baldurdash before BGT?

As far as I'm concerned. When beginning something, it's always "best practice" to begin at the beginning,,, .

Basic 26498 patched install + Fixpack fixes, then BG1 via BGT's engine conversion, then NEJ if it's going to be added, because even using v691 there has been at least a little bit of effort to be compatible with BGT, and is in fact at this point even supported on Vlad's forum with BGT as a part of it's core install (with certain installation constraints). Follow that immediately with BG1NPC and any associated mods, then anything else of a WM6 and above type flavor to complete your core install, then your quest, itm, npc, & AI mods of any type that will make changes to the beginning of your game (ie;BG1 portion) then quest, itm, npc and AI mods of any type that will make changes to the BG2 portion of your game, followed by BP and ending with any tweaks and late install recommended mods, and ending with the WM.

I think that at some point it needs to become inherent upon other mods and their makers to create their mods in as compatible a manner as possible, but also bear in mind that it just makes sense to install particular mods in a particular order.

Since you still can install NeJ2, TS-BP, TDD, SoS, RoT, and CtB before BGT, I'm going to maintain compatibility with these forms of installation, regardless of what people's preferences are. This was the way KD and I agreed upon during the early stages of implementing compatibility between the core mega-modification modifications.

@Asension64, just to check, I think I missed something *huge* - when you are building the FluidStates.tpa, are you doing it dynamically, based on install?

Yes, what numbers appear in FluidStates.tpa will depend on everything that is installed before BGT-WeiDU, meaning you don't have to worry about any mod installed before BGT. Sorry, I'mm not a Scotch drinker... though some OJ would be nice.

P.S. All the variable names are based on the BG1 dialogue file name. The BGT dialogue file names (as per bgt_cpm_vars.tph in its current state) still need to be used when referring to the dialogues themselves, i.e. yes, IMOENJ in BGT should be referred to as IMOEN2J, JAHEIJ in BGT should be referred to as JAHEIRAJ, and Kulyok's favourite XAN in BGT should be referred to as BGXAN

Edited by Ascension64, 16 January 2008 - 09:17 PM.

[cmorgan]

Holy cow. You just made my life so much easier, and I think the code above just needs me to do some minor editing/filling in (and I need to do the I_C_T research on the additional files), and we have a real ballgame!

(Sorry - didn't get back to edit the thread when I realized you were using %SOURCE_RES% not %DEST_RES% - I understand.)

I will start figuring out how to send you the OJ - and I should be able to produce a working v15 by the end of this weekend or early next week that reflects this. Absolutely top rate - thank you very, very much!!!

[Ascension64]

OK, here are the variable names you can use for all meeting, post, joined, and banter dialogues. It'll save you from remembering which dialogues need fluid state treatment and which don't if you assume that all of them do.

In simplest terms, the variables are named BGT<BG1 dialogue file name>State0.

Just remember that when you deal with the files themselves, you still need to refer ot their BGT file names (and you can use the existing CPM variables for it),

e.g. ADD_STATE_TRIGGER ~%tutu_scriptbg%VICONI~ %BGTVICONIState0%~ ~True()~
will add to BGVICONI.DLG at the equivalent of BG1 state 0 the True() trigger.

That example is too simple, but you obviously need to compute what absolute state you want to change (as per Nythrun's code) in the .tp2 and EVALUATE_BUFFER the .d file.

//Dialogues always appended
OUTER_SET BGTBEDWINState0 = 0
OUTER_SET BGTBJAHEIState0 = 0
OUTER_SET BGTBMINSCState0 = 0
OUTER_SET BGTBVICONIState0 = 0

OUTER_SET BGTEDWINState0 = 0
OUTER_SET BGTEDWINJState0 = 0
OUTER_SET BGTEDWINPState0 = 0

OUTER_SET BGTIMOENState0 = 0
OUTER_SET BGTIMOENJState0 = 0
OUTER_SET BGTIMOENPState0 = 0

OUTER_SET BGTJAHEIJState0 = 0
OUTER_SET BGTJAHEIPState0 = 0

OUTER_SET BGTMINSCJState0 = 0
OUTER_SET BGTMINSCPState0 = 0

OUTER_SET BGTVICONIJState0 = 0
OUTER_SET BGTVICONIPState0 = 0


//Never Ending Journey 2 compatibility appending
OUTER_SET BGTXANState0 = 0


//The Darkest Day compatibility appending
OUTER_SET BGTKAGAIPState0 = 0
OUTER_SET BGTKIVANPState0 = 0
OUTER_SET BGTSHARTPState0 = 0
OUTER_SET BGTXZARPState0 = 0
OUTER_SET BGTYESLIPState0 = 0


//Tortured Souls compatibility appending
OUTER_SET BGTBCORANState0 = 0

OUTER_SET BGTCORANState0 = 0
OUTER_SET BGTCORANJState0 = 0
OUTER_SET BGTCORANPState0 = 0

OUTER_SET BGTDYNAHJState0 = 0
OUTER_SET BGTDYNAHPState0 = 0


//Dialogues always new
/* banter */
OUTER_SET BGTBAJANTState0 = 0
OUTER_SET BGTBALORAState0 = 0
OUTER_SET BGTBBRANWState0 = 0
//BCORAN - append if TS detected
OUTER_SET BGTBDYNAHState0 = 0
OUTER_SET BGTBELDOTState0 = 0
//BEDWIN - always appended
OUTER_SET BGTBFALDOState0 = 0
OUTER_SET BGTBGARRIState0 = 0
OUTER_SET BGTBIMOENState0 = 0
//BJAHEI - always appended
OUTER_SET BGTBKAGAIState0 = 0
OUTER_SET BGTBKHALIState0 = 0
OUTER_SET BGTBKIVANState0 = 0
//BMINSC - always appended
OUTER_SET BGTBMONTAState0 = 0
OUTER_SET BGTBQUAYLState0 = 0
OUTER_SET BGTBSAFANState0 = 0
OUTER_SET BGTBSHARTState0 = 0
OUTER_SET BGTBSKIEState0 = 0
OUTER_SET BGTBTIAXState0 = 0
//BVICONI - always appended
OUTER_SET BGTBXANNNState0 = 0
OUTER_SET BGTBXZARState0 = 0
OUTER_SET BGTBYESLIState0 = 0

/* joined */
OUTER_SET BGTAJANTJState0 = 0
OUTER_SET BGTALORAJState0 = 0
OUTER_SET BGTBRANWJState0 = 0
//CORANJ - append if TS detected
//DYNAHJ - append if TS detected
//EDWINJ - always appended
OUTER_SET BGTELDOTJState0 = 0
OUTER_SET BGTFALDOJState0 = 0
OUTER_SET BGTGARRIJState0 = 0
//IMOENJ - always appended
//JAHEIJ - always appended
OUTER_SET BGTKAGAIJState0 = 0
OUTER_SET BGTKHALIJState0 = 0
OUTER_SET BGTKIVANJState0 = 0
//MINSCJ - always appended
OUTER_SET BGTMONTAJState0 = 0
OUTER_SET BGTQUAYLJState0 = 0
OUTER_SET BGTSAFANJState0 = 0
OUTER_SET BGTSHARTJState0 = 0
OUTER_SET BGTSKIEJState0 = 0
OUTER_SET BGTTIAXJState0 = 0
//VICONIJ - always appended
OUTER_SET BGTXANJState0 = 0
OUTER_SET BGTXZARJState0 = 0
OUTER_SET BGTYESLIJState0 = 0

/* meeting */
OUTER_SET BGTAJANTIState0 = 0
OUTER_SET BGTALORAState0 = 0
OUTER_SET BGTBRANWEState0 = 0
//CORAN - append if TS detected
OUTER_SET BGTDYNAHEState0 = 0
//EDWIN - always appended
OUTER_SET BGTELDOTHState0 = 0
OUTER_SET BGTFALDORState0 = 0
OUTER_SET BGTGARRICState0 = 0
//IMOEN - always appended
OUTER_SET BGTJAHEIRState0 = 0
OUTER_SET BGTKAGAINState0 = 0
OUTER_SET BGTKHALIDState0 = 0
OUTER_SET BGTKIVANState0 = 0
OUTER_SET BGTMINSCState0 = 0
OUTER_SET BGTMONTARState0 = 0
OUTER_SET BGTQUAYLEState0 = 0
OUTER_SET BGTSAFANAState0 = 0
OUTER_SET BGTSHARTEState0 = 0
OUTER_SET BGTSKIEState0 = 0
OUTER_SET BGTTIAXState0 = 0
OUTER_SET BGTVICONIState0 = 0
//XAN - append if NeJ2 detected
OUTER_SET BGTXZARState0 = 0
OUTER_SET BGTYESLICState0 = 0

/* post */
OUTER_SET BGTAJANTPState0 = 0
OUTER_SET BGTALORAPState0 = 0
OUTER_SET BGTBRANWPState0 = 0
//CORANP - append if TS detected
//DYNAHP - append if TS detected
//EDWINP - always appended
OUTER_SET BGTELDOTPState0 = 0
OUTER_SET BGTFALDOPState0 = 0
OUTER_SET BGTGARRIPState0 = 0
//IMOENP - always appended
//JAHEIP - always appended
//KAGAIP - append if TDD detected
OUTER_SET BGTKHALIPState0 = 0
//KIVANP - append if TDD detected
//MINSCP - always appended
OUTER_SET BGTMONTAPState0 = 0
OUTER_SET BGTQUAYLPState0 = 0
OUTER_SET BGTSAFANPState0 = 0
//SHARTP - append if TDD detected
OUTER_SET BGTSKIEPState0 = 0
OUTER_SET BGTTIAXPState0 = 0
//VICONIP - always appended
OUTER_SET BGTXANPState0 = 0
//XZARP - append if TDD detected
//YESLIP - append if TDD detected

Edited by Ascension64, 22 January 2008 - 07:03 PM.

[cmorgan]

Got it - (the file presented is for Tutu if I am seeing correctly).

Code crosscheck, please:

within Tutu, currently I have added to BG1NPC\lib\g3_tutu_cpmvars.tpa

//BGT Dialogues always appended
OUTER_SET BGTBEDWINState0 = 0
OUTER_SET BGTBJAHEIState0 = 0
OUTER_SET BGTBMINSCState0 = 0
OUTER_SET BGTBVICONIState0 = 0
OUTER_SET BGTEDWINState0 = 0
OUTER_SET BGTEDWINJState0 = 0
OUTER_SET BGTEDWINPState0 = 0
OUTER_SET BGTIMOENState0 = 0
OUTER_SET BGTIMOENJState0 = 0
OUTER_SET BGTIMOENPState0 = 0
OUTER_SET BGTJAHEIJState0 = 0
OUTER_SET BGTJAHEIPState0 = 0
OUTER_SET BGTMINSCJState0 = 0
OUTER_SET BGTMINSCPState0 = 0
OUTER_SET BGTVICONIJState0 = 0
OUTER_SET BGTVICONIPState0 = 0

//Never Ending Journey 2 compatibility appending
OUTER_SET BGTXANState0 = 0

//The Darkest Day compatibility appending
OUTER_SET BGTKAGAIPState0 = 0
OUTER_SET BGTKIVANPState0 = 0
OUTER_SET BGTSHARTPState0 = 0
OUTER_SET BGTXZARPState0 = 0
OUTER_SET BGTYESLIPState0 = 0

//Tortured Souls compatibility appending
OUTER_SET BGTBCORANState0 = 0
OUTER_SET BGTCORANState0 = 0
OUTER_SET BGTCORANJState0 = 0
OUTER_SET BGTCORANPState0 = 0
OUTER_SET BGTDYNAHJState0 = 0
OUTER_SET BGTDYNAHPState0 = 0

and in BG1NPC\lib\g3_bgt_cpmvars.tpa

ACTION_IF FILE_EXISTS ~BGT/Compat/BG1NPC/FluidStates.tpa~ THEN BEGIN
	INCLUDE ~BGT/Compat/BG1NPC/FluidStates.tpa~
  END ELSE BEGIN
	//BGT Dialogues always appended
	OUTER_SET BGTBEDWINState0 = 106
	OUTER_SET BGTBJAHEIState0 = 461
	OUTER_SET BGTBMINSCState0 = 99
	OUTER_SET BGTBVICONIState0 = 575
	OUTER_SET BGTEDWINState0 = 74
	OUTER_SET BGTEDWINJState0 = 188
	OUTER_SET BGTEDWINPState0 = 9
	OUTER_SET BGTIMOENState0 = 26
	OUTER_SET BGTIMOENJState0 = 111
	OUTER_SET BGTIMOENPState0 = 16
	OUTER_SET BGTJAHEIJState0 = 531
	OUTER_SET BGTJAHEIPState0 = 74
	OUTER_SET BGTMINSCJState0 = 241
	OUTER_SET BGTMINSCPState0 = 10
	OUTER_SET BGTVICONIJState0 = 183
	OUTER_SET BGTVICONIPState0 = 14
	
	//Never Ending Journey 2 compatibility appending
	OUTER_SET BGTXANState0 = 0
	
	//The Darkest Day compatibility appending
	OUTER_SET BGTKAGAIPState0 = 0
	OUTER_SET BGTKIVANPState0 = 0
	OUTER_SET BGTSHARTPState0 = 0
	OUTER_SET BGTXZARPState0 = 0
	OUTER_SET BGTYESLIPState0 = 0
	
	//Tortured Souls compatibility appending
	OUTER_SET BGTBCORANState0 = 0
	OUTER_SET BGTCORANState0 = 0
	OUTER_SET BGTCORANJState0 = 0
	OUTER_SET BGTCORANPState0 = 0
	OUTER_SET BGTDYNAHJState0 = 0
	OUTER_SET BGTDYNAHPState0 = 0
  END

This is processed by the .tp2...

ALWAYS
  ACTION_IF FILE_EXISTS_IN_GAME ~FW0100.are~ THEN BEGIN
	/* Tell the player it is using Tutu stuff */
	PRINT @1000
	INCLUDE ~BG1NPC\lib\g3_tutu_cpmvars.tpa~
  END ELSE BEGIN
	ACTION_IF FILE_EXISTS_IN_GAME ~AR7200.are~ THEN BEGIN
	  /* Tell the player it is using BGT stuff */
	  PRINT @1001
	  INCLUDE ~BG1NPC\lib\g3_bgt_cpmvars.tpa~
	  /* Tell the player it is not Tutu or BGT */
	  END ELSE BEGIN FAIL @1002
	END
  END
  //OUTER_SET BGTBEDWINState0, vanilla _EDWIN = 16 states {0-15}
  OUTER_FOR (cpv = 0; cpv < 17; cpv += 1) BEGIN
	SET EVALUATE_BUFFER ~BGTBEDWINState%cpv%~ = cpv + BGTBEDWINState0
  END
  //OUTER_SET BGTBJAHEIState0 vanilla _BJAHEI = 9 states {0-8}
  OUTER_FOR (cpv = 0; cpv < 10; cpv += 1) BEGIN
	SET EVALUATE_BUFFER ~BGTBJAHEIState%cpv%~ = cpv + BGTBJAHEIState0
  END
  //OUTER_SET BGTBMINSCState0 vanilla _BMINSC = 9 states {0-8} 
  OUTER_FOR (cpv = 0; cpv < 10; cpv += 1) BEGIN
	SET EVALUATE_BUFFER ~BGTBMINSCState%cpv%~ = cpv + BGTBMINSCState0
  END
  //OUTER_SET BGTBVICONIState0 vanilla _BVICON = 13 states {0-12} 
  OUTER_FOR (cpv = 0; cpv < 14; cpv += 1) BEGIN
	SET EVALUATE_BUFFER ~BGTBVICONIState%cpv%~ = cpv + BGTBVICONIState0
  END
  //OUTER_SET BGTEDWINState0 vanilla _EDWIN = 29 states {0-28} 
  OUTER_FOR (cpv = 0; cpv < 30; cpv += 1) BEGIN
	SET EVALUATE_BUFFER ~BGTEDWINState%cpv%~ = cpv + BGTEDWINState0
  END


and so forth...

but I now need to go back and recheck against that new information (I never looked at Ajantis, for example... one helluvu lot of recoding for various I_C_Ts and INTERJECTS and COPY_TRANS etc.)


If I understand this correctly, and you don't see a problem with my math above, then I need to set each clip into regular dialogue

from

IF ~~ ImJa2
SAY @188
COPY_TRANS ~%tutu_var%JAHEIR~ 7
END

to

IF ~~ ImJa2
SAY @188
COPY_TRANS ~%tutu_var%JAHEIR~ %BGTJAHEIRState7%
END

and

INTERJECT ~%tutu_var%MINSC~ %BGTMINSCState5%  X#MinscImoenJoin3
== ~%IMOEN_JOINED%~ IF ~InParty("%IMOEN_DV%") InMyArea("%IMOEN_DV%") !StateCheck("%IMOEN_DV%",CD_STATE_NOTVALID) Gender(Player1,MALE) !Class(Player1,MAGE_ALL) !Class(Player1,CLERIC_ALL) !Class(Player1,BARD_ALL) !Class(Player1,DRUID_ALL)~ THEN @142
= @143
END
++ @145 EXTERN ~%IMOEN_JOINED%~ ImMi2
++ @146 EXTERN ~%IMOEN_JOINED%~ ImMi1

CHAIN ~%IMOEN_JOINED%~ ImMi1
@147
== ~%tutu_var%MINSC~ @144
COPY_TRANS ~%tutu_var%MINSC~ %BGTMINSCState5%

CHAIN ~%IMOEN_JOINED%~ ImMi2
@148
== ~%tutu_var%MINSC~ @144
COPY_TRANS ~%tutu_var%MINSC~ %BGTMINSCState5%

do I have all this code right, as far as you can see?

[Ascension64]

Looks good. If you are only concerned about the compatibility ones, then don't worry about the extra ones that are always 0. I just thought it might make it easier to assume all have fluid states, but it appears that it is going to make it a lot harder, because you have to re-code loads of things.