Yes, the contrail would move because of the wind. You can null the wind and it will be easier to use.
I could modify the bipeds to add markers all over the edges of them, but I'm not really into modding anymore. Besides, a better solution would be to use a single animated synchronizing attachment such as a contrail or projectile attached to the biped model in 3ds max so that we properly emulate synchronization, so it looks like the AI is synchronized.
I was thinking to redo the models and animations as vehicles, where the "drive forward" would be the actor running forward, for example. This could work but might mean more limitations due to the way Halo multiplayer handles vehicles. But a mod could really just remove the Restart Game UI widget from the menu and only have the New Game widget modified to be a one-click process so that it is almost as easy as clicking Restart Game.
But I'm not interested in doing this, even though I'm probably the only person here who would know how to do all this presently.
EDIT: To clarify the idea that I started with when I considered AI synchronization for the first time a year or two ago, right now you have an AI controlling a Bipd model. This method does not synchronize, even though the biped tag synchronizes by itself or in conjunction with player status. So the
bipd tag does not synchronize when controlled by the
actv-
actr tag combination. But vehicles DO synchronize, even when controlled by the
actv-
actr combination. The
bipd tag is similar enough to the
vehi tag (they are both types of
unit tags) and even their
antr model animations are somewhat similar, so it would make sense that we could makeshift synchronized AI by having the following setup:
- right now, it is: actv -> actr -> {neither triggers nor results of AI are synchronized} -> bipd (spawn sync; common factors like gravity which affect the location indirectly mean indirect [potentially incorrect] synchronization) -> bipd-based antr
- workaround would be: vehi (dynamic multiplayer synchronization) -> seat(s) which directly synchronize positioning and visible animations -> actv -> actr ; vehi (dynamic multiplayer synchronization) -> vehi-based antr done as if it were a bipd's animations
I was having problems getting the above workaround to function, since the HEK tools and Blam! engine are so finicky about their animation types (jma vs jmo, specifically), where different animation types are used for bipd positioning (jma) and vehicle wheel animations (jmo). So perhaps instead of having the vehicle look like a spartan and be controlled by the driver seat AI and animate as if it were a biped, the secondary alternative would be to animate the character in the seat, rather than animating the vehicle being driven... but character seat animations are jmo animations also
. As such:
- workaround #2 would be: INVISIBLE vehi (dynamic multiplayer synchronization) -> seat(s) which synchronize only positioning but not visible animations -> actv -> actr -> bipd (spawn sync, but that is overridden by vehi sync by the game engine) -> bipd-based antr as model overlays (jmo) referencing vehi tag markers
--
If you are wondering what .jmo and .jma are,
go buy The Black Art of Halo Mods from Amazon.com for 1 cent.
