form lists vs. multiple mods

[TheTalkieToaster]

Weeeeell, it *might* work as scripts address variables by index (so 'set ScriptedVar.mod1 to 1' is actually 'Set the Nth variable on ScriptedVar to 1') and if both compilations have the same script text the variables might have the same indexes, but that's the kind of stuff that generally should be avoided as it's very liable to break. NVSE has mod inter-operability features for the same reason it has weapon damage alteration, and keypress watching; because people needed them and they weren't in the default game.

[ozziefire]

Cool interesting thread, learnt heaps here, Doh! I was under the misguided opinion a defined global variable could be read by multiple mods, that nugget saved me some lost coding time :)

 

Also it seems scripts are the best way to screw around with formlists for compatibility with other mods, I will have to give that a definate go that would explain why some of my items aren't appearing in vendors for some people I guess :)

 

Umm does that apply to Leveled Item Lists too, do they get overwritten by later mods unless you use a script to add items?

Edited July 19, 2011 by ozziefire

[drakeelvin]

What is a "canary"?

 

Heh, good question I don't even know if "canary" is a generally accepted term but the idea is that a canary process (or function or script or whatever) is like a bird sitting way up overhead on a wire and looking down on the world, watching. It acts when it sees certain things happening. Something I distinctly recall hearing in a very colorful lecture by a compsci prof many years ago.

 

The idea can help to simplify very complex logic by dividing up work, particularly in a scenario where there could be any number of programmers each working on a different area of a system but they all need to monitor the state of one part of a system and act accordingly, and independantly.

 

Pretty much what the Quests do in GECK, the quest mechanism lets you run any number of scripts autonomously, and each one can monitor what's going on with the variables in other quests and/or object references and take action accordingly.

 

The major practical issue is that if you have too many of these running at once it kills performance so you don't want to overdo it. Particularly for object scripts, having a lot of scripted objects in the same cell can really slow down the game and probably even crash it, if you put in too many. It's better to use one larger script to handle many small, related things, rather than have one small script for each thing.

Edited July 19, 2011 by drakeelvin

[stevie70]

I really can't explain it any other way, except to say it doesn't work.

well, actually i never was somebody who could easily take a "won't go" if it comes with no better reasons than just "because it is like that" or "because it's hardcoded" or "because god says so" or other stuff of the likes - best way to make me go try out, and mostly, it proves that that's just the point where stuff gets interesting :-)

 

so i scripted that out, and i VERY proudly present the attached file, which is proof this VERY WELL works. :-)))

 

the file contains two little communicating esp's (plus a version containing both for easier script reviewing, so do _not_ install this one together with the other two - works perfect standalone though)

everyone of them adds one console with a light, a switch for it's own light and a switch for the other mods light. try it out, works like a charm, load order doesn't matter anything.

and if the other mod is not installed, the switch for the other mod just does nothing, no weird behaviour, crashes or anything.

and in addition, on start, every one of the two mods checks for the other one and displays a message if it's installed or not (one thing i haven't scripted out yet though is detection of configuration changes after first detection, but that's as well already layed out in the whole concept and would be easy to do)

apart from that, you can pass as much information as you'll ever want this way without a prob, the only beauty stain being the intentional script overwriting, but i think the benefits pretty much make up for that little unelegance, and it doesn't do any harm anyway.

 

ingame, you find the whole setup in doc mitchells house (coc gsdocmitchellhouse) right beside the vigor-tester (thought that was a good controller because it's only used once right at game start)

note that _everything_ in the left light column is added by mod 1

and _everything_ in the right light column is added by mod 2

the only thing that overwrites is the vigortester-script (both mods make exactly the same changes)

 

and in geck, absolutely everything used in the mods starts with the string "s7oMT", in cell-window as well as in object window,

s7oMT01 for adds by mod1, s7oMT02 for adds by mod2, so it should be all quite easy to find.

and the scripts are pretty well commented and should be quite self explanatory anyway

(the one vanilla script that's undergoing changes is the vigortester-script, like i said)

 

and yes, i'm aware this pretty sure isn't the most efficient way thinkable of scripting this, but for now, i rather concentrated on the logic and keeping the script understandable (more for myself than for others).

...

*patting myself on the shoulder* :-)))

Edited July 20, 2011 by stevie70

[stevie70]

Weeeeell, it *might* work

.....it do-hoooooes.... :-))

[stevie70]

Doh! I was under the misguided opinion a defined global variable could be read by multiple mods,

it _can_, if you just make every single one of those mods think it placed it there itself. make every mod define the same variable in the same vanilla script and it works. :-)

[stevie70]

Heh, good question I don't even know if "canary" is a generally accepted term

ah, cool, private words - and a nice one, too... :-)

 

Particularly for object scripts, having a lot of scripted objects in the same cell can really slow down the game and probably even crash it, if you put in too many.

uhm, that goes for GameMode-blocks and such and not for, like, OnActivate etc, i assume...? or generally many scripts == bad ?

[drakeelvin]

Yes, GameMode blocks in particular.

 

However, it is not clear to me if (generally speaking) there is any performance hit created simply by putting lots of activator objects in the same cell, with scripts.

 

Even if all the scripts use just the "OnActivate" section, does the engine still have to check all the object scripts each frame? Or is the script compiler smart enough to eliminate those objects from the list of things that need to be tested each frame because they only have an OnActivate section?

 

I don't know the answer to that.

Edited July 21, 2011 by drakeelvin

[stevie70]

Yes, GameMode blocks in particular.

However, it is not clear to me if (generally speaking) there is any performance hit created simply by putting lots of activator objects in the same cell, with scripts.

would be bad for me, really like scripting objects (and doing it plenty)

 

Even if all the scripts use just the "OnActivate" section, does the engine still have to check all the object scripts each frame?

wouldn't make much sense to me, i mean i'm pretty sure they're tweaking their programs whereever they can, performancewise, so why would they just pointlessly waste that much. just for an example, any stuff with an onDrop block whereever it is would be checked any frame... or distinguishing between GameMode and MenuMode wouldn't make any sense if everything runs all the time anyway... well, just being optimistic so i can go on scripting objects like there was no tomorrow... hehe... :-))

 

p.s.: and i got to admit, i'm disappointed like hell that nobody even commented on the little mad-scientist-esp-communication-thingie i made... ;-)

[ozziefire]

p.s.: and i got to admit, i'm disappointed like hell that nobody even commented on the little mad-scientist-esp-communication-thingie i made... ;-)

Sorry, I downloaded it, but haven't had time to play with it yet, I'll get distracted from the other 5 things I'm working on at once too easily :)

Edited July 22, 2011 by ozziefire