Right now the process of creating a moving platform is awful for the type of level design that involves a lot of dynamic surfaces. You have to make a new behavior, link it to collision, new model id, etc. This should become a system where a moving platform can be a single level-script command.
Idea:
The format of the macro should allow geolayout and collision pointers, as well as everything else that an object can provide:
MOVING_PLATFORM(geoLayout, collision, posX, posY, posZ, angleX, angleY, angleZ, behParam, beh, acts);
This would prevent needing to load the geo as a model id (otherwise this is pretty useless).
Important (and obvious) thing to note: This would need Fast64 integration. I don't believe it would be too difficult, essentially it would be showing the SM64 Object properties on a mesh object/empty, then that tree would be its own separated geolayout.
I'd love to hear some thoughts on this idea and how it could be better, how it could be done, etc
Right now the process of creating a moving platform is awful for the type of level design that involves a lot of dynamic surfaces. You have to make a new behavior, link it to collision, new model id, etc. This should become a system where a moving platform can be a single level-script command.
Idea:
The format of the macro should allow geolayout and collision pointers, as well as everything else that an object can provide:
This would prevent needing to load the geo as a model id (otherwise this is pretty useless).
Important (and obvious) thing to note: This would need Fast64 integration. I don't believe it would be too difficult, essentially it would be showing the SM64 Object properties on a mesh object/empty, then that tree would be its own separated geolayout.
I'd love to hear some thoughts on this idea and how it could be better, how it could be done, etc