Execute Script Discussion (split: Me+Scripts=Headache)

[envida]

Original thread by Chainz.2da: here

tk102

 

Originally posted by Xcom

But since now you can devote some attention to perfectionism, using Stoffe's decompiled script is much better idea. You can simply replace original OnEnter script without having to "inject" ExecuteScript commands. Your mod's compatibilty rating will increase dramatically.

 

I'm not sure I agree with you on this I think that if you can get away with injecting your scripts that is better than changing in-game scripts. Of course sometimes that is necessary. But using the ExecuteScript will make it easier to make different mods compatible with each other.

 

Lets take an example maybe that explains better what I mean. Lets say we have a onenter script for module Ebon Hawk called k_enter_ebo003, now a modder takes and modifies this original file with his stuff, then you get another modder who uses the same file too with his changes now if these changes are big it gets harder and harder to edit the different changes and use both mods. Now if you just kept the original onenter script and used the ExecuteScript command instead it gets easier to use several mods for the same onenter script. Because for each mod you used you can just enter one line that execute that mod. Now it gets much easier to use several mods for one onenter script.

I think this will become more and more of problem as we get more mods using the onenter scripts.

 

Just my 2 cents. Anyone agree or disagree?

[Darkkender]

Originally posted by envida

I'm not sure I agree with you on this I think that if you can get away with injecting your scripts that is better than changing in-game scripts. Of course sometimes that is necessary. But using the ExecuteScript will make it easier to make different mods compatible with each other.

 

Lets take an example maybe that explains better what I mean. Lets say we have a onenter script for module Ebon Hawk called k_enter_ebo003, now a modder takes and modifies this original file with his stuff, then you get another modder who uses the same file too with his changes now if these changes are big it gets harder and harder to edit the different changes and use both mods. Now if you just kept the original onenter script and used the ExecuteScript command instead it gets easier to use several mods for the same onenter script. Because for each mod you used you can just enter one line that execute that mod. Now it gets much easier to use several mods for one onenter script.

I think this will become more and more of problem as we get more mods using the onenter scripts.

 

Just my 2 cents. Anyone agree or disagree?

 

I agree whole heartedly. Also the advantage comes when you use this method if the scripts for somebody elses mod do not exist the game will ignore the missed execute script and go to the next. I know because when testing placement of my workbench in the Ebon Hawk I left yours and LiquidX's scripts out of game and everything worked fine without them.

[ChAiNz.2da]

Originally posted by Darkkender

I agree whole heartedly. Also the advantage comes when you use this method if the scripts for somebody elses mod do not exist the game will ignore the missed execute script and go to the next. I know because when testing placement of my workbench in the Ebon Hawk I left yours and LiquidX's scripts out of game and everything worked fine without them.

Hmm... I'll definitely keep this in mind then. After being in the Base for 3 days trying the scripts, I've noticed it's a VERY good area for alot of different types of mods. There's even a great spot for an add-on area

 

Seeing as there's not alot of "definite dialogs" options to work from in order to fire a script in this area. Other than giving away vital plots in your readme such as "in order for this mod to work, you must use computer terminal #4...blah blah".

I can see the value of using On Enter scripts for this particular area.

 

Since I have a working version of it as well, I'll make the change over to the Inject Execute style script so that future mods that want to make a compatible version will have less of a headache

Thanks for the input guys

[Xcom]

Originally posted by envida

But using the ExecuteScript will make it easier to make different mods compatible with each other.

 

I don't see how it is easier.

If Chainz includes the source of his script, then it should present no chellenge for next modder to make it compatible. In fact, the next modder has a choice of using ExecuteScript method or merging his code with Chainz' original script.

 

Originally posted y Darkkender

Also the advantage comes when you use this method if the scripts for somebody elses mod do not exist the game will ignore the missed execute script and go to the next.

 

What if they DO exist?

You will be executing original script for several times in a row (because other mods supposedly also have ExecuteScript to call the original script), and you might not want to do that, especially with Ebon Hawk.

[Darth333]

Originally posted by Xcom

What if they DO exist?

You will be executing original script for several times in a row (because other mods supposedly also have ExecuteScript to call the original script), and you might not want to do that, especially with Ebon Hawk.

I 100% agree with Xcom. In any event, it is necessary to merge scripts, no matter which method is being used or you could end up with problems in your module. (This is why it's important for modders to release their source code)

 

As to what method is best, using the ExecuteScript or decompile and reconstitute the original script, both get the job done. This time ChAiNz got the .nss file so why not use it? (It has the advantage that "you get what you see") However, very few people are comfortable reading byte code. Using the the execute script function is easy and just as good. The main idea is to make scripting accessible to most people on these boards.

[envida]

Originally posted by Xcom

I don't see how it is easier.

If Chainz includes the source of his script, then it should present no chellenge for next modder to make it compatible. In fact, the next modder has a choice of using ExecuteScript method or merging his code with Chainz' original script.

 

What if they DO exist?

You will be executing original script for several times in a row (because other mods supposedly also have ExecuteScript to call the original script), and you might not want to do that, especially with Ebon Hawk.

I don't think you understood what I meant. The original script will be run only once of course no matter what.

 

Let me show with an example:

 

Let's take Dantooine. When you arrive you have a script called "k_enter_601" which is run every time you enter the module. Now instead of editing this script itself you rename it to say "602_dan_enter", now you make a new "k_enter_601" script where you will execute the different scripts you want. Like this:

void main() {

// this is where you put in scripts you want 
// to run when entering a new area. These scripts
// only contains the stuff the modder wants to add 
// and not the original onenter script of course
ExecuteScript("script1_from_modder1", OBJECT_SELF);
ExecuteScript("script2_from_modder2", OBJECT_SELF);
ExecuteScript("script3_from_modder3", OBJECT_SELF);

// this is the original onenter script renamed to "602_dan_enter"
// was called "k_enter_601"
// now this original onenter script is run at the end and only once
ExecuteScript("602_dan_enter", OBJECT_SELF);
}

This way you have a simple onenter script where you can add a simple ExecuteScript line for other mods that want to use the onenter script. It's a much cleaner way of doing it than editing the original script several times over with a big chance of messing things up. Of course this won't work when you need to alter something in the file itself but most of the time you don't need to do that.

I'm not trying to impose anything on anybody; I just feel that doing it this way it will make things so much simpler when you have many mods using the onenter script. Instead of going through several scripts figuring out the difference, editing and merging them together you just use a simple ExecuteScript to inject a new mod's script. I can't see how that wouldn't be much simpler and causing less problems than constantly re-editing the original script? This will be truer the bigger and more complicated the script is.

 

Again I'm not trying to be difficult or saying that my way is right and your way is wrong. Just think it's good to discuss these things and try and find methods that make it easier to make different mods compatible with each other.

 

Beancounter has a tutorial on this here: http://www.lucasforums.com/showthread.php?s=&threadid=137370

[Xcom]

in your example, what do these scripts do?

 

script1_from_modder1

script2_from_modder2

script3_from_modder3

 

I assume they come from mods that also use OnEnter script, so they all use the same formula as you, which means:

- they have their own renamed original OnEnter script

- and their scripts look smth like this:

 

void main()
{
     // do some mod related stuff
     ExecuteScript ("renamed_original_OnEnter", OBJECT_SELF);
}

 

or not?

[Darkkender]

Originally posted by Xcom

in your example, what do these scripts do?

 

script1_from_modder1

script2_from_modder2

script3_from_modder3

 

I assume they come from mods that also use OnEnter script, so they all use the same formula as you, which means:

- they have their own renamed original OnEnter script

- and their scripts look smth like this:

 

void main()
{
     // do some mod related stuff
     ExecuteScript ("renamed_original_OnEnter", OBJECT_SELF);
}

 

or not?

 

Pretty close if you have a mod take envida's Ebon Hawk compartments mod and you wish to also add something using the same method. You would simply change the new OnEnter script to include another execute script command. Example

 

void main()
{
     ExecuteScript ("my_script", OBJECT_SELF);
     ExecuteScript ("ev's_script", OBJECT_SELF);
     ExecuteScript ("your_script", OBJECT_SELF);
     // do some mod related stuff
     ExecuteScript ("renamed_original_OnEnter", OBJECT_SELF);
}

 

There would be no need to constantly rename and create a new copy of the OnEnter as somebody has already done so for you. If your mod is not present this script will skip past the executescript(your_script) and go to the next command. However by constantly adding to a script and making it directly more elaborate you take the risk of it ending abruptly if one of it's essential components are missing. I ran into similiar problems when I was writing some complex scripts for K1. But as soon as I broke them down into there own sub-scripts they all worked fine. Plus this has the advantage of consolidated error checking.

[ChAiNz.2da]

hehe, this thread gets more attention than my W.I.P.

 

As the case goes, for this time around, I've used the OnEnter Execute 'inject' script along with a spawn placeable script. I've also used the tips to "trim" my code to it's essentials (tested and works..w00t!)...

 

For a newb scripter like me, this seems the route whereas other's in my 'newb' status would appreciate more as far as being easy to add-on to.

 

The Underground Base keeps getting more potential the longer I'm lingering there, and even if no one else does, some future mod(s) of mine will. It'll at least be easier for me to add additional scripts... hehehe

 

I do appreciate everyone's help, but seeing as how I've still to complete Phase2 as well as add apx 200+ lines in the upcrystals.2da (yeah... 200!!) I have to "move on"...

 

Doesn't mean I won't re-visit this thread, and by all means keep the discussion going. I'm learning more scripting techniques just by viewing all the samples everyone's posting "as examples". I hope this thread and on-going discussions will help others who are or will be in my predicament.

 

I think the title fits for just about any scripts dealing with executing and spawning ... beats the first title I was going to use:

 

"Yes, ChAiNz.2da is a script-tard®" (though still true)

[beancounter]

Originally posted by stoffe -mkb-

You'll also need to keep in mind the sequence that scripts are executed when ExecuteScript() is used. It's no problem when doing as you described and only using the original-named script as a "loader" with a sequence of ExecuteScript statements, but it's worth remembering that...

(snipped to avoid confusion)

 

Stoffe - what you posted above on the ordering of ExecuteScript is incorrect. It fires immediately and executes completely before control returns to the calling program. The function would be completely worthless if it did not. Check the NWN Lexicon entry on ExecuteScript. Your sample scripts will return the correct number of "5" for the first one and "The number is 6!" for the second script. I am 100% sure because I tested them out.

 

In my opinion ExecuteScript is the easiest and best method for merging scripts. Especially since the average modder is not going to be able to figure out the the ncs file.

 

However, the key to making it work correctly is to nest your scripts. Using Darkkenders format:

 

Originally posted by Darkkender

 

void main()
{
     ExecuteScript ("my_script", OBJECT_SELF);
     ExecuteScript ("ev's_script", OBJECT_SELF);
     ExecuteScript ("your_script", OBJECT_SELF);
     // do some mod related stuff
     ExecuteScript ("renamed_original_OnEnter", OBJECT_SELF);
}

 

 

Just make sure none of the individual scripts call the Orginial On Enter Script and everything should work fine.

[stoffe]

Originally posted by beancounter

Stoffe - what you posted above on the ordering of ExecuteScript is incorrect.

 

 

Oops, sorry. Must have thought about something else (DelayCommand(0.0, ...) probably) when I posted that.

 

That's what you get for posting before testing I suppose... I'll remove that post to avoid misleading others.

 

I still believe it depends on what you are trying to do which method is best. And you'd still need to make sure the different scripts play nice with eachother even if you use a plugin-style ExecuteScript() method of merging them.

 

I chose to modify the original script in my first example in order to avoid having to do further checks by placing it within the code block that only gets executed once when the player first enters the area.

 

But, as said, as long as it works either way I suppose it's a matter of personal taste which method one chooses.