if exec load a script, how can unload?

[Johxz]

Hi... sorry :oops: I have other question...

how can unload a script? in the documentation not see nothing... I don't want some functions still there in the level. Exist something like unexec? :lol:

thanks!

[Jason Campbell]

I've never used them but functions can be placed in packages which can be activated or deactivated. Simobject methods can be packaged also.

[rlranft]

Yeah, packages are the best thing you can do - perhaps use them on a per-mission basis or something - but you can't actually unload a script.

The real question is, why? What are you trying to accomplish?

[Johxz]

Thanks Jason sorry not to mention I know the packages. But I need to do more test with this.

@rlranft packages is for one function or few? I want to disable or unload a complete script. Or what is the best practice? use packages and put all the functions inside?

I have a few triggers and stuff made with scripts and only execute once, but the problem I see, a lot of them are in memory and will not will used anymore. Therefore I want to unload all the stuff I will not be used and of course load the new scripts.

thanks for your helps

[rlranft]

For an example of "many or few" look at scripts/server/game.cs and scripts/server/gameDM.cs - gameDM.cs overrides game.cs for DeathmatchGame, and it only overrides part of the base set of scripts.

As far as memory consumption - I can't imagine scripts using more than a few megabytes of RAM. To my knowledge this has never been an issue. Remember - when the game is executing, the scripts are all compiled to byte-code - much smaller than even the text script files.

[buckmaster]

The question you also need to ask is whether packages actually free any memory when they're popped - as far as I'm aware, all they do is remove the functions from the namespace stack, so you can't access them. They still 'exist', I think.

As for your question on best-practises: one best practise is not to worry about tiny amounts of memory until you actually have a memory problem ;).

[rlranft]

"Premature optimization is the root of all evil."

[PaulWeston]

If you are looking to remove unused objects (in this case triggers) that were added through a script, just surround them with a simgroup, and then delete that simgroup when you are done with it.

Then if you need the triggers back, just re-execute the .cs script that includes them.

We use this to add/remove deck objects from our Starship Enterprise. We have each deck's contents stored in a separate .cs file, and a trigger on each deck that is tagged with which objects to load. When you go to that deck it will execute the relevant script and load in all the objects for that deck. Then when you leave the deck (exit the trigger) it deletes the simgroups that it just loaded. When you go back to the deck, we re-execute the .cs. And so on...

[Johxz]

If you are looking to remove unused objects (in this case triggers) that were added through a script, just surround them with a simgroup, and then delete that simgroup when you are done with it.

Then if you need the triggers back, just re-execute the .cs script that includes them.

We use this to add/remove deck objects from our Starship Enterprise. We have each deck's contents stored in a separate .cs file, and a trigger on each deck that is tagged with which objects to load. When you go to that deck it will execute the relevant script and load in all the objects for that deck. Then when you leave the deck (exit the trigger) it deletes the simgroups that it just loaded. When you go back to the deck, we re-execute the .cs. And so on...

 

Thank very much Paul, may be this is what I need ;) delete or destroy and them if I need it, re-execute the .cs.

[rlranft]

Just to point it out, this is what happens between missions already - the players leave the mission, the mission group is deleted, then the next mission is loaded.

[Johxz]

Just to point it out, this is what happens between missions already - the players leave the mission, the mission group is deleted, then the next mission is loaded.

 

thanks @rlranft, I was trying to mimic basically the loading screen of half-life, I have a large level divide by zones, so went the player enter to a new zone I don't want the old stuff from the other zone still there.

[rlranft]

That's a good idea - another fellow was having a problem loading large numbers of objects in a single mission. He wasn't having memory or performance problems, his problem was that the simdictionary has (had?) a hard-coded limit to how many objects could have unique identifiers and it would reuse ids instead of refusing to load a new object. It was playing havoc with his scripts.

[MangoFusion]

Scripts cant be explicitly unloaded, but they are reference counted so if you are no longer using functions defined within a codeblock it should get destroyed. If you have no functions in your codeblock, even better - it should get destroyed as soon as you finish exec'ing it.

Strings and identifiers within scripts however aren't released since they get inserted into the StringTable, though this is usually not a problem.