Dynamic Gravity Logic

[Mr. V]

I know the desire of dynamic gravity blocks has been proposed in a few ways over the last few months - So this thread is more of a proposal on how to implement a dynamic logic system specifically for Gravity Blocks.

I think that if a gravity block is currently receiving an active signal from a NOT block, it should disable that gravity block.

By disabling the gravity block, I mean that you cannot use that gravity block to affect the players current state of gravity (i.e. sending a signal from a NOT block to a gravity block would not affect the player's current state of gravity at all - it would just determine whether or not the player could do anything with that gravity block directly or through area triggers).

This would be useful primarily in multiple floor Gravity Lifts - you could link logic in such away that a given area trigger in a gravity lift chute wouldn't cause the player to change or lose gravity at an unwanted time, while still allowing gravity state changes under desired circumstances.

The main pro's to this system are: 1) easier to design functional/intuitive gravity lifts and 2) no need to add additional blocks into the game

I can't think of any negatives to this proposal, as there is no reason to currently link NOT blocks to gravity blocks - so implementing something like this shouldn't break anyone's ships Let me know if you can think of any cons.


Respectfully,
Mr. V

 

[CyberTao]

Just a question, I am a logic noob, but could you set up a AND gate with a NOT leading into a NOT leading into that AND? Instead of having the NOT lock down the gravity unit, you have the NOT reverse the first NOT signal and feed it into an AND, meaning that the AND wouldn't activate if the first NOT was sending a signal?

Just curious o -o

 

[Mr. V]

It's alright - everyone has to start somewhere - I'd recommend watching some of Sven the Slayer's or Bench's logic tutorial videos, they're pretty helpful. After that just start messing around in Starmade and it'll slowly start to make sense.


My understanding is that the AND block will only activate if it is receiving active signals from all of the blocks it is linked to.

If I understand what you are describing (a NOT linked to a NOT, the second NOT is then linked to an AND), the AND would only activate if the first NOT was deactivated because it would cause the second NOT to become activated. With that said - unless you have other inputs you want to link into the AND you might as well not use the AND at all - just link things directly from the second NOT.


My suggestion at the beginning of this thread was simply to provide a means of rendering a Gravity Block completely incapable of receiving input through logic -- you could rig whatever type of logic system leading up to that NOT block to get it to activate/deactivate for your specific needs.

The same result (deactivating a Gravity Block) could be achieved with any or all other logic blocks the dev's chose to use - I just thought use of the NOT block in order to deactivate something seemed a little more intuitive than the rest of the existing logic blocks for this purpose

 

[CyberTao]

If I understand what you are describing (a NOT linked to a NOT, the second NOT is then linked to an AND), the AND would only activate if the first NOT was deactivated because it would cause the second NOT to become activated. With that said - unless you have other inputs you want to link into the AND you might as well not use the AND at all - just link things directly from the second NOT.

Spoiler: Some ramblings

The NOT was suppose to be that lock that keeps the Gravity from activating, wile you could put an OR on the other side of the AND to receive input from any logic that might activate the Gravity. The gravity block wouldn't get any input unless both the 2nd NOT and the OR were giving a signal. (AND is the block sending the signal to the gravity block)

Signal that deactivate gravity -> NOT -> AND (While signal is true, AND cannot be activated and thus, gravity would not be altered)
Signal that causes change in gravity (multiple) -> OR -> AND (Any signal that would caused a change in gravity would do so, so long as the other side allowed it)

Mind ya it would might need a delay to keep you in that gravity (Gravity disables when the signal ends I think?) Thought that being said, wouldnt locking the gravity then cause you change gravity at times? Maybe a activation module would be better instead of an OR? I dunno, I am rambling now...

 

[Mr. V]

Mind ya it would might need a delay to keep you in that gravity (Gravity disables when the signal ends I think?) Thought that being said, wouldnt locking the gravity then cause you change gravity at times? Maybe a activation module would be better instead of an OR? I dunno, I am rambling now...

ahhh, I see - I'm trying to suggest a way to prevent a gravity block from doing anything to the player's current gravity status. The idea is that you could use logic to get a gravity block to simply disregard any type of input at a given time. The new linkage wouldn't cause a player to switch gravity or lose the current gravity through logic, it would just toggle whether or not that gravity block would currently accept inputs that would affect the player's gravity.

The idea is that if you had a grav lift going to a number of separate floors - you could create area triggers to re-set gravity to "right-side-up" for each floor - all of which the player could fall through without necessarily triggering each and every gravity block. The player hits a button at the bottom floor, gravity reverses, doors/ceilings open - the player falls upward through a number of open doors and area triggers linked to disabled gravity blocks until getting to the appropriate floor where an area trigger linked to a non-disabled block would cause gravity to re-set and a door to close under their feet. The player pressed a single button and the logic system got them to their desired floor and left them in the correct gravity for that floor without any more interaction required from the player.

... I probably should have made a picture or something with this post .. it's difficult to put into words

 

[Demodor]

I would like that the gravity module to have a field around it, once you enter it, you are affected by the gravity, no matter how many players are entering or leaving the field, not having to activate the module every time, or trigger it. And the modules have settings like omnidirectional gravity or directional gravity. This way, with omnidirectional gravity you would not just fall down, instead you get pulled towards the block...this way we can build stations and you can walk on both the top or bottom or inside a torus...i would like inertia for the austonaut too.

Maybe a gravity module with the posibility to add enhancers to increase the size of the gravity, like the dock's system...this way we could have areas in the stations each with their gravity. Or the option to set the field hight/width it the module's menu...the bigger the field, the more power it consumes.

 

[jayman38]

I would like that the gravity module to have a field around it, once you enter it, you are affected by the gravity, no matter how many players are entering or leaving the field, not having to activate the module every time, or trigger it. And the modules have settings like omnidirectional gravity or directional gravity. This way, with omnidirectional gravity you would not just fall down, instead you get pulled towards the block...this way we can build stations and you can walk on both the top or bottom or inside a torus...i would like inertia for the austonaut too.

Maybe a gravity module with the posibility to add enhancers to increase the size of the gravity, like the dock's system...this way we could have areas in the stations each with their gravity. Or the option to set the field hight/width it the module's menu...the bigger the field, the more power it consumes.

Area gravity generation would probably need to be a new set of gravity blocks. A lot of ships use the existing gravity blocks in their elevator systems, and the builders rely on the fact that the current gravity system only effects one player at a time. (Each player has their own gravity setting.) That way, when one player uses the gravity elevator, the rest of the crew doesn't suddenly find themselves laid out on the ceiling.

On the other hand, inertia effecting the physics of the astronaut sounds like a good universal idea.

 

[Demodor]

Area gravity generation would probably need to be a new set of gravity blocks. A lot of ships use the existing gravity blocks in their elevator systems, and the builders rely on the fact that the current gravity system only effects one player at a time. (Each player has their own gravity setting.) That way, when one player uses the gravity elevator, the rest of the crew doesn't suddenly find themselves laid out on the ceiling.

That's just wrong...i hate it when i create an area with trigger modules that activates the gravity, and when another player walks in, it disables my gravity..the gravity should be one for all. Right now, it's each player affects individually a gravity block, while i want all players to be affected the same in the area of an individual gravity module. You enter into an another gravity module's area, you get affected by that one, while the other players are each affected by the gravity of the module they are in proximity.

This is why i said that "we could have areas in the stations each with their gravity" ( i meant ships too, by the way)

Anyway, soon, the new docking system will be implemented along with the rail system...so no need for gravity elevators anyway. By the way, i don't even use the gravity elevator, i use a system of damage beams with push and pull effect and the cabin is a ship with shields, thus making a realistic elevator.

 

[NeonSturm]

Trigger -> Activation module -> Gravity.

Everything else does not work.

Gravity at least needs a second input : The condition when it is possible to set this gravity alignment.



Previously I made the suggestion about a Logic-User-Block which just stores the last user activating this block.

This would help with a timer for gravity changes if Gravity-Blocks pick the user from this block if one is adjacent.

 

[Bench]

The current logic system prevents anything except activation modules triggered manually or through area triggers, from triggering gravity modules. We don't store who triggered the original sequence of logic that results in the gravity being triggered, otherwise the system could be abused and cause issues. We've discussed solutions previously but with the other projects that are happening it hasn't been a high priority to resolve. At some point we will address improving performance within logic and the topic of gravity modules will be looked at at that time.

 

[NeonSturm]

otherwise the system could be abused

More than a logic-triggered death pulse? . . . In the worst case you just use suicide Bench.

 

[Bench]

More than a logic-triggered death pulse? . . . In the worst case you just use suicide Bench.

It's more the system isn't built for it