andylegate wrote:But there is a limitation to that: SDL file. I can't make changes to it and see them with the Internal Client. I have to wait until Mark does a rebuild and updates the SDL file I send him (which is actually a raw text file since MOUL uses a different format for SDL than the one POTS used).
If you mean a different encryption format, then yes. The actual textual format is the same between engines (but not the same as Myst V).
I'd assume that all files would be handled in plaintext form, and the build process being the encryption stage.
andylegate wrote:Colliders: we discovered (and Mark warned me about this) that a lot of colliders that seemed to work just fine on a POTS type setup or Alcugs shard, misbehaved on the MOUL server Cyan set up for us (we tested things on the actual MOUL:a server first, then the company that is sponsering this paid Cyan to set up our own actual physical server that our project runs on).
I found doorways blocked suddenly. Walls that I could suddenly walk through, etc.
Turns out PhysX is less forgiving than Havok. I had to go in and change the shape or geometry of some of the colliders, in order to get them to work correctly.
Some of this is due to differences in the physics engine, and a lot of this is to do with how PhysX was implemented. Uru's code was already designed with all the assumptions of Havok, and to make it use PhysX "properly" (to its full potential) would have required changes to a lot more than just the colliders. Animations, cameras, sounds, etc. would also have been affected.
Cyan took the easier and more time-effective route here, and replaced the core Havok stuff with PhysX while keeping the rest of the assumptions the same.
andylegate wrote:Sound files. Seems as though POTS doesn't mind just having a .ogg file, and in just about any format.
MOUL on the other hand is a bit picky about that. In many cases, it wants a .wav file too (and not because it's a non-spatial sound, or has to be streamed). We found that many of our home-grown sound effects were not working until I made .wav versions of them and Mark added those to the server. We also had issues of the home made sound files not liking this format:
44 Khz, 16 bit Stereo. or 44 Khz, 32 Bit Float Stereo.
Instead, it wanted the home made files to be 44 Khz, 16 bit Mono.
Mark is still trying to figure that one out.
It makes sense from a game production standpoint to use the raw, uncompressed wav files in Max, and have the ogg files generated at export time.
In particular, PlasmaMax has some code to handle labels at certain time intervals in a wav file (for synchronizing animations or triggering callbacks).
andylegate wrote:Another thing we noticed (and have not figured out yet). Let's say there is an elevator, and you have the elevator sound emitter parented to the Sub World Dummy. If you are on the bottom floor, and the elevator is several floors above you, when you call the elevator down, as it get's in range of the player, the sound of the elevator should fade in.
Instead, what has been happening is the elevator sound doesn't actually start until the emitter gets within range of the player (causing a delay when you have your responders waiting on the sound to finish before the elevator doors open up).
PhysX doesn't have a concept of subworlds as their own object type, but does some crazy parenting magic to make things work. Not sure if that's the issue or if it's a flag on the SoundMsg, but it seems weird to me to have a sound emitter parented to a subworld. Animating the emitter itself should work without these issues...
