29 replies to this topic

[Vandervecken]

More info:
I thought it might have to do with timer variables, so I removed all 284, and compared speed to removing the first 284 variables alphabetically. Same effect.
Then I thought it might have to do with the number of variables I removed. Here is the dramatic result:

Number removed seconds for 10 runs through baldur.bcs
0 11s
10 8.4s
20 8.2s
30 7.85
40 7.3
50 7.08
60 6.22
70 6.14
80 6.20
90 6.03
100 5.90

284 5.50
2000 (i.e. the save from early time) 5.50s

So it looks like there's some weird threshold for global variables where things slow down dramatically and suddenly.
This analysis works btw whether I use the top or bottom of the list to remove from.
Why might this be?

Edited by Vandervecken, 09 August 2009 - 04:38 PM.

[Vandervecken]

What if I culled GLOBAL variables with the following technique:

Start a new BG2 game, make a list of all global variables.
Make a list of all global variables from a savegame just before I leave BG1 for BG2.
Subtract list 1 from list 2, call it list 3
This leaves all global variables defined in BG1 that don't show up in a new game of BG2.
AFAIK there is no mod that transfers information from BG1 to BG2, except for the NPC mods. Those Mods have info about the NPCs stored in the Out of Party NPC section of the save game.

If the above statement is correct, all I have to do is remove the globals in list 3 from the stuttering savegame.

Ideas? suggestions?

EDIT: I should of course add that the variables in list 3 would only be removed from the stuttering save if their values are identical in both the stuttering save and list 3.
I have found some variables where this is not the case.
I have also been saving some variables that seem useful to save. List follows:
bansheefear - different values
BW_02 variables - the BW herbs mod is a BG1/2 crossmod.
ChloeSpawn - What is the NPC Chloe doing in BG1? Unless this is a different Chloe. Better to save just in case.
DMWWPHASE - a timer which hasn't stopped - to do with Phase spiders. Seems to be clocking up the minutes for some reason. Someone should look into pspider.bcs to see why it isn't being zeroed out.
DMWWzoneofsweetair - timer
dreamtimerstarted - seemed important
DSOTSC - seemed important
Fear - runaway timer?
goldenpantaloons - seemed important since I have kept them
malison - runaway timer?
partygobyebyenow - different values. What is this for I don't know

I am up to S but S is an awfully big job.

Edited by Vandervecken, 09 August 2009 - 10:55 PM.

[Chevalier]

Thanks Vandervecken!

For all your hard work on this problem!!!

[Ranadiel]

What if I culled GLOBAL variables with the following technique:

Start a new BG2 game, make a list of all global variables.
Make a list of all global variables from a savegame just before I leave BG1 for BG2.
Subtract list 1 from list 2, call it list 3
This leaves all global variables defined in BG1 that don't show up in a new game of BG2.
AFAIK there is no mod that transfers information from BG1 to BG2, except for the NPC mods. Those Mods have info about the NPCs stored in the Out of Party NPC section of the save game.

If the above statement is correct, all I have to do is remove the globals in list 3 from the stuttering savegame.

Ideas? suggestions?

EDIT: I should of course add that the variables in list 3 would only be removed from the stuttering save if their values are identical in both the stuttering save and list 3.
I have found some variables where this is not the case.
I have also been saving some variables that seem useful to save. List follows:
bansheefear - different values
BW_02 variables - the BW herbs mod is a BG1/2 crossmod.
ChloeSpawn - What is the NPC Chloe doing in BG1? Unless this is a different Chloe. Better to save just in case.
DMWWPHASE - a timer which hasn't stopped - to do with Phase spiders. Seems to be clocking up the minutes for some reason. Someone should look into pspider.bcs to see why it isn't being zeroed out.
DMWWzoneofsweetair - timer
dreamtimerstarted - seemed important
DSOTSC - seemed important
Fear - runaway timer?
goldenpantaloons - seemed important since I have kept them
malison - runaway timer?
partygobyebyenow - different values. What is this for I don't know

I am up to S but S is an awfully big job.

Some things to note.

-There are some NPC mods that behave differently if you play BG1. I believe that all of these are romance mods that have additional tracks available if you play through the same romance in BG1. I seem to recall that it is present for Xan and Ajantis, but I don't recall if it is present for Edwin. I'm fairly certain it isn't present for any of the female NPCs(although it may or may not be present in future releases of Rose). Just something to keep in mind as these details are likely read via romance specific globals.

ChloeSpawn- There is an NPC in BG1 called Chloe(I think she is in Ulgoth's Beard). This for a while did cause some minor incompatibility between BGT and Chloe. I know it has been fixed in the latest versions of the BiG World Project. I would think it would be safe to delete it, but it is entirely your call.

goldenpantaloons- I think this is just the variable that determines whether the golden pantaloons appear in Irenicus's Dungeon so it should be safe to delete after acquiring them as any further checks regarding them should be checking for the item itself and not the variable.

[Vandervecken]

What if I culled GLOBAL variables with the following technique:

Start a new BG2 game, make a list of all global variables.
Make a list of all global variables from a savegame just before I leave BG1 for BG2.
Subtract list 1 from list 2, call it list 3
This leaves all global variables defined in BG1 that don't show up in a new game of BG2.
AFAIK there is no mod that transfers information from BG1 to BG2, except for the NPC mods. Those Mods have info about the NPCs stored in the Out of Party NPC section of the save game.

If the above statement is correct, all I have to do is remove the globals in list 3 from the stuttering savegame.

Ideas? suggestions?

EDIT: I should of course add that the variables in list 3 would only be removed from the stuttering save if their values are identical in both the stuttering save and list 3.
I have found some variables where this is not the case.
I have also been saving some variables that seem useful to save. List follows:
bansheefear - different values
BW_02 variables - the BW herbs mod is a BG1/2 crossmod.
ChloeSpawn - What is the NPC Chloe doing in BG1? Unless this is a different Chloe. Better to save just in case.
DMWWPHASE - a timer which hasn't stopped - to do with Phase spiders. Seems to be clocking up the minutes for some reason. Someone should look into pspider.bcs to see why it isn't being zeroed out.
DMWWzoneofsweetair - timer
dreamtimerstarted - seemed important
DSOTSC - seemed important
Fear - runaway timer?
goldenpantaloons - seemed important since I have kept them
malison - runaway timer?
partygobyebyenow - different values. What is this for I don't know

I am up to S but S is an awfully big job.

Some things to note.

-There are some NPC mods that behave differently if you play BG1. I believe that all of these are romance mods that have additional tracks available if you play through the same romance in BG1. I seem to recall that it is present for Xan and Ajantis, but I don't recall if it is present for Edwin. I'm fairly certain it isn't present for any of the female NPCs(although it may or may not be present in future releases of Rose). Just something to keep in mind as these details are likely read via romance specific globals.

ChloeSpawn- There is an NPC in BG1 called Chloe(I think she is in Ulgoth's Beard). This for a while did cause some minor incompatibility between BGT and Chloe. I know it has been fixed in the latest versions of the BiG World Project. I would think it would be safe to delete it, but it is entirely your call.

goldenpantaloons- I think this is just the variable that determines whether the golden pantaloons appear in Irenicus's Dungeon so it should be safe to delete after acquiring them as any further checks regarding them should be checking for the item itself and not the variable.

Thanks for the detailed pointers. I add to the list the following:

sprite_is_dead

sprite_is_dead plus:
bearbr
deadcatpan01
copy
diana
gorf
greaterwolf
hobarc01
hobarc02
hobgoblinleader
hobsha01
hobwar01
hobwiz01
icbone01
king
misthO01
mistpo01
nevpupil
none
ogre
orc01
orc02
orc05
orc06
orcmage
orcpriest
pawn
player1-5 - seemed important
queen
rogtro02
sendai
shadow01
shank
skelwa01
spidgi01
tazok
trollde01
troll01
troll02
william
wyvern

usscbloc4 - semed relevant to bloc 5,6
viconiajoinedparty
vp_in_bg1
------------------

I guess what I really want to know is why a hundred or so global variables suddenly cause huge amounts of stutter, i.e. the reasons for my timing data in the post a few above this.
That would suggest a true upper limit to global variables, and perhaps the BWP should look into a community effort to lower global variable use when it can be done.

[Jarno Mikkola]

I guess what I really want to know is why a hundred or so global variables suddenly cause huge amounts of stutter, i.e. the reasons for my timing data in the post a few above this.
That would suggest a true upper limit to global variables, and perhaps the BWP should look into a community effort to lower global variable use when it can be done.

Hmm, how many of those Global's have large numbers on them? A large number is something excess of 1000, cause if you have a lot of timing variables, as most of them are, they could cause small lag each and so build up.

[Ranadiel]

I guess what I really want to know is why a hundred or so global variables suddenly cause huge amounts of stutter, i.e. the reasons for my timing data in the post a few above this.
That would suggest a true upper limit to global variables, and perhaps the BWP should look into a community effort to lower global variable use when it can be done.

If I were to take a guess, I would say, based solely on the timing information you provided, that there is a built in time delay on running through baulder.bcs. Based on your timing info, I would guess specifically that there must be at least .55 seconds between every check. When you have a smaller number of variables, Baldur's Gate is able to run through baulder.bcs in something like .2 seconds(entirely made up number) which gives the game .35 seconds to do everything else it has to do(such as updating the graphics) before the next run can be called. However as the variables increase, the time it takes to check every single condition gets longer until eventually it takes longer than the .55 second time required between checks which decreases the time that can be spent performing additional operations. Keep in mind though that this is just theory on my part as I haven't looked through BGII's code, so I don't know for sure how everything is taken care of.

Anyways, I don't think that decreasing global variable use is really an option as a community. From what I've been able to see from looking around scripts in the BG games, global variables are the bread and butter of all Infinity Engine programming. At best you might be able to get a handful of globabls combined in individual mods, but I don't think that would do much to fix the problem. I think a better solution might be to add a script at the transition from BGI to BGII that cleans up your globals by getting rid of any that aren't used. And then maybe have another one for SoA to ToB. I don't know how practical this would actually be, but it doesn't seem like it would be too hard in concept(just very very long and very time consuming).

-=Edit: Actually here is a question for you. When you ran your test on deleting 284 timer variables vs. the first 284 alphabetical variables, did you avoid deleting any timer variables with the alphabetical ones? If not perhaps try just deleting 284 non-timer variables just to see if you are getting the same result.=-

Edited by Ranadiel, 10 August 2009 - 06:20 AM.

[Vandervecken]

I guess what I really want to know is why a hundred or so global variables suddenly cause huge amounts of stutter, i.e. the reasons for my timing data in the post a few above this.
That would suggest a true upper limit to global variables, and perhaps the BWP should look into a community effort to lower global variable use when it can be done.

Hmm, how many of those Global's have large numbers on them? A large number is something excess of 1000, cause if you have a lot of timing variables, as most of them are, they could cause small lag each and so build up.

See Post 20.
96 old (2 or 3 of which seem to be runaway timers) and 284 total in the stuttering save.