Textures used to be unloaded as soon as they were unreferenced.
The TextureMgr cache keeps an active reference to prevent load-unload-load
cycles so it only unloads things when explicitly asked.
This does require some more peak VRAM during map/tileset transitions
especially, since old textures are unloaded only after the next map
has been loaded, but the shortened load times should be worth it.
Major code/logic cleanups + it has a multithreaded batch mode now.
The VFS code doesn't like multiple threads at all,
so for now there's a big lock in front of where it matters.
Changed precacher, map/tileset, and worldmap loading to batched mode.
Still TODO:
- fix broken mod preview images
- reloading resources on debug key
- make mod recache entirely unnecessary
- actually drop resources when no longer needed
Bugfix: Actually call postInit() for entities spawned via "se" node.
Bugfix: Don't call postInit() twice for the active pet
Previously, f55a70b459 changed entity ID handling so that
script-spawned entities have negative IDs and entities placed
on the map have positive IDs.
Turns out that positive IDs were still flaky due to frequent renumbering
upon map load. Typically entity IDs are assigned sequentially, and if,
upon loading, an entity with an already existing ID was to be spawned,
that new entity would be assigned a new unique ID (often its ID+1).
That in turn would often cascade into a long string of IDs falsely
considered conflicting because one bad entity started the entire thing.
During lots of map editing I've noticed that sometimes after adding an
entity to an older map, saving, and loading, many entities could be shuffled
around on the map. I'm not 100% sure this bug is related (and it may or
may not be fixed, i don't know yet, time will tell)
but at least entity numbering should be fine now.
This change properly and permanently renumbers entities so that upon map save,
the problem will no longer occur on subsequent loads and entity IDs
will be stable from then on.
Duplicate entity IDs should also no longer happen.
Also kill Entity::entityTypeIdx because there's no need to store it.
And yes i do feel bad for nuking that funny comment block :<
A map element ("tile") can now be tagged with an int.
In the editor:
Ctrl+Numpad to quickly set tag 0-9
Ctrl+T to input tag number for selection
This tag can be used by scripts for more advanced tile
manipulation compared to the old node_setElementsInLayerActive().
This function now takes a 4th parameter, the tag.
If 0 or omitted, the behavior is unchanged.
Otherwise, only affect tiles with that tag.
Add Lua func refreshElementsWithTagCallback(tag, callback):
Call callback(templateIdx:int, texture:str, active:bool, layer:int, tag:int),
and the tile is set to active when the return value is true.
refreshElementsOnLayerCallback(tag, callback) is also changed to use
the same callback.
Also fix UB (dangling pointer)in Element::render()
that never even caused a single problem.
- does no longer depend on collision mask
- remove global Game::lastCollideMaskIndex
- remove the horribly convoluted and now unused RenderObject::getInvRotPosition()
+ Lua func entity_getBoneLockDelay()
+ Lua func entity_setBoneLockDelay()
This takes out the last of the RenderObject mutables.
This also fixes the long-standing editor bug that map tiles
that are once moved to parallax layers and then back to a
normal layer keep their scroll factor until the tile is deleted
or the map saved and reloaded.
- Lua func node_activate() is now variadic and can pass any params to the target's activate()
- Add Lua func entity_activate() that works in the same manner
- Activating nodes/entities via RMB now passes (naija ptr, int input source) to activate()
- Don't delay entity activation by 1 frame
- Minor cleanups to some Lua functions; no functional changes there
The game used to unconditionally enforce shots to go at close to their max speed;
it is now possible to turn that behavior off if needed:
In a shot txt file, set AlwaysMaxSpeed = 0
New Lua functions:
+ shot_setAlwaysMaxSpeed()
+ shot_isAlwaysMaxSpeed
