Why are the quests in the game handled by a segmented, chaotic, random collection of result scripts when it would be 100% more structured and intuitive to have all stages, objectives and their logic stored in the quest's script and just use the quest "system" for holding text info?

Becase the Dev's hate you! No, seriously I was just trying to give you a bump! :facepalm:


cev

I think it's a result of the new conversation editor. Quests are conversation based in NV and so it ended up in this hard to debugging form.

Flexibility.

Some things you just can't shoehorn into a list of fields/tables. And they've tried, they've really tried...

I've done a similar design concept at work - and sometimes you just need to let the developers extend things with scripting, otherwise you're going to be rewriting the engine all the time to handle special cases. If it can handle 98% of things, then it's good enough.

Ugh. I'm gonna say PAH to that, do everything in the quest script and see where that gets me. Sure, I'll need some dialogue result scripts, but they'll just be setting variables in the quest script. I guess the system works if you're familiar with it, but to me there's nothing more cozy than the intimate feeling of a Notepad document full of if-blocks with no error reporting.

Seriously, don't stick everything in one massive gamemode block full of if's, that's incredibly poor scripting. The system is certainly messy but stage result scripts and dialogue scripts have a purpose- they replace the need for those big, constantly-running ifs checking a bunch of variables with just "SetStage Quest 50" and the script you only need to run once, only runs once. Not that you need to make significant use of dialogue result scripts- you should generally try and have the dialogue firing stage scripts for actual quests as they're centralised and easier to modify and expand (so if there's 3 different people you can talk to to trigger an event, they can all call SetStage rather than using result scripts, and you can add more without needing to copy-paste large chunks of code).

If you want to say "Sod it, I don't care about efficiency" you can, but it's a bad choice, community unfriendly (as if everyone coded like that we'd end up getting performance issues), and will rapidly run into problems when you start using more processor-hungry functions like GetLOS.

I would also add that the questing engine was built so that someone who Doesn't understand assembly code can create entire quests, opening-up the list of people that can make quests by a great margin. The UI for questing may seem jumbled, but I find it quite convenient for isolating specific moments in a quest and controlling all possible factors that way.

Perhaps most importantly, it allows us to interject conditions from one quest onto another quite easily and in a way that can be quickly found later. I don't think it would have been possible for Obsidian to construct the ultra-complex, interrelating quest logic that they did without simplifying the interface and expanding the available touch points.

The interface does take some getting used-to, but after that it becomes very easily to assemble quests and tie things together.

Miax

quest dialogue lines are all eligible to cause specific and unique changes in the game. The way it works now seems to allow a whole lot of power.

I do find the new conversation editor kinda awkward, but that could be a familiarity thing. Maybe it's great. But I am definitely used to and comfortable with the 'old' way.

Actually whilst we are on the subject, are there any decent articles on scripting efficiency / etiquette or that kind of thing? Ive looked through the wiki extensively but its easy to miss something since the search option isnt that inclusive.

I think it is definately something us intermediate scripters could do with looking at. Ive never had anyone slap me on the wrist for writing inefficient / poorly constructed code, and I think its become a bit of a bad habit. The only pointer Ive ever really clued on to is dont stick a bunch of crap in gamemode blocks without at least conditionalizing it with variables.

I think it is a matter of do the best you can. Your knowledge and skill dictates much of this.

The only thing I've seen which resembles etiquitte is, people like to see stuff indented properly.

Some people make variables like bHello with the b indicating that the variable is used as a 0 or 1 state flag (binary). I don't personally fart around with that but, it does exist.

Cipscis has a nice pile of tutorials. http://www.cipscis.com/fallout/tutorials/ .

Yeah indenting is pretty much mandatory right now with the error checker not present, I barely keep track as it is :brokencomputer:

It would be cool if there was a way to "measure" how much your mods total scripts were affecting performance, e.g. by framerate drop, although I doubt it would be noticeable except for several very large scripts running nonstop?

There is, cipscis made a thing which does this. can't recall where to get it atm but I used it to test some of my stuff.

Also identified how very much easier on CPU the 'isweaponinlist' function is as compared with running the same thing through 'getequipped'.

Cipsis is the go-to person for efficiency, but in general the advice is just minimise the number of things gamemode scripts do in any one frame, and use if(var) and elses when possible.
For example:

if(stage == 0)   set stage to 1elseif(stage == 1)   set stage to 2elseif(stage == 3)   set stage to 3endif

Is going to be running 3 if-comparisons a frame, even when it's 'finished' and stage is 3. It can be written more efficiently as

if(stage == 3)   returnelseif(stage == 2)   set stage to 3elseif(stage)   set stage to 2else   set stage to 1endif

If it's finished, it only runs one check.
That said, don't go mental trying to optimise everything perfectly and sorting all your if lists by order of occurrence, it's just something that helps if you do it.

Fake edit: I didn't know IsWeaponInList was that much more efficient, you learn something new every day.

I've only just started with the engine and I picked this habit up from looking at the game's scripts myself, though actually given that shorts are prefixed with s and floats with f, it's pretty safe to say the b stands for bool, which is a basic programming data-type we don't have (Actually I recall reading that in Oblivion at least, all data was stored internally as floats no matter what the scripting told you they were... I wonder if that's still true.) Though yes, a bool is a single-bit 0 or 1 value.

I'm studying game engine architecture as a subclass of a computer game development degree in college right now, having a sharp set of C++ skills is mandatory there. C++ is very strict about what you can and can't do with a type, so to easily remember what type a variable is and save yourself some headaches later, it's common to use some kind of naming convention on your variables. Giving a variable a name like m_pLstGameEntities might seem a bit unnecessary, but in a large system it's very convenient to know that that variable is a member of the current class(m_), is a pointer(p) to a List(Lst), the name itself(GameEntities) telling us that it's used to keep track of all the entities in the game. Keeping a similar syntax is handy to let you remember what GameBryo script variables can be used for, even though we only have 3 types. I myself use b on Booleans(though they are in fact integers), i on shorts and f on floats, mostly to avoid rubbing out my C++ "accent", which happens alarmingly fast, I've already developed a nasty habit of not parenthesing my ifs, forgetting semicolons, etc.

As for script performance, I believe that sacrificing a small bit of performance is in order if it makes debugging easier, and especially if it increases code flexibility. Scripts will never be fast anyway, but a couple of if's extra should not matter. Expensive functions like sqrt, pow, trigonometry stuff, getLOS, etc. should however be used with care. Let's say you want some objects to always be in front and back of the player, as part of a floating ring of stuff or something, etc. This can be made positively devastating with bad scripting, like this stupid and extreme example:

set fFrontOfPlayerX to player.getpos x + sqrt(fVectorX*fVectorX + fVectorY*fVectorY) * sin (player.getangle z)set fFrontOfPlayerY to player.getpos y + sqrt(fVectorX*fVectorX + fVectorY*fVectorY) * cos (player.getangle z)set fBackOfPlayerX to player.getpos x - sqrt(fVectorX*fVectorX + fVectorY*fVectorY) * sin (player.getangle z)set fBackOfPlayerY to player.getpos y - sqrt(fVectorX*fVectorX + fVectorY*fVectorY) * cos (player.getangle z)frontObject.setpos x fFrontOfPlayerXfrontObject.setpos y fFrontOfPlayerYbackObject.setpos x fBackOfPlayerXbackObject.setpos y fBackOfPlayerY

Instead, you should do the expensive functions only once and store their results, cut down on unneeded variables, and avoid multiplication or division wherever you can, like this:

set fDistance to sqrt(fVectorX*fVectorX + fVectorY*fVectorY)set fPlayerYawSine to sin (player.getangle z)set fPlayerYawCosine to cos (player.getangle z)set fStuffPositionX to fDistance*fPlayerYawSineset fStuffPositionY to fDistance*fPlayerYawCosineset fStuffPositionX to fStuffPositionX + player.getpos xset fStuffPositionY to fStuffPositionY + player.getpos yfrontObject.setpos x fStuffPositionXfrontObject.setpos y fStuffPositionYset fStuffPositionX to player.getpos x - fStuffPositionXset fStuffPositionY to player.getpos y - fStuffPositionYbackObject.setpos x fStuffPositionXbackObject.setpos y fStuffPositionY

Also, it's important to remember that when you have a hammer, everything looks like a face. The above result can be achieved without any expensive trigonometry, simply with:

set fStuffPositionX to player.getpos x + fVectorXset fStuffPositionY to player.getpos y + fVectorYfrontObject.setpos x fStuffPositionXfrontObject.setpos y fStuffPositionYset fStuffPositionX to player.getpos x - fStuffPositionXset fStuffPositionY to player.getpos y - fStuffPositionYbackObject.setpos x fStuffPositionXbackObject.setpos y fStuffPositionY

I made it available as an example plugin on Fallout 3 Nexus, although I don't remember what sort of condition the plugin is in - http://www.fallout3nexus.com/downloads/file.php?id=11239

Now that NVSE is out and allows looping, I might make a similar utility and run some more performance tests. It'd be nice to know if anything has changed in New Vegas with regard to script optimisation. On that note, does anyone have anything that they'd like me to test out? I'll have a look at general syntax things like the difference between "if bVar" and "if bVar == 1", but if there are any functions you'd like me to compare as well just let me know.

Cipscis

Funny you should ask.

if SomeREF.getitemcount Everything    ; <---- everything is a huge formlist NV has; do stuff   SomeREF.removeallitems ...endif

Ref only typically has like, 1 or 2 things in its inventory.

I had recently, specifically, wondered just how bad this is.

All I wanted to know by that code is: does the ref have anything at all in its inventory. I didn't offhand see a better way to get that.

I'm not running this in gamemode, its quest script with 5 second timing.

Hmm, that is an interesting idea. Of course if it's only running once every second then using a slightly less optimised script isn't a big deal, but I'll try running it a few thousand times per frame and see what pops out the other side.

I'll compare multiple http://geck.gamesas.com/index.php/GetItemCount calls for single items against a single http://geck.gamesas.com/index.php/GetItemCount on a form list containing the items, with various form lists (i.e. one containing only the relevant items, one containing a few extra items, one containing a lot of extra items).

I probably won't get it done tonight (getting close to 2:30 am here in New Zealand), but I'll post a new topic once I've got some results later.

Cipscis

EDIT:

Didn't test exactly what I said in this post, but I think it's still relevant. I'll post a new thread once I've written up the results.

Cipscis

EDIT:

Thread is http://www.gamesas.com/index.php?/topic/1139867-script-optimisation/. Tarrant, I tried to send you a PM but your inbox is full.

Cipscis