Space Engineers Feedback

4
Votes
jumpdrives and API: balancing the space-time bender.
disclaimer: while i will be mostly talking about the jumpdrive, this also aplies to some extent to the ore detector, which is in the same place right now. also, I intend these changes to be shipped in conjuction with an effective jumpdrive countermeasure, since right now there is none. I will propose one, but realy anything balanced should do. So lets get to the main point : jumpdrives are broken... not realy a surprise there. they are a free get out of jail card with absolutly no counter and the ability to just fuck off 5 k away no matter what. and while i do not want this feature removed, there should be a way to keep people in an area. this is why, to balance the jumpdrive, there should be a block to prent its use, the same way you cannot use it on planets, but with a bit of refinement. so let me introduce to you: "the subspace snare module", more commonly known as the jumpdrive inhibitor. this block has a very simple use. it automaticaly turn off any jumpdrives that enters its operating range, and prevent it from being reactivated (either by preventing it or damaging the jumpdrive each time it happens). as a toogleable option, you can also block ships from entering the area through a jump, in that case they would be stoped 1 km on the edge of the jamming field. the jumpdrive inhibitor has a maximum range of 50 km and a very big power consuption, making a constant 50km function unpractical. the generator will also be producing a lot of heat, making it visible on the HUD of anyone within its influance. finaly, the jumpdrive inhibitor will only work if the grid on which it is instaled is stationary. meaning that any movement from its grid would deactivate it. once active, any jumpdrives in the area will be shot down, but could still be able to charge. if the game code dosent handle that, then also prevent the recharge. the first use that comes into mind is use on stations, where it will prevent trolls from getting away of your defences, but has a chance of revealing your position, because of the 50k reveal range. use on ships is more complex, but still possible. through the use of jump inhibition pods you ditch from your ship, or jump inibition torpedoes that would stop and create a disruption bubble, with a bit of clever engineering, you can assault those perpeturaly fleeing ships, and because of the 50k maximum range, you could stop even those who spam the 5k jumps. however, trapping someone in the bubble also means you trap yourself in it, and there is only 2 ways out: get out of the operational range, or destroy the generator. it will be to the player to decide to flee or to go for the generator. now, for the changes to the jumpdrive itself. while the main problem with the jumpdrive comes from the ability to hide in deep space far from all danger, and this is not dependant to the jumpdrive but from other mechanics like teritory ownership, jumpdrives still lack a very big thing: programming API accesibilty. of course adding jumpdrives to the API was probably already considered, but in the curent state, it would only worsen the problem. so i came with a solution: do the same thing as the camera. cams use a charge system to limit their ability to lock stuff. jumpdrives with API support should behave the same. once charged, and they receive either a blind jump order with a range, or a GPS coord, they will begin to accumulate charge. it will be keens job to fix the value, but a 2000km jump should take a program way more time than a human to compensate, something like 5 or 6 mins, that was ships that use programs to keep jumping would have a vulnerability period, on top of the already long recharge times. of course that time would scale with the maximum range, and balancing will again, be dependant on how easy it is to find the grid, mainly depending on other things like territory control or a scan mechanic.


Overwerk shared this idea 20/09/17 11:31