I hope the question is not out of bounds here.
I'd like to add HUD items as achievements / advancements of player through game play, ie: collect radar in mission, activate radar after collection or on mission turn in.
I can try to figure out how to hide/show it but since it's HUD and always active (for proper use once shown) it's overhead that I'd like to avoid running when HUD parts are not shown.

Attached some pics of the game.

Something else that is totally unrelated (except to me). Is there any published work on single entity, multi quest script(s).
Entity offering different 'defined' quests based on a definable player variable (ie: lvl, money etc).

Hud elements are just sprites so to hide them you simply move them off screen, i.e. position them at 200, 200 or similar.

I was actually curious about the question in the title, last night. Whereas instead of a Destroy(e) etc, we had something that would set the entity to then a static.

Neat idea in theory but not practical, the entire point of static objects is that they are set up at the beginning of the level and then forgot about for the remainder of the game, by defining something as static you would need to re-setup the entire map (ai pathing, lighting etc) which would make it more time consuming than just leaving the model dynamic

Another issue that will occur changing between static and dynamic is lightmapping, one of the primary functions of static entities is to tell the engine what to lightmap, if you start it off dynamic and switch it to static via lua it will still not be lightmapped, so it won't use dynamic lighting, but also won't have a lightmap to work from.

And of course AI collision! That is worked out once at start-up based upon the location of static entities, switch something to static during game play and the AI will still try to navigate through it rather than around it!

Courtesy of AmenMoses scripts, I've noticed something...
If you just want the script to essentially "turn off" and your objects
are isimmobile = yes, so you still want them visible, then you can add
a 'return end' right at the beginning of the script (when a certain condition
is triggered. I've done so, and it works, but again check the properties of
the entity (isimmobile, etc). Also you can Hide(e) them I'm supposing at the
same time?

BTW if entity is hidden- what happens to lighting? lol

if script[e] == 0 then return end --- exit script

After some thought and replies from others who are by far more familiar with GG. It makes sense that static y/n be set at startup.

Perhaps where I need to look is at better understanding how to use SwitchScript(e,str) for something other than cover while not crashing my tests.

So what's a good way to brick an entity?

For example like a chest you open and you no longer want it to run any scripting what so ever after its opened?

You could swap the script for default.lua.

I.e. SwitchScript( e, "default.lua" ) -- or maybe "scriptbank\\default.lua"

How about the reverse though? assigning default.lua (allowing the entity to be not static) and switching to something else on a trigger?
I.e. SwitchScript( e, "rpgchat.lua" ) or some other script action to become active on a condition.

Nah, if the script is default.lua then GG doesn't even attempt to call it, likewise if an entity is static GG doesn't attempt to call it's script.

The entity has to be active before GG will check to see if it has a script to call. If the script name is default.lua then GG just skips that entity entirely for Lua processing.

One other oddity I noticed is that GG will attempt to call the _init_name function for an entity and even if that succeeds it will still attempt the _init function, so in theory you could have and _init_name function which does some stuff and an _init function that switches the script to default.lua and you wouldn't need a _main function at all! (I haven't actually tested this though)

Whoa! Really? You can switch scripts mid-game?!
Now that sounds like it holds potential.

This might sound funny, but too bad you can't have GG call to open
up another software while the level is playing (for example you want to
create a menu in a another engine, or add perhaps a story)-- ya know
those little Visual Novel game makers. That would be all the way!
It would be cool if something allowed you to do this.

You could tie many software pieces into GG with trigger points or something.
That would take care of many feature requests... no?

Yes, it's quite simple, i can't remember the exact format off hand without my crib sheet, but it's basically two lines, the first would be placed above the _init and is a require command that tells the script that it will be using another script at some point, and then the second line would be in the _main wherever you need it which would actually switch to the other script when the conditions you set are achieved.



I don't think you can open up other software, but i'm pretty sure i read somewhere that there's a command you can use to open up a web page in your browser.

Look at the lua manual and you'll find some commands to deal with system stuff, think the one to open other files is os.execute("name")
Though iirc it opens in the background as GG takes fullscreen focus so you would need to make the user aware they need to tab to it or find a way to bring it to the front