Rail System Improvements + What next?

[Auriga_Nexus]

So, this is basically a list of things that have been mentioned a few times around on the forums in some cases, in other cases just some personal improvements I would suggest for both the rail system and for upcoming additions. So here goes, start with rails first:

1: Multi-sided rail blocks
Having the rail system like we have so far is pretty good, but I personally think that rails shouldn't be one-sided, instead they should be like a segment with four rails on the X and Y faces of the blocks all pointing toward the same direction on the Z-axis. This allows a bit more variety when docking ships as not only can you determine what direction your ship should be facing, but also which side of the rail it is docked to. Default would be whatever of the rail block faces the docking block is closest to when it docks... so if you have a straight line of rail blocks protruding outward, docking while ABOVE the rail will dock your rail docker on top of that line, docking while BELOW will dock you below the line (rotating your ship so that the docking block is still flush with the rail), etc. This cut down on the possible ways a rail block would need to be oriented (3 possible orientations with the rails pointing toward one side or the other, that's 3x2=6 possible orientations as opposed to the current 6x4 =24).

2: Combo rail
This one's a doozy. It's basically a combo of both the rail blocks (as described above) and the rail dockers. It functions like a rail docker in the sense that it can dock to another combo rail block on the same Z-axis. On the X and Y faces it has normal rails, on the Z faces it has a combination between a normal rail and a rail docker.
The main use for this is that the combo rail can function both like a rail and a rail docker, but when two combo rails are flush with each other, they are considered "docked", and if there is a rail moving along the axis perpendicular to the connecting plane between two combo blocks it will treat the combo blocks as a single rail entity even though they are on separate entities. This means anything going along that rail can transfer from being docked to one entity to the other automatically as it moves along the connected rails.
On top of having a third entity move across the first two, if there is a rail parallel to the contact plane, the second entity can move along that as well. This allows you to build, say, an elevator shaft linking a rail from the hangar bay of a carrier to the rail on the catapult deck, allowing a fighter to move from the hangar rail to the elevator rail, then the elevator platform moves down the shaft until it connects with the launch rail, which in turn allows for transition from the elevator to the launch deck.

The combo rail would basically solve both of these suggestions at once:
http://starmadedock.net/threads/all...el-along-rails-made-of-multiple-sections.7376
http://starmadedock.net/threads/allow-rail-dockers-to-dock-with-other-rail-dockers.7396


3: Rail accelerators and altering rail speed
So I'm going to go out and say it. Rails are really. Freaking. Slow. Even with a maxed-out speed controller and no mass penalty an entity moving along a rail moves only marginally faster than your astronauts's space flight speed. I can understand how additional speed can be a problem especially when calculating collision detection, but it makes any idea of a catapult rail less than useless.

My suggestion is a block specifically designed to "boost" rail-docked entities as they move. This is the idea behind the rail accelerator. It ignores the rail "max speed" and instead accelerates the entity by a set amount, say 10m/s. Multiple rail accelerators would add sequentially until it reaches server max speed, so an entity going around 10 m/s would be going 100m/s after hitting 9 rail accelerators in a row.
They can be arranged directionally like normal rail blocks, the difference is that they do not change direction, just velocity. In other words, placing an accelerator block in line between two rails pointing the same direction would work the same, but an accelerator pointing the opposite direction would cause the ship to decelerate but still move in the direction of the rails. Of course the rail blocks directly in front of and behind would have to face the same direction as well.

Which leads me to my third feature of rail accelerators: if a line of rail accelerators are not bounded in line by rail segments or if the rail segments are not facing the same direction relative to each other, then when the entity reaches the end of the line of accelerators, it instantly undocks, retaining whatever velocity it had at the time it separated. This means, of course, that a solid line of rail accelerators that terminates without additional rails at the terminus will fling the docked object off of it at the speed it was going when it hit the last block. Boom, catapult.

Of course, there would be a drawback to using rail accelerators, that would be that they consume power like rail mass enhancers, and they also will not function period for overweight entities, meaning that you have to have enough power generation to power both the accelerators themselves and enough mass enhancers to bear the full load of what you are accelerating. We could also have it to where accelerators consume energy only when they activate, and the energy cost scales based on the objects mass and its current velocity (which makes sense physics-wise).

4: Behavior of wifi blocks
While we're on the subject of realism, the current method of using wifi blocks is not only difficult, but unrealistic. Difficult because if you want multiple ships to be able to activate the same entity, you would need to put a wifi block for each ship. Unrealistic because true wifi is a radio broadcast, not a point-to-point connection. When you are connected to a wireless network, information is broadcasted to every device in range; the wireless receivers on your computer and the access point determine which packets are addressed to you via your IP address and discard the excess.
I personally think when dealing with wifi blocks we should treat them less like a wifi connection and more like the transponder and radios on an aircraft. In the real world ATC uses a variety of channels on which to communicate with planes; any radio tuned into that frequency can pick up the transmission regardless if it is the intended recipient. For the most part, a lot of space-fighter games and media use the same concept regarding ship-to-ship communication, which is where the phrase "switching to a secure channel" and similar concepts come from. Instead of having to connect wifi blocks manually, we should be able to set a frequency number or name (something that is already possible with inner-ship remotes and should be just as easy to implement for wifi blocks), and have it activate any wifi block that shares that name. This has already been suggested before but I am re-suggesting it for its brilliance. Need a public docking bay that can be accessible to any ship with a hangar door that opens and closes? Simply set a wifi block to "Docking Bay N1", and connect to the door controls. When ships arrive they need only have rename a wifi block to "Docking Bay N1" and they can open or close the hangar from their ship.

There are other enhancements I have thought of as well, but I will post those later.

 

[NeonSturm]

1: multi-sided rails:​

Thought of this before, like it and am glad that I am not the only one who thought about this.

I did not post it because I didn't want to steal somebody the chance to get this idea himself (or herself).

And because I saw the problem if you combine it with (2)

2: combo rail:​

I actually wrote that in another thread.

Rails of different entities are like magnets with a positive and negative side to connect different entities in one continuous rail.

The problem: how would you sync directions between entity A and B.

3: Rail accelerators:​

Perhaps basic rails should have no direction at all, just an axis of movement. IRL it's the train which chooses the direction, not the rail.

If logic directed into a rail is repeated by the rail docker, you can command the train - if it accepts commands.
Likewise you could direct logic into a rail docker to communicate with the rail entity.

• Because you can't automatically connect free WiFi blocks between docks and docked right now.

Currently we have 24 rotations = 5 bit.
Use 2 for the axis (0, x, y, z) where 0 is disabled, STOP.
Use 1 for the direction (positive, negative) along an axis.
Use 2 bits for serial logic (Maybe | clock <-> or | data <-> and)

4: Suggested over and over again :p​

But I still like it

What is your opinion about hacking?

 

[Snk]

Make rail dockers activatable by logic. That's a pretty big one

 

[Auriga_Nexus]

1: multi-sided rails:​

Thought of this before, like it and am glad that I am not the only one who thought about this.

I did not post it because I didn't want to steal somebody the chance to get this idea himself (or herself).

And because I saw the problem if you combine it with (2)

2: combo rail:​

I actually wrote that in another thread.

Rails of different entities are like magnets with a positive and negative side to connect different entities in one continuous rail.

The problem: how would you sync directions between entity A and B.

3: Rail accelerators:​

Perhaps basic rails should have no direction at all, just an axis of movement. IRL it's the train which chooses the direction, not the rail.

If logic directed into a rail is repeated by the rail docker, you can command the train - if it accepts commands.
Likewise you could direct logic into a rail docker to communicate with the rail entity.

• Because you can't automatically connect free WiFi blocks between docks and docked right now.

Currently we have 24 rotations = 5 bit.
Use 2 for the axis (0, x, y, z) where 0 is disabled, STOP.
Use 1 for the direction (positive, negative) along an axis.
Use 2 bits for serial logic (Maybe | clock <-> or | data <-> and)

4: Suggested over and over again :p​

But I still like it

What is your opinion about hacking?

I don't understand what you mean by hacking, are you referring to in-game mechanics to circumvent faction-locks?

 

[NeonSturm]

I don't understand what you mean by hacking, are you referring to in-game mechanics to circumvent faction-locks?

Need a public docking bay that can be accessible to any ship with a hangar door that opens and closes? Simply set a wifi block to "Docking Bay N1", and connect to the door controls. When ships arrive they need only have rename a wifi block to "Docking Bay N1" and they can open or close the hangar from their ship.

That.
Somebody may spy your blueprint and access internals (like entity-entity interaction with your docked reactor or security-lock) you don't want him to access.

If you suggest something like this, also suggest a solution to hacking.
Like: You can set whether a WiFi asks for confirmation (to logic) before connecting to a new entity.

What happens if 3 have the same name? Who is listener, who sender?
May all send to that channel and ignore their own signals?

 

[Auriga_Nexus]

That.
Somebody may spy your blueprint and access internals (like entity-entity interaction with your docked reactor or security-lock) you don't want him to access.

If you suggest something like this, also suggest a solution to hacking.
Like: You can set whether a WiFi asks for confirmation (to logic) before connecting to a new entity.

What happens if 3 have the same name? Who is listener, who sender?
May all send to that channel and ignore their own signals?

Well the idea was that only wifi blocks within detectable range i.e. "on grid" would trigger, and that the signal would broadcast itself once and then stop. in other words, you click one wifi block and it pulses, kinda like how buttons work, and any wifi blocks within range on the same band will pulse as well. To be honest it would be easier with this system if wifi blocks just pulsed rather than changing state, it would limit confusion as blocks on the same frequency came and left the grid, and if you want the functionality of a toggle switch... well that is what the flipflop block is for, hooking a button into a flipflop basically does the exact same thing as an activation module. The only difference is that the flow of logic is in one direction and the network topography is a centralized wheel spoke and not a web/n-gram configuration.

As far as hacking, well you would have to deal with that possibility. Going back to my hangar bay idea, if someone is using the hangar and they don't want others to be able to open the door they need only place an AND-signal in between the door control system and the wifi block that triggers the system, then connect an activation module to that. When the activation module is inactive the system is locked and the door will not open.

Though I do agree the potential risk is high and in some cases a manual lock-unlock switch may not be an effective solution. Not to mention if everyone uses this system we will need a lot of space for unique names. How about this: in addition to the frequency wifi blocks follow faction rules, meaning a wifi block from a foreign faction cannot activate a wifi block on a faction-locked entity, even if the frequencies match. Of course for public stations you can use a faction permission block to circumvent this as needed.

The frequency system itself was never meant to be a secure method of data transfer, it is merely meant to have a measure of control over which wifi blocks activate which.