49 replies to this topic

[Chevalier]

Well, not there yet, but I might find a way.

[erebusant]

Well, not there yet, but I might find a way.

You could always duplicate a script block in AR0602.bcs, or AR0700.bcs, or wherever you want to strategically locate it in SoA. Something like the below, but with the BH sword of course,,,

IF
 Global("IHaveStealth","GLOBAL",1)
THEN
 RESPONSE #100
  SetGlobal("IHaveStealth","GLOBAL",2)
  ActionOverride("Table1",CreateItem("BOOT02",0,0,0)) // Boots of Stealth
  Continue()
END

[Bloodtitan]

well it's not that i do not WANT to post my weidu.log - it's just that i have posted it before and i didn't touch the installation since then. it wasn't labelled bad for wrong installation order or bad mods.

didn't get the chance to review the baldur.bcs so far, will do later the day and inform you about possible improvements

[Miloch]

It is from SoBH, it's the talking flaming sword.

Really now. All that extra stuff in baldur.bcs just for talking weapons? Yeah it's neat (I guess) but not crucial to the actual functioning of the weapon (aside from the talking, that is... and I'd think that'd get a bit old after a while since it seems to fire almost all the time).

I'd think if you really wanted this talking weapon behaviour, you could put it in your PC's script (or the script of whomever you wish to wield it). Sure, if you have AI off it won't fire, but that might be a blessing in disguise, and the same is true for anything that's in baldur.bcs.

As for this:

Quest mods do have to use baldur.bcs because there is no other script that runs constantly.

I haven't seen the need to use it in any of the (few) quests I've worked on. Usually adding to the script of the .cre you report to for the quest, or the scripts of the areas relevant to the quest has sufficed. And for BG1 modding, it's not possible to use baldur.bcs anyway.

[melkor_morgoth75]

Think you got it bad? I wonder how players of BiG World installs are handling stutters...

I never had a stutter in my games. The only one i found was with Senyiad ... this was due to their cultists trying to move after u speak him for the first time. Nothing particular. My override is ALWAYS pretty big, i don't biff files and my machine is just a 1.4gz with 512 Mb RAM and a little 32 MB video card (and i play in 1024 x 768 screen resolution).

mm75

Edited by melkor_morgoth75, 22 November 2007 - 03:53 AM.

[Miloch]

I never had a stutter in my games.

I thought you did have slowdown in Nashkel mines and maybe other places.

The only one i found was with Senyiad

Have you reported this previously? I was wondering recently if this was an issue with SCS Smarter Priests or maybe even the unmodded game. You might want to report it here too.

[Bloodtitan]

i have removed the suggested "songsapate", "elfsapate" and "hellblade: all" and stutter was reduced dramatically. still, it was not removed completely so my guess is it's one of those NPC scripts outside of my party again . at least i can play on (for a while..?).

[melkor_morgoth75]

I thought you did have slowdown in Nashkel mines and maybe other places.

Oh, i HAD just that one but it was due to a very first release of SCS if i remember correctly, actually i did forget it :-) I played the game so many times ... I hope i'm in the position to miss something after years of BG games. Anyway, the stutter was not a big issue, i mean ... the area was playable with only a slight delay and was only related to it. Miloch, we both know what the stutter (the real one) is, do we? ;-)

Have you reported this previously? I was wondering recently if this was an issue with SCS Smarter Priests or maybe even the unmodded game. You might want to report it here too.

Of course i had, I reported it some time ago to cmorgan, it is due to BG1 NPC Project, i hope he solved it. Chev had a similar issue if i remember correctly. The stutter in the link u gave above is different. It is not due to Andarthe, but senyad and maynly his fellows.

I think BIG mods as SoS or TDD COULD be the cause of stutter, 'cause i quite never have them installed.

mm75

Edited by melkor_morgoth75, 22 November 2007 - 07:53 AM.

[Miloch]

Have you reported this previously? I was wondering recently if this was an issue with SCS Smarter Priests or maybe even the unmodded game. You might want to report it here too.

Of course i had, I reported it some time ago to cmorgan, it is due to BG1 NPC Project, i hope he solved it.

BG1NPC does not touch Seniyad or his minion druids, as I reported and double-checked in the linked thread. SCS does though. Maybe you're getting your druids confused .

[Azazello]

It is from SoBH, it's the talking flaming sword.

Hee-hee, I stored mine in a chest back in Beregost I think, so when I get to NeJ2 I plan to pick it up again.

Really now. All that extra stuff in baldur.bcs just for talking weapons? Yeah it's neat (I guess) but not crucial to the actual functioning of the weapon (aside from the talking, that is... and I'd think that'd get a bit old after a while since it seems to fire almost all the time).

I'd think if you really wanted this talking weapon behaviour, you could put it in your PC's script (or the script of whomever you wish to wield it). Sure, if you have AI off it won't fire, but that might be a blessing in disguise, and the same is true for anything that's in baldur.bcs.

I like this idea but like Lilarcor the modder wants the sword/item to talk whenever any party member has a hold of it. I guess the questions are, can it be scripted to add the speech to all NPCs, and is that more effective than just dumping the code block, once, into baldur.bcs?

As for this:

Quest mods do have to use baldur.bcs because there is no other script that runs constantly.

I haven't seen the need to use it in any of the (few) quests I've worked on. Usually adding to the script of the .cre you report to for the quest, or the scripts of the areas relevant to the quest has sufficed. And for BG1 modding, it's not possible to use baldur.bcs anyway.

Interesting we're talking about this. I started looking for mods that put stuff into baldur.bcs, and would move stuff to area scripts. I've only done a couple mods so far, but if we're all willing, I think a thread proposing suggestions might, ultimately, remove some stutter issues, maybe some of the biggest ones.

I don't know how such changes could be moved to CREs or DLGs, so you coding gurus can edumucate the rest of us on this.

Edited by Azazello, 22 November 2007 - 04:41 PM.

[Ascension64]

Really now. All that extra stuff in baldur.bcs just for talking weapons? Yeah it's neat (I guess) but not crucial to the actual functioning of the weapon (aside from the talking, that is... and I'd think that'd get a bit old after a while since it seems to fire almost all the time).

I'd think if you really wanted this talking weapon behaviour, you could put it in your PC's script (or the script of whomever you wish to wield it). Sure, if you have AI off it won't fire, but that might be a blessing in disguise, and the same is true for anything that's in baldur.bcs.

I like this idea but like Lilarcor the modder wants the sword/item to talk whenever any party member has a hold of it. I guess the questions are, can it be scripted to add the speech to all NPCs, and is that more effective than just dumping the code block, once, into baldur.bcs?

The problem with PC scripts is that, as Miloch had mentioned, disabling party AI will annul anything you chuck in it. I don't think its a blessing because its a huge price to pay if you lose script control of your character (say, if you use eSeries, some of the SCS scripts, etc.). It is complete inconvenience to have to remember to turn party AI back on during a battle and turn it off at a conclusion to shut talking items up anyway. I'm not sure whether the same applies to override scripts, but I hope someone doesn't do that, because I use override scripts for temporary application of one-off scripts, and that would screw up any more permanent override script placed on the PC.

However, you might be able to offset the load on baldur.bcs if you made an invisible creature that warps to and follows the party around (a few blocks in baldur.bcs), keeps track if dialogue and globals, who has the item, and prompts the talking item to start dialogue. I hope not too many people catch on this idea. I can already imagine a game where numerous, elusive gremlins incessantly stalk Player1, making him/her delusional and schizophrenic, to say the least.

[Miloch]

It is complete inconvenience to have to remember to turn party AI back on during a battle and turn it off at a conclusion to shut talking items up anyway.

This actually makes perfect sense to me. During a battle, or before it, you'll have your weapon out (AI on), killing things, meanwhile Stormbringer will be screaming "More souls for my lord Arioch!" or whatever. Then after you've killed all the baddies, the sword is sated (for now), and even if it wasn't, you sheath it (AI off) so it has to STFU.

But my bigger point was - all that code in baldur.bcs merely for talking weapons, which any member may or may not have at any moment? Come on. If it was just one unique weapon then... maybe, but it sounds like there are several here. No wonder there's major stutter.

The invisible CRE scenario sounds like it might have even more issues, unless your imaginary friends can be made to appear only when the item is equipped or something. And even then, it's cludgy at best.

Couldn't the modder just put a few Display String effects on the item that happen either in rare cases or only under certain conditions? For example you might have a 1% heat crit and the sword says something about fire, another rare chance to suck some HP from the wielder and the sword says something about needing more souls, and so on? Might not be the exact same behaviour, but at the exchange of avoiding global stagger, I'd consider that path first as a modder.

[Ascension64]

This actually makes perfect sense to me. During a battle, or before it, you'll have your weapon out (AI on), killing things, meanwhile Stormbringer will be screaming "More souls for my lord Arioch!" or whatever. Then after you've killed all the baddies, the sword is sated (for now), and even if it wasn't, you sheath it (AI off) so it has to STFU.

If I was a garrulous sentient sword (no, there is no way I'd like to be one at that unless I had my own set of motor skills), I wouldn't just talk during battle. Plus, you don't sheath weapons (unless you put on your fists) in the game...the sword is always at ready.

But my bigger point was - all that code in baldur.bcs merely for talking weapons, which any member may or may not have at any moment? Come on. If it was just one unique weapon then... maybe, but it sounds like there are several here. No wonder there's major stutter.

Well, is there stutter if only the BG2-resident code plus the talking weapons were there? If all the weapons were added by the same mod, then whoever tested the mod on vanilla BG2 probably didn't see a stutter at all. Berating the mod philosophy and intentions aside, the best we could do is advise people not to use any other mod that changes baldur.bcs with this mod. That begs the question: did anyone delete all that talking weapon code and successfully remove stutter?

The invisible CRE scenario sounds like it might have even more issues, unless your imaginary friends can be made to appear only when the item is equipped or something. And even then, it's cludgy at best.

It was just a way to offset all the scripting from baldur.bcs somewhere else. It ain't fudge if it works, but it isn't like I have tried, either.

Couldn't the modder just put a few Display String effects on the item that happen either in rare cases or only under certain conditions? For example you might have a 1% heat crit and the sword says something about fire, another rare chance to suck some HP from the wielder and the sword says something about needing more souls, and so on? Might not be the exact same behaviour, but at the exchange of avoiding global stagger, I'd consider that path first as a modder.

A few wouldn't make the cut for a mod that has depth to it, but here it would depend on how intelligent the item would be. You can certainly do your DisplayStrings if you add the effect as part of the item ability, but that would only cater for the situation where you hit something.

From what I gather from CBs code, he mostly does checks for equipping, and random DisplayStrings not during combat. A temporary override script should handle the equipping scenario (putting in DPLAYER#.BCS would allow cheating since you can leave party AI off without the script block triggering). Don't know if you can avoid DisplayStrings in the baldur.bcs though.

Again, putting all the concepts of how bad a world of talking weapons looks, I think back in the day, it was simply an attempt to copy Lilarcor +3's code, hence the immense swelling of baldur.bcs size when talking weapons are added to the game.

[Miloch]

Again, putting all the concepts of how bad a world of talking weapons looks, I think back in the day, it was simply an attempt to copy Lilarcor +3's code, hence the immense swelling of baldur.bcs size when talking weapons are added to the game.

And this really gets to the crux of the matter (mod philosophy, as you say, aside).

[melkor_morgoth75]

BG1NPC does not touch Seniyad or his minion druids, as I reported and double-checked in the linked thread. SCS does though. Maybe you're getting your druids confused .

Really? Where does Jaheria quest with Seniyad come from?

mm75

Edited by melkor_morgoth75, 23 November 2007 - 12:13 AM.

[Miloch]

Really? Where does Jaheria quest with Seniyad come from?

BG1NPC does not modify those creatures or their scripts, as far as I've been able to determine from looking at the mod code. It only adds custom dialogue for Jaheira with respect to Seniyad. If you read the post I linked (not sure if you did), you'll see that someone reported exactly the same issue as you in the BG1NPC forum, but we've identified the probably cause as the SCS "Smarter Priests" component. SCS does definitely modify the scripts for those CREs.

[Bloodtitan]

i thought about the stutter problem and had an idea. at least for those stutters that come from quest related NPCs, maybe it will work for romances too:

we basically need a database containing the global variables for all the globals your savegame could have. the tool then should read out the actual globals in your stuttering savegame and compare with the database. it should also be able to track back how long a variable is set. the tool should give out warnings for variables related to quests or important dialog that are in a critical state, meaning running for quite a long time and not dealt with / quest not finished/started.
what can be leftout is variables like "has killed blabla" or quests that are finished anyway.

this is the basic concept to banish the stutter demon. not sure it will work and i am sure it needs finetuning. i am no coder or modder so i couldn't create it. need you experts to confirm the idea and a volunteer to code .

[Ascension64]

we basically need a database containing the global variables for all the globals your savegame could have. the tool then should read out the actual globals in your stuttering savegame and compare with the database.

Massively, massively impractical. What boring person will ever do that?

If you are worried about too many global/local timers running at the same time, then pro-actively stop them in-game by finishing quests, use less mods (espeically limit the number of NPC mod running concurrently, since you really can only have 6 NPCs in that party at one time), avoid starting too many, or buy a more powerful computer.

There isn't really any other practical, workable way of stopping stutter should you get it.

[Bloodtitan]

is it really that hard to create the database ? all you would have to do is reading the .dlg like NI does and save the globals mentioned. i would assume a script can do that..

If you are worried about too many global/local timers running at the same time, then pro-actively stop them in-game by finishing quests, use less mods (espeically limit the number of NPC mod running concurrently, since you really can only have 6 NPCs in that party at one time), avoid starting too many, or buy a more powerful computer.

see my problem is that sometimes stutter occurs without ever having started the quest yet finishing it will end the stutter. you cannot solve the quest stuttering with finishing the running quests. i have had this twice now and it is annoying - especially when i take in count i by far do not run the biggest possible megamod installation. i've only got like 50% possible.

however i do agree with you that solving the stutter ingame without a tool is the correct way. i just want the tool to analyze your savegame and give you a hint what quest could cause the stuttering (started or not) and as i elaborated, you cannot always realize it with just reading your journal.

Edited by Bloodtitan, 24 November 2007 - 12:28 AM.

[Ascension64]

is it really that hard to create the database ? all you would have to do is reading the .dlg like NI does and save the globals mentioned. i would assume a script can do that..

And so you are stuck with all the variables in dialogue files, perhaps related back to the dialogue file that sets it (or the 15 dialogue files that set it), which would make you to much research and guesswork to determine which quest/mod the dialogue file with some interesting variable belongs to. Multiply that for 500 variables and see who doesn't get ticked off 10% of the way into variable searching.

see my problem is that sometimes stutter occurs without ever having started the quest yet finishing it will end the stutter.

This makes a variable database even worse. If you get extraneous variables intermingling with 'meaningful' variables then you are forced to start extra quests.

i have had this twice now and it is annoying - especially when i take in count i by far do not run the biggest possible megamod installation. i've only got like 50% possible.

Which quests? It would be worth taking a look at whether these quests really plant pre-emptive 'stutter variables' into your BALDUR.GAM. Certainly better to deal with this on a case-by-case basis than to perform a circuitous holistic approach that would waste more time than bear fruit.

however i do agree with you that solving the stutter ingame without a tool is the correct way. i just want the tool to analyze your savegame and give you a hint what quest could cause the stuttering (started or not) and as i elaborated, you cannot always realize it with just reading your journal.

Fine, but do this on an empirical basis rather than a highly intensive approximate one. Can you mention the quests where after finishing them the 'stutter' abated?

Please excuse me if I come across to be overly confrontational. I am exhorting against a tedious approach to reduce stutter that most likely isn't worth the effort.