Quote:

---

That would be an option, but i do not think that it would work as well since its so tied to the cycle time of the ship. It will be either useless against small ships or very strong against large ones. As well, it might pair too well with sensor damps. Since you would break their lock and then reduce their lock time to untenable levels producing a perma-jam too easily.

There is another option which would both resolve the "stacking" issues from multiple ships as well as resolve the "you can't do anything while you're jammed" problems.

Instead of ECM breaking your lock, it adds to an new attribute on your ship. When you attempt to activate any targeted module [or send drones to a target], you make a roll against this value divided by your sensor strength. If you fail(I.E. the jam works), the module is not activated but cycles as if it was. [it can either turn off at the end of its cycle, or auto cycle and try again, depending on implementation goals].

What this does is makes it so that ECM does not totally shut a ship down for 20 seconds 50% of the time, but shuts 50% of the ships targeted capabilities down on average all the time. As well, since it does not prevent ships from locking, there is no problem with relocking. Since it adds/subtracts to a value on the ship, stacking penalties can be applied like any other value.

ECCM can be a flat minus to this value[making you immune to low strength ECM and reducing the chance of jam from high strength ECM]. It could also be a flat + to sensor strength which would probably be better.

There are three problems, two it shares with yours[you have to rewrite all the bonuses and abilities, and you can create perma-jam situations more easily] and one new one[lag]. Then again, the more i think about lag, the less i think it would have an effect. Since the module is going to cycle anyway, each player only has to know the result of the activation and not that he was jammed. So the same information is going back and forth each way. What happened, and who is jamming you. This will still increase the amount of calculation that the server needs to do[another random die per targeted module].

Anyway, lets give an example to make it clear

Enemy 1 in a megathron shoots at friendly 1 in a Raven. Enemy 1 has 5 ECM drones and they all have a strength of 2. The Raven has a sensor strength of 22.

So the first ECM drone adds 2 to the friendly raven's ECM stat. The second adds 1.74 the third adds 1.14 the fourth adds .56 and the fifth adds .1 for a total of 5.54.

So, every time friendly 1 attempts to use a targeted module, that module will do nothing 5.54 times out of 22 or 25.1% of the time. When friendly 1 unloads his torps into enemy 1, each torp only does damage if it passes the ECM check. When friendly 1 webs enemy 1, the web only works if it passes the ECM check. Ditto scramblers etc.

Alright, now a falcon comes along and jams friendly 1 on top of the drones. He has 2 racial jammers at 14 points each and lays them down. Now the chance that our friendly megas will be unable to use any specific module is 14+12.15+1.14+.../22 per activation.

The raven can't activate any targeted modules because the jam strength is over his sensor strength. If we wanted to get around that, we could hard cap your "jammed" stat at some % of your sensor strength. This would not prevent a jam, but would prevent a jam from totally locking you down all the time.

Make sense?

---