Rail docked entity orientation detection.

[BillGHero]

The idea is that it might be necessary to ensure an entity is facing a specific direction. I tried using trigger blocks on the main entity for this purpose. But docked entities don't activate the parent's trigger blocks. A little research turned up this post in the bug tracker: http://bugs.star-made.org/issues/1986

Apparently using trigger blocks in this fashion isn't to be supported because "...it's a costly inefficient way to do a trigger..". But in order to fully mature the rail system some method of detecting a docked entity's orientation will be essential...

Anybody out there know if there is already a way to do this? Or will this need to be addressed in a future patch?

 

[Adonis0]

An entity which docks to a rail-basic will always orientate the same way, same with the initial docking of the rotor blocks. They orientate to make the docker's arrow point the same way as the arrows on the rail or rotator. From the initial docking it will maintain orientation unless it hits a rotating block

From there, the orientation of docked entities will be easily to calculate, (Rotor block with one attached activation block, 45o from what it was originally, etc)

 

[Knack]

From there, the orientation of docked entities will be easily to calculate

Incorrect, I'm running in huge problems at the moment because as soon as the server is lagging, the rails behaviour is not deterministic.
Yesterday I had it, that the rail-door wasn't rotating while the closing process, for normal no problem, it is designed to correct this at the next opening by collision. (Can't turn down, cause of wall)
But it rotated and got stuck in the hull of the station. That should be impossible, the whole station was correctly loaded.

The relay bad thing: after that it was not possible to rotate or move the door in any direction. Had to undock and bug through the station.

So a detection of the orientation or a rotation block what rotates into an specific direction would be needed to avoid this.

 

[Adonis0]

Incorrect, I'm running in huge problems at the moment because as soon as the server is lagging, the rails behaviour is not deterministic.
Yesterday I had it, that the rail-door wasn't rotating while the closing process, for normal no problem, it is designed to correct this at the next opening by collision. (Can't turn down, cause of wall)
But it rotated and got stuck in the hull of the station. That should be impossible, the whole station was correctly loaded.

The relay bad thing: after that it was not possible to rotate or move the door in any direction. Had to undock and bug through the station.

So a detection of the orientation or a rotation block what rotates into an specific direction would be needed to avoid this.

It's hard to detect things through lag, because by definition, lag stuffs up processes that should work.

 

[Knack]

With orientation indication it would at least be repairable. (in my case)

 

[Adonis0]

Ideas as to how you might do so

Does something being hit by a beam cause an indication?
I.e. detecting that the power supply beam is hitting valid block
if this works, then that would be easy to set up as a routine check. Doors open, and beam is now hitting/block is being hit, confirm movement is successful type logic procedure.

Else, use a second rail object to try and move into the space where the first one is to see if it fails or not. how this works in my head is that this would be more so used as a checking mechanism for when things have gone wrong than a routine check. May ruin the aesthetic to have prod sticks moving about during your movement procedure.

 

[Knack]

In my case, your check by another rail would have failed and both rails were stuck. (The collision check failed for some reason)

 

[CyberTao]

If the game lagging causes a docked ships to glitch into something, chances are logic wouldn't be able to catch it either. The reason it glitches in is because the collision check failed I presume, and running multiple checks on every rail operation would cause a lot more lag than we have already (Rails still have a noticable effect enbulk).

I would say we don't need a system to check the orientation, mainly because ideally the orientation is predictable and only messes up with lag or bugs, which would be sorted out before release. Strapping extra systems and calculations onto something that only happens because of it's alpha state isn't going to help much in the long run, and probably make the whole system feel a lot more complicated for new players.

 

[BillGHero]

Presence/position/orientation detection features will be on the mind of anyone wanting a competitive mechanical feature set. There is no doubt in my mind that the game will eventually have a very efficient option for this.

My interest isn't in arguing over it's value, but sharing ideas on how to detect and/or correct orientation with what is already available.

Personally, my next session in the game will aim to see if I can use a key and channel arrangement with timers to detect and correct a miss-aligned entity.

 

[Knack]

The check would be very simple and would not affect performance.
The use cases are more than to avoid stuck rails, because the orientation is not as predictable as you might think.
In small rail systems where only you are docking things, that should no be the case.
But as soon as other players dock their ships to your very awesome automated docking system, ..., things get strange.
You know, dumb players will mess up your system.

Lags will be better in release, but every game has lags form time to time. That also should not mess up your system.

 

[AndyP]

hm, it could be made like a "lock".

Top down view, of the layer around the base:


and have a small pole raise from below, once it went up (and this can be detected), the position is correct.

Not 100% reliable, but with adjustable stepping down to 45° you should be able to get it in a predicted position.

[edit]
Sure this is not a fix, or adding a function, but it could act as a workaround for the problem, until something gets implemented that allows this.
[/edit]

- Andy

 

[jayman38]

I would think that a rotation block could send out a high signal to a logic block in a ring around the rotation block, perpendicular to the rotation axis. 8 possible rotations, 8 block positions around the rotator. For example:

Legend: R= Rotation block, 0 = low signal, 1 = high signal, rotations are relative to the rotor face.

The rotated entity is facing northeast:
001
0R0
000

The rotated entity is facing south:
000
0R0
010

The rotated entity is facing west:
000
1R0
000

The rotated entity is facing southeast:
000
0R0
001

With all 8 positions around the rotation block filled with logic activators, the builder would have complete knowledge of which direction the docked entity was facing. The builder could place activators at only specific positions if they only cared about those rotations. This would be a self-contained, block-only solution that could be useful for all kinds of neat things.

 

[BillGHero]

hm, it could be made like a "lock".

Top down view, of the layer around the base:
View attachment 13890

and have a small pole raise from below, once it went up (and this can be detected), the position is correct.

Not 100% reliable, but with adjustable stepping down to 45° you should be able to get it in a predicted position.

[edit]
Sure this is not a fix, or adding a function, but it could act as a workaround for the problem, until something gets implemented that allows this.
[/edit]

- Andy

I can see this working too, will have to try it this weekend. Thanks!

 

[Knack]

[edit]
Sure this is not a fix, or adding a function, but it could act as a workaround for the problem, until something gets implemented that allows this.
[/edit]

- Andy

Not working for me, cause the rail would bug into the lock in the same way it bugs into the station
(Only happened once so far and the stations is spawned since a week, while the door only was 5 time opened and closed)

Also as far as I know this could lead to higher load on a server and that's what I want to prevent.
I think I will build something similar, so I can repeat the rotation as long as it is not in the right orientation, but this also leads to new problems. (Infinite try to rotate)

 

[AndyP]

The idea is to use the "movement finished" pulse from the rotator, to "try" to extend the lock-stick into the base.
If it does not reach the top position, turn again.
Could imagine a not too complex logic for that.

Sure trying to extend it all the time, to possibly lock the entity while it is turning will at least cause some server load, and may not work at all, as any blocked movement has a max-move-time when that is not met, the entity returns to pre-move-position and gets a short break from retry.

- Andy

 

[jayman38]

I would think that a rotation block could send out a high signal to a logic block in a ring around the rotation block, perpendicular to the rotation axis. 8 possible rotations, 8 block positions around the rotator....With all 8 positions around the rotation block filled with logic activators, the builder would have complete knowledge of which direction the docked entity was facing. The builder could place activators at only specific positions if they only cared about those rotations. This would be a self-contained, block-only solution that could be useful for all kinds of neat things.

In order to avoid interfering with a rail path, the rotation sensor blocks would need to be placed down one block from the rotator, so that other rotors and rails that further move the attached entity could be directly attached to the rotor being sensed.

Another issue I thought about is sensor interference from adjacent rotors. You wouldn't be sure which rotor was reporting the direction, unless you used an AND block with an activator directly beneath the rotor that gets a high signal at the end of a rotation, regardless of entity rotation.

This means you have up to a nine-block sensor array in a grid directly below the rotator block:
123
456
789

1-4, 6-9: docked entity direction sensors (activation blocks that get a high signal, depending on the direction of the rotated entity)
5: rotor activation block directly beneath the rotor that gets a high signal at the end of the rotation, can be used with an AND block for each rotary sensor block to get an accurate picture of the attached entity's orientation.

You could still use adjacent activator "sensor" blocks on the sides of the rotor that aren't being used by other rail blocks.

 

[Fireshock]

I make it so it always automaticaly replaces all rotator blocks with rail basic when it is turned off.