96
edits
Difference between revisions of "Loading Level Resources With Lua"
Jump to navigation
Jump to search
Loading Level Resources With Lua (view source)
Revision as of 00:25, 9 June 2021
, 00:25, 9 June 2021added new info about level unloading, and how new triggers work
(Added info on Names table load order, stuff we don't know how to load with Lua yet, notes on sound/particle emitters, maybe a couple other things) |
(added new info about level unloading, and how new triggers work) |
||
| Line 5: | Line 5: | ||
====Important things to remember==== | ====Important things to remember==== | ||
These methods do not actually edit how the game reads an embedded Level_''Somewhere''/''Something''Instances.lua , so these changes only last until the level is unloaded. | These methods do not actually edit how the game reads an embedded Level_''Somewhere''/''Something''Instances.lua , so these changes only last until the level is unloaded. When a level unloads, it seems the Names table is completely cleared, including any new objects you created that weren't in the original ''Something''Instances.lua. | ||
If you | If you reference an ObjectName that exists in the Names table, but the associated object no longer exists in memory or is corrupted, your game will most likely crash. | ||
Although the ''Something''Instances.lua's all have each part of their table on its own line, it seems like the entire table needs to be on the same line to | Although the ''Something''Instances.lua's all have each part of their table on its own line, it seems like the entire table needs to be on the same line to be defined properly in Lua. | ||
The ''Something''Instances/etc tables that you construct to load resources into the Names table are usually (but not always) cleared automatically after the functions run, to free up memory. | The ''Something''Instances/etc tables that you construct to load resources into the Names table are usually (but not always) cleared automatically after the functions run, to free up memory. | ||
| Line 58: | Line 58: | ||
===Creating new Triggers=== | ===Creating new Triggers=== | ||
You can create new triggers basically the same way, by adding the CreateTriggers function: | You can temporarily create new triggers basically the same way, by adding the CreateTriggers function: | ||
<code> | <code> | ||
| Line 84: | Line 84: | ||
</code> | </code> | ||
With this method alone, new | With this method alone, new Trigger ObjectNames are added to the Names table for the rest of the level, but the actual data defining what the Trigger should do is '''not''' added to the section of memory where normal Trigger data is stored. Wherever the data is, the Trigger does exist at least until the end of the frame (maybe a few frames) and it can be activated for that short time, but then the data is overwritten and your game will crash if it tries to activate the nonexistent Trigger. | ||
It is not yet known how to make the actual Trigger persist for the entire level. Until we figure that out, one solution to create new "persistent" Triggers might be to have this code running every frame - though you'd have to make it not run while the normal level load/unload stuff is happening. Haven't tested that yet. | |||
Once you have created a new Trigger, you only need to use ResolveTriggerNames() to re-create it after its data is deleted. However, there does not appear to be any harm in using CreateTriggers() for it again, it just won't do anything - the Names table will stay the same. | |||
====Spawning instant one-time Triggers==== | ====Spawning instant one-time Triggers==== | ||