Script-Lag, time to trim?

[BigJ]

Similar to the trimming areas talk, I thought this might be worth some discussion.

(Disclaimer: My only real experience of this is with Skyrim, in single player mode. Even with a more modern engine like that in SP the more scripts you have running, the slower it can get (Eg. Delayed sound effects, slow inventory loads, even CTD's).)

A quick google showed scripts can cause a fair bit of lag in NWN2, especially when there are a lot of players and NPCs in one area and scripts are bouncing off all of them. Shops too. DM events especially.

So is it time to discuss what scripts actually add a lot to gameplay and roleplay? Maybe consider removing some that do not contribute as much as first thought?

At a time when all the talk seems to be about adding more to this old engine bless it, should we be trimming back here and there? Ie. Ranged attack / cover system?

BigJ

(PS. Apologies to anyone the slightest bit offended if I'm off base with this, I would like the discussion though and do not mind being corrected)

[chad878262]

I wouldn't mind cutting back on scripts if they really aren't adding to gameplay, are buggy or otherwise cause some form of unintended difficulty. However, seeing as our various developers, scripters, area builders, etc. work so hard on the content, I would not want to remove scripts arbitrarily unless we can somehow show that removing the script will improve performance in some way. Ranged cover, for instance is something Rasael worked hard to implement (along with the various other melee and ranged changes) so I wouldn't want to remove it unless there was a real improvement made by doing so.

My personal opinion is that the stand in actors could be an issue, if they still persist as they have in the past. I can't imaging having numerous actors, bigby hand's etc. can be good for performance/stability.

[Aspect of Sorrow]

The compiled scripts weigh in somewhere around 70 MB on disk and are often executed from the SSD than cached. The on loaded event script for example is our 17th heaviest script weighing in at 119 KB compiled, with approximately 21,300 instructions performed in the worst case scenario, but a lot of the code has long dependency chains that aren't just specific to what has been authored for the BGTSCC module, and are dependent on nwscript's vm. Cutting back on scripts doesn't necessarily benefit in totality, instead creating our own optimizations has a better yield on overall performance such as in instances where instructing the CPU for store buffer forwarding is limited.

Some scripts are rarely fired, while others, even smaller ones, are executed in considerable amounts. Some things that can be changed is reducing variable declaration overkill, and fixing some of the object invalid declarations can enable us to take advantage of the script accelerator, but not until we can make certain of server stability using it first.

We'll refactor a lot this year without needing to prune away what helps define the module.