Jump to content

3 second delay in SCS?


Miloch

Recommended Posts

Could I ask a couple of people with slow computers to test the new hopefully-optimised mage script and see if it still runs slow?

 

Unzip the attached file. Put dw#mgsee.spl into EasyTUTU/override, put magecore.baf into EasyTUTU/scs/mage, and reinstall scs. It will whine about various PARSE_ERRORs, but ignore it. Test it in and out of battle and let me know if it works any better than the original version.

 

I'd like to release a new version of SCS very soon so a quick reply would be very helpful.

scs_test.zip

Link to comment
Guest Freelance Cynic

Hello DavidW!

 

First of all, thank you for looking into this so quickly. :p

 

Unfortunately :p, I have to report that the hopefully-optimised mage script didn't prevent the hiccups from occuring in my tests and didn't also, at least perceptibly, space them farther appart from each others. In my game, with any version of [smarter mages], hiccups still occur every 3.5-4 sec in Candlekeep and every 2 sec in Candlekeep Inn, for example.

Link to comment

Unfortunately I have to report the same results as Freelance. I put it to the same stress test as posted on SHS. It basically followed the same behaviour as Scenario 1 (SCS 3.01 without this fix). Which means pro5's revision was an improvement but, on the other hand, this didn't crash either. And I almost thought it would, because with the Smarter Mages, this battle with the three mages in FW1009 is just *insane*. I was surrounded by literally dozens of summoned kobolds, gnolls, xvarts, which are annoying just by their sheer numbers. Then when I finally hacked through those, and several mirror images and shields, the mages start popping healing and invisibility potions like they're happy pills. I only finally manage to kill one - the other two wusses went like perma-invis and buggered off somewhere in the maze. I do hope you get this fixed soon, because without Smarter Mages, this battle is pathetic. I'll be happy to test again though because even with the stutter, this component makes the battle quite fun. :p (I should post a screen shot next time - it's *insane* I tell you.)

Link to comment

*Much* better. :p The stuttering is gone, even in combat at its height with the three mages and their summonees.

 

However, I think the save/load time increase problem still remains. Might not be quite as bad - I didn't notice it much when I created a new character (maybe a few seconds longer than usual) and it wasn't too bad when I CLUAed to FW1008. But when I moved from there into the cave at FW1009 (where the mages are) the game froze for a full 30 seconds at least. The ice maze loads in a couple seconds without Smarter Mages (I confirmed this after backing out the component).

 

Though I only have ever noticed this with the Smarter Mages installed, it is exactly symptomatic of the same problem addressed on Bioware's site by beta patch 26499, as I reported on SHS. If you can't see any cause of the problem in the component, maybe I'll try installing the beta patch and see if it fixes it (I'll ask on PPG if this is even possible with Tutu).

This BETA patch is being provided to fix a particular issue with the Throne of Bhaal 26498 patch. If you are having a problem with save and load times noticeably increasing, the new Throne of Bhaal 26499 BETA patch has been found to resolve the problem.
Oh and here's those screen shots I promised:

 

Before Smarter Mages (I cut these guys down in a few seconds):

smage0.jpg

 

After Smarter Mages (it got more "insane" than this, but close enough):

smage1.jpg

Link to comment

Fantastic - thanks for that.

 

As for the save/load time increase, my working theory is that when the game creates a creature in an area (such as when you enter that area, or when the game sets up the area when you load the game), it somehow loads each creature's script into memory. So the longer the script, the longer this takes.

 

Now, the "smarter mages" script is about ten thousand lines of code. By comparison, the typical BG1 mage script is about 150 lines; the typical BG2 mage script is about 300 lines. The mage script from Tactics is the nearest in size that I know, and that's about 2000 lines. So inevitably it's going to slow things down some when loading areas.

 

If this theory is right, then there isn't really anything I can do about it - optimising the code may make it run quicker, but it won't make it physically shorter, and I don't think there's all that much redundancy in it. It's just that every single spell needs about ten long blocks of code in order to target it intelligently, and that adds up quickly.

 

(It's irritatingly difficult to write good code in the BG scripting language, it's too restricted).

 

So I fear the slow load/save is probably a price you have to pay for increased mage intelligence.

Link to comment
Guest Freelance Cynic

Amazing! :p It works near perfectly!

 

The hiccups are completely gone outside of combat and, inside, are much more subtle.

 

Just to make sure I got it right, however, was I supposed for the last test to run it with all three files you sent us (dw#mgsee.spl, magecore.baf & magetop.baf) or only the last one (magetop.baf)? I tested both and didn't see any appreciable differences.

 

I also have the extra-long load/save times like Miloch, but I can live with them, they're much less annoying that the hiccups were.

 

Thank you so much for looking into this, especially since this is an issue that surely doesn't affect many of the users of this mod. :p

Link to comment
Amazing! :p It works near perfectly!

 

The hiccups are completely gone outside of combat and, inside, are much more subtle.

 

Just to make sure I got it right, however, was I supposed for the last test to run it with all three files you sent us (dw#mgsee.spl, magecore.baf & magetop.baf) or only the last one (magetop.baf)? I tested both and didn't see any appreciable differences.

 

All three.

 

I also have the extra-long load/save times like Miloch, but I can live with them, they're much less annoying that the hiccups were.

 

Thank you so much for looking into this, especially since this is an issue that surely doesn't affect many of the users of this mod. :p

 

Not a problem. I've had the comment from a significant minority of users - and I'm in the process of producing a BG2 version where there will be quite a few comparably long scripts, so looking for ways of optimising code is useful for that too.

Link to comment
The optimised script is now incorporated into V4 of SCS - let me know what effect it has on people's observed slowdown times.
Hi David, there are at least a couple of reports of slowdowns with the latest version. One user has a fairly fast machine, one a fairly slow one. As I've previously reported, it seems to work ok on my own (slower) machine except as noted between area transfers. Just thought you might want to look into it. Cheers, -Miloch
Link to comment
The optimised script is now incorporated into V4 of SCS - let me know what effect it has on people's observed slowdown times.
Hi David, there are at least a couple of reports of slowdowns with the latest version. One user has a fairly fast machine, one a fairly slow one. As I've previously reported, it seems to work ok on my own (slower) machine except as noted between area transfers. Just thought you might want to look into it. Cheers, -Miloch

 

Looking through that thread (which I've vaguely been following) I can't find anyone who's confirmed that they're actually using v4. Am I missing something? I've posted a request-for-clarification.

Link to comment
I don't have a problem (it's either cause of v3, or my 1.6ghz processor)
That would be your processor. Version 3 still had the suboptimal script, though you probably wouldn't notice it.

 

Also, the user with the fast machine confirmed he had no problems with v4. The user with the slow machine hasn't confirmed the version yet (that machine was slower than mine if I recall, so lag could still be happening even with v4).

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...