* Removed the `OrderedDict`s
* Changed some stuff from the code review
* Fixed a typo
* Added these imports: `from __future__ import annotations`
and `from typing import *`
* Moved `from __future__ import annotations` to the top.
* Changed type annotation `any`s to `Any`
In an attempt to address #359, I separated 3D stereo sounds into
separate emitter scene objects and allow the engine to position them
around the listener such that the left channel is actually on the left
of the listener (and the same for the right channel). Unfortunately,
this did not fix the bug in question. However, the code that interfaces
with sounds from the outside is now much simpler, and the improved
behavior is a win, IMO, so let's keep this.
If a sound message was being sent to a random sound modifier, the
responder tree might crash on export. This fixes that particular problem
and adds a mitigation to the responder code itself. Remember kids that,
in Python `None and True` is `None`...
I don't really want to talk about it. *Gulp*. Anyway, you define
multiple animations on either the animation modifier or the textures
panel. The UIs have all been unified. By default, you have an "(Entire
Animation)" that represents the old single animation. You may create
additional sub-animations over an arbitrary range of keyframes. Once
other animations are defined, the "(Entire Animation)" may be deleted.
However, if all subanimations are deleted, the "(Entire Animation)" will
resurect itself with its last known settings.
Behavior change: object animations (except for fixed cameras) now
REQUIRE an animation modifier be attached to export. It is now an error
to attach an animation modifier to any camera except for a fixed camera.
When an emitter is a random sound emitter, then it is no longer possible
to address the individual sounds on that emitter. Instead, you can now
only stop or resume the randomization OR set the volume of the active
sound.
This allows directing the message to *all* modifiers -- this is
primarily only useful for ladders, but some other types may respect the
message. Also exposed the ability to send the message to child objects.
It appears that in Havok-physics enabled versions of Plasma, plEnableMsg
does not affect physics. Therefore, we have to send the PotS-era
plSimSuppressMsg to do this job.
Previously, reusing node trees required careful thought and
specification of specific nodes in the advanced logic modifier. This
tedious requirement has been removed in favor of ensuring that the nodes
themselves take into account whether or not they should generate and
attach plasma objects.
"Improve" is not quite the correct verbiage here because there were bugs
in the old code. The main issue is that any SceneObject with a
plPythonFileMod attached MUST have a CoordinateInterface attached,
otherwise the object would be invisible in game. Further, there were
some unreported oversights with regard to auto-generated modifiers that
have been fixed.
What was previously marked as transition cuts would really only cut goal
and POA tracking. Transition cutting requires the addition of a
transition ovveride. The engine supports cutting transitions on
plCameraMsg receipt by the virtual camera. The option looked sloppy on
regions (and should probably be controlled in the transitions), but it
has been added to camera message nodes for more control.
This commit removes the ability for Responder State nodes to specify
Responder Command nodes. Now, Responder State nodes reference Message
nodes directly. Messages that support sending callbacks can now
reference other messages as linked outputs.
Note that old node trees are currently broken and will need to be
reworked by hand. TODO is to automatically upgrade those old command
based node trees. Also, LOGICWIZ code using command nodes needs to be
updated.
Added the Render > Lighting modifier that lets one specify whether or not
we should forcibly use RT lights. This allows us to change the light
baking rules to allow the baking of nonanimated Plasma lights when this
setting is disabled. The modifier also has text explaining what the
lighting results should look like.
OK, this commit does a lot, and it was hard to separate the changes, so
mega-commit.
- We now export stencils in such a way that Plasma layers can be affected
by multiple stencils, theoretically matching the Blender behavior
- We don't try to animate stencils or even offer animation options. This
is nonsense.
- In our zealousness to skip over illegal texture slots, there was a bug
introduced in which we queried texture fcurve paths illegally,
potentially causing animations to be exported incorrectly. This has been
fixed.
- There was a potential issue with the animation command node's material
option in which the message could be sent to the wrong page. This has
been corrected by making the Object field mandatory for all animation
types.
This makes things incredibly more complex because Blender stores those
animations on the ObData ID instead of the Object ID data block. Dang. So,
the animation modifier's detection code had to be pretty much scrapped.
The newer code is a little hacky in places. Hopefully we can address this
soon-ish.
Also, this fixes a bug with auto-expanding input sockets. It turns out
Blender was renaming them behind the scenes. We now ensure that we ignore
this renaming -- fixes many potential gotchas.
Now, an object can be a "master" animation object controlling many
animated objects when you address it with the Animation Command logic
node.
This also includes a fix for a bug that would potentially break an
animation if it were addressed by an Animation Command node.
To ensure that there are really, really, REALLY no race conditions related
to coordinate interfaces, we now run through all modifiers before we
export and ask them if they need to make Coordinate Interfaces. I was
hearing some comments about clickables warping around. This sounds like
physical coordinate issues to me...
1Codealot
Patrick Dulebohn
