- Joined
- Jun 23, 2013
- Messages
- 504
- Reaction score
- 127
As it is, logic-gravity interaction is limited at best. You can make a button trigger a gravity module, and you can make a particular area trigger a gravity module. That is, sadly, it. Any logic between the the button and the gravity module will make the interaction fail, allowing for no control over the system besides trying to control and predict the position of the player.
The technical reason for this is obvious- the game has to keep track of who triggered the signal, which gets messy if there's anything between the trigger and the module. Thus, I propose a mechanic to control the behavior of the gravity modules themselves, not the signals that trigger them. This approach has been more than proven with the implementation of the rails, and will surely function just as well for gravity.
Mechanic One: An on/off switch for gravity modules.
Any control we wish to have over gravity modules, for any particular situation, boils down to this- will or will it not trigger gravity? To control this, we should be able to slave one activation module to the gravity block. (like we can slave activators to rail rotators) If the slaved activator is on, the gravity module will accept a trigger, if the activator is off, the gravity module will not.
There is one exceedingly common subset of the on/off control that is, unfortunately, difficult do determine with logic alone- which direction gravity is already pulling. This is usually the most important fact about a player in any two-way transport system, since it the only certain indicator of where they're headed. While mechanic one would be a huge leap forward, this part could still be improved. Thus, I also propose:
Mechanic Two: Direction-based exceptions
For any gravity module, we should be able to dictate "If the player is falling rightwards, don't change their direction." To indicate which directions are to be left alone, we could slave gravity modules pointing in those directions to the module we want to configure.
For a deactivated (using mechanic one) gravity module, it should be the other way around. Since it's default interaction for any player is "zero effect", the "exception" dictated by a slaved module would be "full effect".
Mechanic Three: An on/off switch for slaved gravity.
To top it all off, the on/off switch should work for slaved gravity as well. A slaved module in "On" mode interacts with the master, a module in "Off" mode might as well not be there. This would mean all aspects of these mechanics can be freely controlled with logic, which is certainly desirable.
Hopefully, this should fulfill nearly any need for gravity manipulation, while being fully logic controlled, based on block architecture, and use minimal blocks for the more common use cases.
The technical reason for this is obvious- the game has to keep track of who triggered the signal, which gets messy if there's anything between the trigger and the module. Thus, I propose a mechanic to control the behavior of the gravity modules themselves, not the signals that trigger them. This approach has been more than proven with the implementation of the rails, and will surely function just as well for gravity.
Mechanic One: An on/off switch for gravity modules.
Any control we wish to have over gravity modules, for any particular situation, boils down to this- will or will it not trigger gravity? To control this, we should be able to slave one activation module to the gravity block. (like we can slave activators to rail rotators) If the slaved activator is on, the gravity module will accept a trigger, if the activator is off, the gravity module will not.
There is one exceedingly common subset of the on/off control that is, unfortunately, difficult do determine with logic alone- which direction gravity is already pulling. This is usually the most important fact about a player in any two-way transport system, since it the only certain indicator of where they're headed. While mechanic one would be a huge leap forward, this part could still be improved. Thus, I also propose:
Mechanic Two: Direction-based exceptions
For any gravity module, we should be able to dictate "If the player is falling rightwards, don't change their direction." To indicate which directions are to be left alone, we could slave gravity modules pointing in those directions to the module we want to configure.
For a deactivated (using mechanic one) gravity module, it should be the other way around. Since it's default interaction for any player is "zero effect", the "exception" dictated by a slaved module would be "full effect".
Mechanic Three: An on/off switch for slaved gravity.
To top it all off, the on/off switch should work for slaved gravity as well. A slaved module in "On" mode interacts with the master, a module in "Off" mode might as well not be there. This would mean all aspects of these mechanics can be freely controlled with logic, which is certainly desirable.
Hopefully, this should fulfill nearly any need for gravity manipulation, while being fully logic controlled, based on block architecture, and use minimal blocks for the more common use cases.
Last edited:
