Jump Inhibitor Logic

[Heillos]

This is a thread about Jump Inhibitors and their interactions with logic. In particular, it is about how this can be used to a player's advantage.

Obviously, logic can activate a Jump Inhibitor. They act like Flip-Flops, due to coding inconsistencies/the fact that their manual activation is an on/off toggle. They also, unfortunately, forget their state and turn off when their sector is unloaded.

The formula for the discharge per second of a Jump Inhibitor is (10,000+50*BlockCount), and this is where things get interesting in combination with logic. This large flat value (10,000) granted to any inhibitor can be stacked easily, creating much more block-efficient jump inhibitor setups (power-efficiency is off the table, as power cost is always effectively "Discharge*2").

There are some subtleties to this, such as the fact that inhibitors cannot be activated simultaneously (only one of any group given a simultaneous pulse will be activated); this is overcome by activating them in sequence. If activating in sequence, delays are preferable, as high-frequency clocks are prone to errors, especially when deactivating a system. If fast activation/deactivation times remain desirable, consider self-destruction mechanisms. Inhibitors on separate entities can be activated simultaneously, and will obviously still stack their effects.

I have constructed a compact (11x9x52) module that demonstrates the usage of these facts, and as of this edit have successfully resolved previous blueprint errors; it is available for download from the CC here.

This thread maintains its original purpose of discussion regarding the balance of these devices and whether or not they, and similar technologies, should have a place in the game.

 

[Jaaskinal]

I am of the persuasion that the mechanization of in game mechanics is a valuable asset for the diversity of engineering tasks and the general meta of the game. However, there is an argument against such devices for the balance of the game - the same sort of discussion occurred with chain-drives. The use of these devices to skirt the *diminishing* returns of jump-drive inhibitors could be viewed as an exploit, if not for it's power efficiency, for it's massive decrease in size. That being said, even in terms of power, these devices are somewhat easier to power, since they can be docked and are not required to be on the main ship. (You can have the rods of inhibitors have enough power on them to sustain their operation, which would bypass the diminishing returns of on-ship power while also bypassing the power losses of docked power.)

All in all, I would love to see things like this stay in the game, but perhaps not in this sort of way. Engineering should create new and different meta's ( like how the original spamhibitors were not to overpower jump-drives, but to keep them from being activated by making them never quite full.) and should not make more efficient and strictly better solutions ( x-drives.)

 

[Tunk]

Did someone say spamhibitor?

Personally I find the multi activation of comps a bit exploity, mainly due to how compact it is and the ability of a high freq clock to stall/twiddle charge.

Kinda interesting this came up today, as the last line of development I was working on with Az prior to work going to hell was abusing jump inhibition in all its forms.

(Semi back, work was hell)

 

[Heillos]

I am of the persuasion that the mechanization of in game mechanics is a valuable asset for the diversity of engineering tasks and the general meta of the game. However, there is an argument against such devices for the balance of the game - the same sort of discussion occurred with chain-drives. The use of these devices to skirt the *diminishing* returns of jump-drive inhibitors could be viewed as an exploit, if not for it's power efficiency, for it's massive decrease in size. That being said, even in terms of power, these devices are somewhat easier to power, since they can be docked and are not required to be on the main ship. (You can have the rods of inhibitors have enough power on them to sustain their operation, which would bypass the diminishing returns of on-ship power while also bypassing the power losses of docked power.)

All in all, I would love to see things like this stay in the game, but perhaps not in this sort of way. Engineering should create new and different meta's ( like how the original spamhibitors were not to overpower jump-drives, but to keep them from being activated by making them never quite full.) and should not make more efficient and strictly better solutions ( x-drives.)

I must also agree that this device, and those others like it, are an exploit; I find them quite favourable, though, as they should serve to ease the finding of conflict, and decrease the possibility for cowardice. On the other hand, the innocents already preyed upon by normal jump inhibitors will now have an even greater threat to them; at the end of the day, the choice to make good or bad of this technology is with those who would use it.

Did someone say spamhibitor?

Personally I find the multi activation of comps a bit exploity, mainly due to how compact it is and the ability of a high freq clock to stall/twiddle charge.

Kinda interesting this came up today, as the last line of development I was working on with Az prior to work going to hell was abusing jump inhibition in all its forms.

(Semi back, work was hell)

I'm as yet unable to replicate the particular... vigour, shall we say, of your own high-frequency spamhibitors, and as I believe you encountered, turning them off again is significantly challenging/not realistically possible. The compact nature of these devices is only natural, if I may say so; in all fields of this game, shipwrights (particularly those who build for war) will seek efficiency, and it is often found, as it has been here.

If we are to suppose that this is an exploit (I do certainly believe that it is) and that it should be removed from the game (I do not yet believe that there is a reason to "fix" this), I am not certain how it could be removed, without a significant rework of the mechanics. It should not be very difficult to iron out those issues which allow multiple inhibitors on the same entity to be activated by logic, but such a fix would simply lead to logic inhibitors with many docked single inhibitors. This would cut into the efficiency margin somewhat, but not enough to prevent their use.

 

[Proxima_Centauri]

Quite frankly, the "large flat value" should be removed (and it should also be removed from jump drives)

A similar base damage feature used to exist for amc cannons (in 2013) and it made giant checkered cannons super extremely overpowered, and when damage beams were first added they required no power so small checkered arrays of beam+pulse could do hundreds of millions of shield damage in a single shot (a fact that vaygr & calderon and presumably many others used to decimate noobs for months until it was fixed)

It is quite obvious that this """""feature""""" is an unintended consequence of devs thinking "hey lets give small fighters the ability to jump inhibit with this small boost" without realizing that it would break the mechanic in this way.

 

[Zekester81]

Now that's what I call ingenuity. I can see both sides of the argument here, so I will stay neutral. I can readily see why this would be considered an exploit, though I am impressed with the ability of people to make things like this. It just goes to show that some will always go to the most efficient way of doing things. Not playing online, I tend not to run into things like this so currently as a player it doesn't affect me.

I will say that if I were a server operator and a player made something like this, I probably wouldn't have a problem with it. To me, it would seem wrong to punish a player for simply building a better mouse trap so to speak. Players ingenuity advances us all. I would be interested in what the Devs have to say about this, and defer to their judgement as to whether they consider it an exploit.

 

[NeonSturm]

I think that 1m^3 checker-board should be punished in all it's ways (including the recent quadruple armour).
I have nothing against more efficient designs (up to 200% is ok or even 400% if it is only volume, not mass and not cost).

But I hate wasting performance.
The ships should be built to go in line with performance-optimizations intuitively and not counter-act them were-ever possible because it is more efficient.

If a ship can place 8 thruster blocks and 8 others touching these in a set pattern of (above/below/right/left) to activate a 200% thrust cheat for the whole entity, it would be better than any checker-board thing which increases face-count to render.
​

Because of that, I want 100x100x100 blocks before any significant drop-down (>3%) due to diminishing returns.
And a flat value per computer is diminishing returns. Even if that computer costs 10x and modules 1x, it's more volume efficient.

I like ±20% but I hate <33% size or >300% efficiency – that's just too much of a reward for just reading through a forum-post or downloading community content.