moving to a one-folder-per-actor structure in my editor
already implemented and partially tested the loading & saving code
the end goal is to be able to track changes and only save the edited part of the map, skipping the rest, to make ctrl+s faster
a side benefit is that all object-specific files will reside in the same folder
that should make it easier to cleanly emit multiple meshes from one generated object (e.g. door + frame, or separating windows in a building)
the side effect of making custom tech is generating lots of test data with unclear porting value
got a bunch of maps that I'm not sure if I should even port to OFPA since they were used to test something once upon a time
due to upgrading several things at the same time, it's unclear if they're even fully functional - and some things (like lighting) definitely aren't anymore
should probably focus on developing confidence in replacements before deciding what to do
even after doing 99% of serialization work, a few silly bugs appeared
- first save produced the correct files but subsequent saves deleted them (since the path was wrong and they failed to load)
- subtype serialization was just missing so the files couldn't be loaded back
have done some polishing as well now (sorting actors when compiling the map and in the list UI)
yet to do actor file deletion too, will probably do as part of per-actor dirty flag implementation
found one more funny OFPA bug earlier
I have a function to convert an actor template (resolved at edit time) to a prefab (resolved at runtime)
in the process, the prefab is created and the actor template is deleted, and both have the same world UID/folder
when deleting any map object, the world UID is inserted into the set so that its folder can be deleted
file writing comes before deleting
therefore on the next time the map was saved, the new prefab was saved and deleted
there was also a "collaborative" path bug (files being saved to the wrong location) that I only found out due to moving compiled runtime data to the asset folder
the incorrectly placed generated object models created folders that showed up in SVN
I guess that's another reason in favor of avoiding two separate, parallel and similar (but not the same) file structures for source vs compiled-for-runtime assets
OFPA seems to have exposed some deficiencies in my tooling
for one, TortoiseSVN seems to kill explorer's responsiveness as soon as a bunch of files are saved at the same time
this might be fixed by an update, looking into what's going on or a different SVN client, not sure yet
also, OFPA isn't especially useful for prefabs without overrides (excluding position/rotation) - it's a tiny amount of data for a separate file, so I could pull just those back together in one file
now thinking about extending the OFPA system for a more open-world type thing
I had submaps initially (like UE) but ended up never using them
I also don't like the idea of scenes (Unity, Godot) since it adds too much friction for same-logical-map transfer actions and makes linking too manual overall
I also want the paths to be stable since all my resource refs are path-based
currently leaning towards removing submaps and adding a partitioning extension instead
this probably already exists somewhere at least partially but here's the idea of partitioning I have so far:
- not a 2D grid (like UE)
- hierarchical (partitions can have subpartitions)
- orthogonal to map editor layers
- each actor stores which partition it belongs to, but also there's a cache to find actors from partitions (for faster limited map loads)
- actors can be marked real or imposter (LOD)
- partitioning doesn't affect actor path (<map root>/_ofpa/<world UID>/*)
now wondering if I want one file per partition or one for all, or some hybrid
per-partition actor UID lists could become long
but I don't want to try replicating the partition hierarchy in the file system either
could have one master file + per-partition files
all the master file needs to be useful is the hierarchy (e.g. tab-indented list of partition IDs)
the rest could be in per-partition files (ID, name, bounding volume(s), real/imposter actor UIDs)
finished removing the old submap system from the map editor a while ago
turned out that it was heavily integrated
now dissolving maps from the runtime code
already managed to dissolve most of it
just need to convert things to a point where a map can contain a categorized set of objects that can be moved into the main world (and ideally also back out without destroying them)
thinking of moving actors and spawners into the component container now
had to mostly revert 2 commits that moved actors/spawners into the world directly
as it turned out, component container was a better location for it
now world contains 2 containers (the "run set" for what's active and the "pending set" for what's manually added and about to be active next frame)
seems like in the end the component container will be basically the same as the map object, just controlled differently and with copying features
redesigned the map derived material system because an issue was found
all the materials were loaded with the map
when a map is being streamed, nothing as big should be preloaded in entirety, not to mention cases where the materials end up not being used at all
instead saved them to separate files (one might say OFPM) while still supporting them being edited in the map editor (key code remains basically unchanged, at least for now)
Arvīds Kokins