Created steps, pit, static collision, and armature.
Still need to:
* Create proper animation
* Add triggers
* Convert static collision to dynamic
* Make portals work
security_camera: replaced hardcoded mass of 1.0f with SECURITY_CAMERA_RIGID_BODY_MASS definition in header. added utility function to calculate security_camera moment_of_inertia, making it accessible to scene_serialize for deserialization due to rigidBodyUnmarkKinematic
The following static geometry was previously not marked with `no_portals`:
* Walls behind ball launcher and catcher in chamber 11
* Floor beneath button in chamber 12
* Wall behind ball launcher in chamber 14
in test_chamber blender files, renamed @fizzler objects to not cause generation of unused signals.
removed "parse_trigger_signal" in trigger.lua, added "optional_signal_index_for_name", which is used for both trigger signals and fizzler signals.
added check in fizzler.c if signal is -1
test_chamber_00: added level logic to trigger voice lines whenever the cube in the first room is fizzled.
added missing voice lines
box_dropper.c: fixed typo "DROPPER_.." instead of "DROOPER_.."
(Issue #13)
Elevator destination is taken into account when initializing
cutscenePreventingMovement, so the else block (intended for end of level
elevators) will not be mistakenly entered for start of level elevators
when voice lines are playing.
However, not nesting the condition makes it look like there is a bug
here, and makes the intention of the code (one branch for each elevator
type) less clear. Moved the voice line condition to inside the if body to
avoid this. There is no functional change.
Eventually the elevator logic as a whole should be refactored as it has
grown to be unnecessarily complex.
Level animations use global coordinates, but sk_animation uses relative
offsets for child bones. Updating sk_animation to use global coordinates
works, but would break support for model animations (which use relative
offsets).
Although model animation export logic is currently implemented on the
C++ side and would not be immediately affected, eventually it'd be worth
it to move it over to Lua for simplicity and consistency.
So to avoid a future breaking change, and since complex armatures for
level animations are not likely to be needed, I'm leaving the current
behavior as-is until it is proven to be useful/necessary. Levels which
break this rule will now fail to export, to avoid surprises for anyone
who tries.