FTL Discussion Reboot

[Aizria]

Eh, I'm against any sort of teleportation system. FTL should be a fancy way to increase your top speed.

We already have that. It's called Overdrive. Honestly, if that cut it in terms of having in-game FTL, myself and others would not ask for something different. One could, of course, argue that we could simply have a faster version of Overdrive, but the problem with that sort of "FTL" is that, with faster true speed, rather than teleportation, comes more sectors loaded over a shorter period of time, leading to client lag at best because of clients not keeping up, and server lag or crashing at worst due to the server itself not being able to keep up. Not to mention what would happen to a server if someone were, say, travelling a 2,000 m/s and smashed into some solid object or another....even something as small as some asteroids. Personally, a mere "special speed boost" seems like entirely the wrong solution, if not possibly a very bad idea as well.

 

[NeonSturm]

If wormholes would be exactly as fast as normal FTL (due to no direct route) you have no point to argue against it (except because this would be stupid/redundant)

But if you need about 100 blocks+ or >10% of your ship's mass dedicated to FTL, Wormholes (even if they were just as fast as FTL) would make sense.
You don't even know how FTL will get implemented, so you have no reason to argue against it.

You just can argue that we should have FTL first. Luckily (for me) it is not your decision if we get this


FTL is required because you can't hit a ship with any weapon at 40km/s
(IRL that is not even light-speed but the speed to escape gravity)
But IRL we also need a planet's gravity for slingshots to reach realistic inter-planetary-travel velocity. Dividing movement into thrust and FTL seems like a logical step.

 

[jayman38]

I would like to see a fast-travel option that allows you to select any set of coordinates within a certain radius that depends either on server settings or on some sort of hyperdrive engine block count (and maybe geometric arrangement, the more complex the better). Then you disappear within an area that is the size of your ship's maximum dimensions that represents a portal that stays open for about 30 seconds. The portal should have visibility. Like a bunch of translucent glowing ice crystals or something. Maybe make it flicker 5 seconds before it closes and disappears. A sudden flash, such as a plex beacon flare, when it closes might be a nice touch. Any ship that can fit within that area can follow you, but anything bigger just flies right through the portal without entering it and without taking damage.

When your ship goes immediately through the portal, it is in an alternative sector (a generic, maybe temporary, hyperspace sector that is not part of the regular universe) for an amount of time that is dependent on the distance between the departure sector and the destination sector. It would be great to have an animated background to replace the space background in this sector. Lock the traveling ship to 0 velocity in this hyperspace sector. They shouldn't be able to navigate within hyperspace. The time spent in the hyperspace sector shouldn't be a matter of days, like you sometimes see in Star Trek or Star Wars, but should be in minutes (maybe 5 seconds of "hyperspace travel" per 1000 km).

The player should be shown, when selecting the destination, how long the hyperspace travel will take (Example: 4:30), with a minimum of 20 seconds of travel, even if they only pick the next sector over. Then, while they are in hyperspace, the player gets a message (and maybe a quick little alert sound) saying that they are 10 seconds from exiting hyperspace, to give them that time to get back into flight mode on the main ship. While they are in Hyperspace, the player will be free to move about the cabin. I envision it as a great time to get into build mode and fix damage, or go to a plex locker and rearrange some inventory for trading at a shop. Anything the player needs to do that is not flying the ship. Any ship that follows should not be able to see or engage them during this time. It's purely down-time, where the player doesn't need to be alert for attackers. Then they get that warning message that they are coming out of hyperspace, and have a short time to finish up and get back into flight mode. If the player is detached from the ship in hyperspace when the ship exits hyperspace, kill the player immediately. Harsh, but that's life in the 'verse....

When the alert sounds 10 seconds before exiting hyperspace, the game is starting to load the destination sector and all related chunks in the background. Prior to this, the game finds a random open spot in the destination sector. If there is no open spot big enough in the target sector, adjacent sectors are checked for a spot. If no spot is found there either, the ship is destroyed and the player is killed. Automatically do the same thing to any ship that pursues through the same portal. Even if the pursuing ship has a few more seconds before exiting hyperspace, just delay a second or two and take 'em out, to avoid wasting their time. (Although, it might be more cinematic to kill them after they have had to wait those extra seconds. Plus, that would give the original player a few extra seconds to take care of business after respawning, before the pursuer respawns next to them.)

Now, assuming a safe spot is found for the ship to exit hyperspace, they are spawned in that location (teleported from the hyperspace sector), and an invisible portal is spawned in the exiting ship's location. Any pursuers will spawn in this area as well. Since they are known to already fit in the original entry portal, we know they can fit in this portal as well. All exiting ships should be given enough speed to clear the portal in about 1 second. If any ship is still in the destination portal when another ship comes through, that ship is damaged. I'm not sure if we should kill it outright, or do a block-by-block overlay assessment. It might be less frustrating for the victim player to have block-by-block damage when a ship that exits hyperspace overlays the victim's ship. However, that's a big lag spike right there, especially given that the exiting ship will be automatically given a speed to clear the portal. And especially if the victim ship has any velocity of its own. The exit portal will close the same amount of time after the entry portal closes: 30 seconds. More fun versus less lag. Maybe a server setting. If the server can handle it, they can set it to damage-overlay. Otherwise, if the server operator is concerned about lag, just kill the victim ship outright.

Now, assuming that the exiting ship has exited successfully, once the exit portal is cleared, the velocity should drop much faster than normal space friction, or even braking. The ship should travel some distance, but should slow down quickly. The player can immediately push the throttle. Depending on current speed, you can almost immediately hit your top speed and hold it when exiting the hyperspace exit portal.

Upon exiting the hyperspace portal, shield storage should be 0, and should stay there for 5 seconds. Then it starts recharging like normal.

 

[Snk]

(How do I delete this thing?)

 

[Snk]

I would like to see a fast-travel option that allows you to select any set of coordinates within a certain radius that depends either on server settings or on some sort of hyperdrive engine block count (and maybe geometric arrangement, the more complex the better). Then you disappear within an area that is the size of your ship's maximum dimensions that represents a portal that stays open for about 30 seconds. The portal should have visibility. Like a bunch of translucent glowing ice crystals or something. Maybe make it flicker 5 seconds before it closes and disappears. A sudden flash, such as a plex beacon flare, when it closes might be a nice touch. Any ship that can fit within that area can follow you, but anything bigger just flies right through the portal without entering it and without taking damage.

When your ship goes immediately through the portal, it is in an alternative sector (a generic, maybe temporary, hyperspace sector that is not part of the regular universe) for an amount of time that is dependent on the distance between the departure sector and the destination sector. It would be great to have an animated background to replace the space background in this sector. Lock the traveling ship to 0 velocity in this hyperspace sector. They shouldn't be able to navigate within hyperspace. The time spent in the hyperspace sector shouldn't be a matter of days, like you sometimes see in Star Trek or Star Wars, but should be in minutes (maybe 5 seconds of "hyperspace travel" per 1000 km).

The player should be shown, when selecting the destination, how long the hyperspace travel will take (Example: 4:30), with a minimum of 20 seconds of travel, even if they only pick the next sector over. Then, while they are in hyperspace, the player gets a message (and maybe a quick little alert sound) saying that they are 10 seconds from exiting hyperspace, to give them that time to get back into flight mode on the main ship. While they are in Hyperspace, the player will be free to move about the cabin. I envision it as a great time to get into build mode and fix damage, or go to a plex locker and rearrange some inventory for trading at a shop. Anything the player needs to do that is not flying the ship. Any ship that follows should not be able to see or engage them during this time. It's purely down-time, where the player doesn't need to be alert for attackers. Then they get that warning message that they are coming out of hyperspace, and have a short time to finish up and get back into flight mode. If the player is detached from the ship in hyperspace when the ship exits hyperspace, kill the player immediately. Harsh, but that's life in the 'verse....

When the alert sounds 10 seconds before exiting hyperspace, the game is starting to load the destination sector and all related chunks in the background. Prior to this, the game finds a random open spot in the destination sector. If there is no open spot big enough in the target sector, adjacent sectors are checked for a spot. If no spot is found there either, the ship is destroyed and the player is killed. Automatically do the same thing to any ship that pursues through the same portal. Even if the pursuing ship has a few more seconds before exiting hyperspace, just delay a second or two and take 'em out, to avoid wasting their time. (Although, it might be more cinematic to kill them after they have had to wait those extra seconds. Plus, that would give the original player a few extra seconds to take care of business after respawning, before the pursuer respawns next to them.)

Now, assuming a safe spot is found for the ship to exit hyperspace, they are spawned in that location (teleported from the hyperspace sector), and an invisible portal is spawned in the exiting ship's location. Any pursuers will spawn in this area as well. Since they are known to already fit in the original entry portal, we know they can fit in this portal as well. All exiting ships should be given enough speed to clear the portal in about 1 second. If any ship is still in the destination portal when another ship comes through, that ship is damaged. I'm not sure if we should kill it outright, or do a block-by-block overlay assessment. It might be less frustrating for the victim player to have block-by-block damage when a ship that exits hyperspace overlays the victim's ship. However, that's a big lag spike right there, especially given that the exiting ship will be automatically given a speed to clear the portal. And especially if the victim ship has any velocity of its own. The exit portal will close the same amount of time after the entry portal closes: 30 seconds. More fun versus less lag. Maybe a server setting. If the server can handle it, they can set it to damage-overlay. Otherwise, if the server operator is concerned about lag, just kill the victim ship outright.

Now, assuming that the exiting ship has exited successfully, once the exit portal is cleared, the velocity should drop much faster than normal space friction, or even braking. The ship should travel some distance, but should slow down quickly. The player can immediately push the throttle. Depending on current speed, you can almost immediately hit your top speed and hold it when exiting the hyperspace exit portal.

Upon exiting the hyperspace portal, shield storage should be 0, and should stay there for 5 seconds. Then it starts recharging like normal.

Great idea. I'll delete my previous post because of it. I'd still like for people to see you, though. Maybe they'd see a flying warp bubble, and you could create weapons to stop it?

 

[jayman38]

Great idea. I'll delete my previous post because of it. I'd still like for people to see you, though. Maybe they'd see a flying warp bubble, and you could create weapons to stop it?

Area-effect Denial fields! Maybe a secondary effect of Ion effect systems or something. If your pursuer is too close, and their area-effect denial touches you, no fast-travel escape for you!

 

[Snk]

Anti-warp mines! Of course, anti warp weapons would do no physical damage because you wouldn't see them.

 

[jayman38]

I think you're right. It'll need to be weapons like beams. An area affect will be too hard on the server to calculate. Especially if it's in the middle of a raging battle. That's not to say that area-effect denial isn't possible, but it might need to be limited to static locations like asteroids, planets, and stations.

 

[NeonSturm]

Maybe the warp bubble could fly through all passed sectors with warp-simulation more or less simultanously to not have a 20km/s bubble.

Just start it when a player is at ((warp)progress-fixedTimeOffset) *(count)#sectors = #sector in a line between A and B.

But only if this sector needs it (anti-warp mines, intercepting pirates or players)

I think you're right. It'll need to be weapons like beams. An area affect will be too hard on the server to calculate. Especially if it's in the middle of a raging battle. That's not to say that area-effect denial isn't possible, but it might need to be limited to static locations like asteroids, planets, and stations.

It is possible.
A^2 + B^2 = C^2
abs(x1-x2)^2 + abs(y1-y2)^2 + abs(z1+z2)^2 = distance^2
distance^2 < radius^2 = core inside
raidus^2 needs only to be calculated once.

no need to check against the box. against big ships you need a stronger interception-field any-ways, why not a bit larger too?

 

[Dragon2000]

what about a warp disruption field that could be set up around a station or somewhere (maybe not on a ship that might be a little too powerful but could be cool) that inhibits a warp field this could mean that no one could go to warp hyperspace slip space what ever you want to call it but it could be a cool idea of defense and possibly if on a ship could be used to stop a ship retreating from battle at warp sure they could run with normal thrusters but there are ways to stop that as well

 

[therimmer96]

Wormholes should be completely invisible until a player gets close enough to them, say 2km, then it suddenly erupts in front of you, and starts dragging you in, lowering shields and causing all kinds of havoc with your systems (effects wormhole has should be randomly generated with the wormhole, with the chances of no effects, creating a "stable" wormhole) . its then down to whether you have enough thrust or the stop effect as to whether you get away. If you don't, you get sucked through the wormhole.

Idea for using the silly little map we have now along side the warp system
If you pass through a sector with a planet or star in it, you get destroyed, so you have to actually open the map, plot a course through, and then jump. If you do enter a planet sector, the gravity disrupts the warp field, and the ship gets tore apart and appears in many parts in that sector. It would provide a balance in the form that you can only go as far as you are willing to plot/the map will render and it actually takes time to plot, so you can't just warp away from battle.

 

[FunnyBunny14]

I remember seeing a video on what I think was the teleport command, and those animations were amaaaazing. Teleport FTL is fine if it looks like that.

 

[therimmer96]

There is no animation for the TP command. there have been several videos done in editing software which show what it could look like

 

[jayman38]

The hyperspace in the Freespace series of games were my favorite in-game FTL transportation. I just didn't like the in-transit combat. Trying to perform combat maneuvers while the wormhole is warping past (animated background) can make a guy sick to his stomach! (In actuality, I just got disoriented and thrown off course a little when trying to track enemies.)

I love the idea of a wormhole gaping in front of you suddenly. I always liked that bigger-than-life visual on the Star Trek Deep Space Nine show. And suddenly it's too late to slow or turn around! It's got you now! Going in!

Even with relatively simple particle effects, such a big effect would be fun to see. And probably even better to experience. Lag city, but oh-so worth it. (Hey, gamify lag, and call it an effect of the wormhole disrupting time/space!)

 

[Ithirahad]

The hyperspace in the Freespace series of games were my favorite in-game FTL transportation. I just didn't like the in-transit combat. Trying to perform combat maneuvers while the wormhole is warping past (animated background) can make a guy sick to his stomach! (In actuality, I just got disoriented and thrown off course a little when trying to track enemies.)

I love the idea of a wormhole gaping in front of you suddenly. I always liked that bigger-than-life visual on the Star Trek Deep Space Nine show. And suddenly it's too late to slow or turn around! It's got you now! Going in!

Even with relatively simple particle effects, such a big effect would be fun to see. And probably even better to experience. Lag city, but oh-so worth it. (Hey, gamify lag, and call it an effect of the wormhole disrupting time/space!)

Meh, if done right it shouldn't cause too much lag... Not much more than, say, giant thruster plasma cones.

 

[Snk]

AI+Damage pulse=mines.

 

[takethispie]

what I think about how FTL should works in Starmade:

it should not use pure block count because big ship already have a lot of block with effect/weapon and as a planetoid/heavy planetoid builder I know what I'm talking about !

instead it would have a little part of block count because only one block for hyperdrive won't be roleplay-friendly nor good at all
let's say 1 "hyperdrive module" per 100 mass, you CAN have less blocks than the amount needed BUT your hyperdrive will take more time to start ! so the base time to start the hyperdrive is 20 seconds and the maximum is 5 minutes when you have only one hyperdrive module

the starting range is 100 sector and then +1 sec per 5 sectors , imagine you are at 0,0,0 if you want to go to 900,0,0 it will take 3 minutes with the right number of hyperdrive module

the hyperdrive system will use energy but not the way you might think, when you start the hyperdrive the spaceship's energy bar will go empty and your shield will be down wich is something really good in terms of gameplay, I think, as you can't escape from a dogfight using warp

a ship wouldn't be able to use FTL if his mass < 1000.0

this would be a first implementation , not the only FTL system available because I think schema won't put all FTL systems in one updates

 

[matheod]

For me doing a FTL should require lots of energy depending on the mass of the ship. We would have to put FTL block on our ship to do it (with a FTL computer that we link to hotbar). Each FTL block take some energy from the ship, until enough energy is taken and then the FTL is done.

So adding more FTL block should decrease time to do the FTL, but it would be effective only if we generate enough energy. Having too many FTL block could be dangerous because we no longer have energy after the FTL.

 

[Mikisew01]

I would not mind the idea of having gates and FTL drive. FTL drive would need to be cost or energy prohibitive...so there would be drawbacks in building ships with them...so just the big ones...or the intentional scouts waste the space on them. I would see gates as not necessarily being heavily size prohibitive...but I would not see them as player created. Instead, I would see them as world generated (like shops), and indestructible. Thus they become strategic points in the world, and they provide access for all. Has something of a Star Trek DS9 wormhole, and Stargate SG-1 stargate feel about them. They are not able to be affected by players...but can be used by players and become points to defend in the universe. FTL is the way around this requirement...but takes more time.

 

[whooplaah]

Increasing top speed creates lag on servers and the player's computer. I think that it would be best to have a teleport system, but if not done correctly that takes out the expansive feel of space.

Blocks:
For a Ship
FTL Drive Computer (have to have it to activate the FTL drive from the quickbar)
FTL Drive Module (the more you have, the faster the FTL drive charges)
Navicomputer (a way to store discovered beacons/gates, and can be used to analyze portals opened by other ships to determine the coordinates to which it opens)

For a Jump Gate
FTL Jump Dock Controller (the actual location of the beacon. It can accept a number of incoming ships according to the number of FTL Jump Docks tied to it, so long as they aren't being used for departure. Incoming ships are assigned to the smallest docking area in which they fit.)
FTL Jump Dock (a docking port for a ship preparing to use an FTL Gate and the point over which a ship appears when it jumps in. Can be set to allow/disallow faction, allies, neutrals, or enemies. Once docked the player is prompted to choose a beacon from the navicomputer or purchase one from the Jump Gate's store. The player can choose to cancel their jump at this point to undock. When the location is selected, charging commences and cannot be stopped.)
FTL Jump Dock Enhancer (makes the docking area able to accommodate larger vessels)

Mechanics:

• When an FTL portal is opened it is one way. You do not need to worry about opening a portal and having something on the other side jump through to your location. You have to open a new portal to make a return trip.
• Only ships can travel through an FTL portal. Astronauts who attempt to walk/fly through are killed. Projectiles are destroyed at the entrance to the portal. Disentegrators are also destroyed unless part of a player-piloted ship.
• The amount of charge needed to jump is based upon ship dimensions and the distance to the landing beacon.
• The rate at which the FTL charges is determined by the number of FTL modules onboard the ship. Because it pulls energy/sec from the ship, it cannot charge faster than the ship produces energy.
• While charging an FTL Jump the ship's engines are disabled. It can neither move nor turn (hopefully there are turrets defending you). This is to prevent players from charging their FTL before entering a battle.
  
• While charging, a wormhole opens in front of the ship growing as it charges. This provides a visual for determining how close another ship is to jumping.
• By locking onto a portal opened by another ship, you can determine the coordinates to which it is jumping.
• If another ship flies through the portal before it is fully charged it will teleport. The FTL drive is drained according to however much energy was needed to send the ship through (this means that a Freighter's jump can be delayed if enough smaller vessels go through the portal while it is charging, and they can then wait in ambush if they weren't destroyed in the jump).
• At 33% you can jump, but doing so will deplete shields, deplete energy, disable navigation, and damage the ship. Energy, shields, and navigation remain down for whatever amount of time it would have taken to fully charge the FTL drive. Use only in emergencies.
• At 66% you can jump without worrying about damaging the ship, but will still loose all shields and energy for whatever amount of time it would have taken to fully charge the FTL drive.
• At 100% you can jump without taking damage and without loosing navigation. Shields and energy are depleted but begin recharging as normal.
• Once it begins charging, FTL jumps cannot be canceled. This is to prevent larger ships from acting as mobile FTL gates.
• If the landing zone (determined by the placement of the FTL Jump Dock) has a ship docked for departure, it cannot be selected as a destination.
• The landing zone must be clear for a jump to commence automatically. If the landing zone is obstructed, the player is asked to either wait or force jump. Engines remain locked while waiting for a landing zone to clear. After 60 seconds of waiting for an obstruction to clear, the FTL jump is cancelled.
• If the player chooses to force jump into an obstructed landing zone, all players within that zone are killed. Additionally, all blocks with the area are turned into disintegrator blocks and detonate after the ship arrives. Because jumps disable shields, this damage is applied directly to hull and components.

Discussion:
I think that FTL should have both a MINIMUM and MAXIMUM jump distance. That way you can't abuse the system too much. Fly short distances in your ship, jump medium distances using beacons/gates, and use multiple gates to jump longer distances.

I think that jump gates or beacons are a necessity. If I can use an FTL drive to jump to random parts of space I've never been to before then I'm cutting out the feel of the expansive nature of the game. Having beacons/gates as static (station) objects will force factions to protect them (instead of moving it away) and will make coding the entrance/exit coordinates much easier. If someone is driving the capital ship/FTL gate around, and then logs out, what happens to that beacon as an exit point? When they log back in, what happens?

Building FTL Gates would also be a way for a faction to make money. They spent the time constructing the gate, so anyone using it should have to pay per jump (maybe at a discount for allies).

When a ship uses it's FTL Drive it can only jump to a beacon stored in the navicomputer. This makes faction alliances more rewarding, and the coordinates for gates can be traded/sold/gifted to ships with new navicomputers (let's hope you keep yours well protected). This makes it less desireable to swap out a ship for a new one, as beacon information must be rebought or transferred.

When attempting to capture an FTL gate from an enemy faction, stopping up the FTL Dock Zone is a good way to prevent reinforcements, or at least damage them when they arrive. Additionally, if too many attempt to jump through at once they may destroy each other.