28 replies to this topic

[Qwinn]

It appears that there is a hard limit to the number of global (possibly -any-, but definitely at least global) variables that the game can read from the VAR.VAR file. Version 4.0 as I was going to release it rides the limit pretty close... I found that if I added a few more, then ones at the end of the list simply dropped off, which would cause my save games to crash, because the save games contain values for variables that no longer exist in the game.

So, I went through the variables I add and made them local variables where I can. But that may not be enough, it may be that there's a limit on the *total* number of variables, local and global combined, but the missing local variables don't cause a crash when loading a save game that has those variables unless you're in that specific area.

So I came up with a new macro that, instead of adding variables, deletes them. I'm adding this to the Fixpack, which will mean that v4.0 will NOT be compatible with any save games that came before. The purpose of this thread is to document which variables I'm deleting.

If someone later wants to do a mod where they actually make use of such stored information (on the assumption that if they wrote the variables, that demonstrates at least some intent to do something with them that was just never implemented), knock yourselves out, just let me know on this thread and I'll stop deleting them. No longer deleting the variables wouldn't cause any save game compatibility issues going forward. But, for now, if the variables serve no purpose whatsoever, better to remove them and reduce the possibility of hitting that hard limit.

There are *tons* of either totally unused or "written but never read" variables in PS:T. I know I've noticed a great many in my fixing stuff. So if you're planning on modding, don't let "I don't want to deal with running out of variables" dissuade you, there'll be plenty of useless variables we can delete for almost anything (within reason) that you want to do, just let me know how many you need and I'll hunt 'em down.

Qwinn

Edited by Qwinn, 28 December 2009 - 12:51 AM.

[Qwinn]

Global variables that are duplicated in the vanilla VAR.VAR, so I remove one of the entries:

1. "Annah_Accuse"
2. "Chad_Talked"
3. "Chaotic_Fhjull_1"
4. "Chaotic_Penn_1"
5. "Evil_Bedai_1"
6. "Evil_Bedai_2"
7. "Evil_Bedai_3"
8. "Evil_Bedai_4"
9. "Evil_Bedai_5"
10. "Evil_Thorp_1"
11. "Good_Bedai_1"
12. "Good_Bedai_2"
13. "Good_Bedai_3"
14. "Good_Bedai_4"
15. "Good_Thorp_1"
16. "Good_Yellow_2"
17. "Know_Director_Truth"
18. "Know_Ojo"
19. "Nature"
20. "Lawful_Bedai_1"
21. "Lawful_Bedai_2"

Global variables that are apparently never read or written:

1. "Alley_Puzzle2_SC"
2. "Ambush"
3. "Anarchist_Recruitment"
4. "Arbwarning"
5. "Chapel"
6. "Complete_Alley"
7. "Dhall_Styx"
8. "Eli_Location"
9. "Fort_Descriptor"
10. "Lady_Location"
11. "Pox_To_Mortuary"
12. "QuiSai_Location"
13. "Smoldering_Corpse"
14. "Superghoul"
15. "Undead_Pissed_A"
16. "Undead_Pissed_B"
17. "Undead_Pissed_C"

Global variables that are written but never read:

1. "Absorb_Practical_Incarnation": Obvious. Never read.
2. "Absorb_Paranoid_Incarnation": Obvious. Never read.
3. "Absorb_Good_Incarnation": Obvious. Never read.
4. "Alley_Puzzle1_SC": Set almost everywhere in the dialogue of the boards you need to pry in Pregnant Alley. Never read.
5. "Await_Death_Answer": tracks your response to Awaiting Death when he asks you why you want to die. Never read.
6. "Await_Life_Answer": tracks your response to Awaiting Death when he asks you why you want to live. Never read.
7. "Curst_Loot": set if you just say farewell to the looters in Carceri. Nothing happens, though, and variable is never read.
8. "Deionarra_SS_Annah": set if Annah is the one to comfort you at the Longing memory stone. There's a similar one for Grace that does get used, but Annah's never does.
9. "Doubtful_Answer": set when you tell the Doubtful Skeleton in Dead Nations whether he should accept the True Death or keep on living. Has no effect, never read.
10. "Know_Iannis_Loss": set when Dustmen mourners tell you they are mourning Iannis's loss. Never read.
11. "Red_Shroud": set when the transformed Ilquix and Grace discuss Grace's mother. Never read.
12. "Surrendered": set simultaneously with Game_Over. Never read.
13. "Trias_Cause": set when Tek'elach tells you that Trias is responsible for certain troubles. Never read. (The state where this variable is set is actually inaccessible until Fixpack v4.0.)
14. "Trias_Curse": set when you break your vow and Trias curses you as you kill him. Never read.
15. "Warning_Dhall": set when Morte complains to you as you first approach Dhall. Never read.

Global variables that are read but never written:

1. "Feign_Death": Checked in Pox's dialogue. If this were set, then you could pretend to be dead successfully even if you failed the (easy) charisma check. Never actually set anywhere though.
2. "Token": Checked in Bedai and Foundry Guard's dialogues, but never written. Seems meant to track if you got (or lost) Godsman token, but elsewhere this is checked by simply looking for the item in inventory.

Global variables that are read and written, but totally useless:

1. "Alley": In a female Hiver dialogue, when she tells you where the Alley of Dangerous Angles is. Has no in game effect whatsoever.

Qwinn

Edited by Qwinn, 29 December 2009 - 12:11 AM.

[Qwinn]

Bleah. Looks like I have to give "Alpha", "Beta", "Delta" and "Epsilon" back. Deleting any one of them causes the game to crash when you try to view the journal. Looks like those variables got reused in the engine.

Qwinn

Edited by Qwinn, 28 December 2009 - 03:11 AM.

[SimDing0]

Got there before me. As a quick sanity check, it might be worth firing up a hex editor and scouring the EXE for each variable name before you delete it. We know PST has a lot of hardcoded shit, and I imagine embedding variable dependencies in the binary is not beyond it.

[SimDing0]

(Indidentally, for what it's worth, I'm very impressed with all the good work that's gone on here.)

[Qwinn]

Yep, did the EXE search thing. Unfortunately, a non-case-sensitive text search for "Alpha", "Beta", "Delta" or "Epsilon" doesn't actually turn up anything relevant in the engine. There are definitely a number of variable dependencies in the EXE, and some of them are findable via a text search in a hex editor, but they aren't always. So it's a matter of testing on some of these to see if removing them causes a problem. My experience with all this so far suggests to me that if a variable -is- dependent in the engine, it's generally something that'll cause a crash pretty quickly if you take it out.

Of the ones I've added to the list above, the only ones I think there's more than a 1% chance they might be used in the engine are the "Undead_Pissed" and "Gamma" variables. For those, maybe 2%. I'll be testing just in case.

I think the above list frees up enough variable slots for anything else I might want to do for version 4.0, so I'm going to freeze my variable deletion there. That lets me start a new test game where I can be somewhat assured I won't need to blow up my saves.

And thanks a lot for the kind words Sim

Qwinn

Edited by Qwinn, 28 December 2009 - 06:34 AM.

[rtr86]

There are *tons* of either totally unused or "written but never read" variables in PS:T.

Would these variables take up system resources to process? I know most systems today can handle PS:T with ease but even so, could these 'useless' variables cause any conflicts etc which may result it some sort of corruption? Would getting rid of them all be to much work to help make PS:T even more 'sleeker'?

Edited by rtr86, 28 December 2009 - 07:54 AM.

[Qwinn]

I don't think deleting variables will have any significant impact on processing speed whatsoever, if that's what you're asking. I think the time spent processing these is negligible. But as -resources-, meaning there's a limited total possible and they need to be conserved, yes, I think it's worth cleaning out the underbrush.

And I lied when I said I was done. I'm going to give it another few hours of work adding to the list (already have)... this is painful and boring enough that I don't ever want to have to go through it again, not to mention needing to test that removing them doesn't cause any unexpected weirdness, and lastly that if I need to do this again that'll be a whole 'nother slew of save games I'll be invalidating. So, screw it, I'll try to be thorough about it on this one pass and get all the low hanging fruit possible, and hopefully we'll never need to do this again.

Qwinn

[Markus Ramikin]

Ooh, I foresee a lot of bugs and problems that will take forever to fix.

*ever the optimist*

[Qwinn]

It's possible there will be bugs, but "forever to fix" isn't going to happen. If a new bug occurs it'll be very easy for me to determine that it is caused by a deleted variable and then only a process of elimination to figure out which one, and the solution is: stop deleting that variable.

Qwinn

[Qwinn]

Yep, did the EXE search thing. Unfortunately, a non-case-sensitive text search for "Alpha", "Beta", "Delta" or "Epsilon" doesn't actually turn up anything relevant in the engine.

These guys are quests.ini (all those referenced variables for their silly quest toggles need to exist and be working).

Nice catch! You are correct. Should've thought to look there. And man, now that I see it, they really went nuts making it so the journal updates properly for this quest no matter what you do. I can see why they didn't use the FedEx variable now, that could get updated and change the "completed" text of an earlier leg of the delivery chain to a new one. Okay. Won't touch any of these then.

I'll check Quests.INI to make sure none of the variables I am removing are referenced there. Again, nice catch.

EDIT: Bah, yeah, gotta take BoxLeft off the list too, that one is referenced in Quests.INI as well.

EDIT 2: Checked all the rest, no other references in Quests.INI. Phew. This actually makes me feel a lot better, as there is now no evidence of variables being called by the engine that I can't find in a hex search. Now that I've been reminded to check Quests.INI, I think I've got a good list for checking where -any- variable could potentially be checked.

Qwinn

Edited by Qwinn, 28 December 2009 - 02:32 PM.

[Qwinn]

I'm not sure that the duplicate entries work against the hard limit, but they might depending on how the engine read of the table was coded.

I would suggest not overwriting those entries... I don't know if you're just writing to the specific location of the vanilla VAR.VAR or if you're looking for the variable name first, but either way, yeah, that method puts them out of order, and if you try it after v4.0, it will overwrite the -only- instance of the variable in the list, which would be bad.

Please feel free to use my macros for adding/removing variables. (If you wait a few days for 4.0 to be released, you can get the most updated version that includes the Delete macro, or I can PM it if you're in a hurry). It will find the proper alphabetical place to add your new variable and insert the bytes there, which is nice when you need to look a variable up. If you tell it to add a variable that already exists, it won't create a duplicate. Calling the macro is really simple. In this case, adding your MEMPA_RING variable, the entire process would be:

INCLUDE ~PST-Fix/utils/Q_VARMacros.tph~

COPY_EXISTING ~VAR.VAR~ ~VAR.TMP~
  SET Q_FileSize = %SOURCE_SIZE%

  SPRINT "Q_NewVarType"  ~GLOBAL  ~
  SPRINT "Q_NewVarName"  ~MEMPA_RING				  ~
  SET	Q_NewVarValue = 0
  LAUNCH_PATCH_MACRO Q_VarVar_AddNewRecord

 BUT_ONLY_IF_IT_CHANGES
COPY ~VAR.TMP~ ~VAR.VAR~

That's it. The only thing to be sure of is to pad the two variable sets with SPRINT with the proper amount of spaces (total length 8 for the type, 32 for the name).

And yes, if you don't mind, I would like to do the fix for the item dialogue you pointed out in my Fixpack, I wasn't aware of it before this. Any objection to me using that same variable name (MEMPA_RING)?

Nice to finally see someone else getting into the PS:T content modding game!

Qwinn

Edited by Qwinn, 28 December 2009 - 03:05 PM.

[Qwinn]

(BTW, recent builds of NI should work a bit nicer with Planescape, although we don't have a compiled .jar up anywhere yet. It should make your work slightly more friendly, as well as anybody else who wants to mod for PST without resorting to DLTCEP.)

Sounds great... so when is it due to be released? Or if you'd like some testing, well, you know I'd beat the hell out of it.

And after review, I'm just going to call the variable that tracks if you've talked to the FINGER item and DFINGER dialogue "Finger", to make it easier to connect the variable to the dialogue and item.

Qwinn

Edited by Qwinn, 29 December 2009 - 12:27 AM.

[Qwinn]

And okay, now I really am done with deletions... that's 35 up there, and that should hopefully be enough for a long, long, long time. (And that's assuming that removing the duplicate variable entries doesn't help at all).

Qwinn

Edited by Qwinn, 29 December 2009 - 12:11 AM.

[Qwinn]

That'd be cool, thanks. BTW, if you're assuming I know who you are at this point, afraid not

Qwinn

[ghostdog]

if you're assuming I know who you are at this point, afraid not

Maybe it's Santa

Seriously, it's good to know that at least someone is still working on a new build of Near Infinity. Can I get one copy too ?