I'm sorry but intent is not enough. I've highlighted the special order sequence of combat jump on N3. I've noticed Combat Jump been released without changes to fix It's weird order sequence when C1 was launched. At that moment I thought it could be a probable source of problems and I reported It. I don't understand why this "issue" has passed from N3 to C1, and from C1 to N4. Everything regarding combat jump and controlled jump design is fuzzy. Enemy's can declare ARO after the resollution step of the declaring AROs The Combat jump skill describes a different order sequence. No AROs before putting the trooper on the table. So no combat jump to interfere with the AD trooper l jump can't be declared as ARO if the AD trooper doesn't enter inside the hacking zone. As I understand the 3rd point of the EFFECT section of program; "This Program’s range covers the entire game table"; it can only be applied to the effect, not as an exception to the conditions required to declare a valid ARO The program doesn't work as intended and the combat jump skill is a mess. One or both skills need to be FAQed just a few weeks after global launch. In my opinion the solution comes by Explicitly say in the program description: "controlled jump can be declared as a valid ARO when an enemy trooper declares combat jump". Because without that phrase the program is subject to the same hacking ARO conditions the rest of the programs have to be a valid ARO... In other words, Having LoF, enemy activated in ZoC, or enemy activated inside Hacking zone. Fix combat the combat jump sequence inside the description and make it fit to the normal sequence. It's not so hard: - Declaration of the Normal Entire order, and thus declaration of the intended landing spot, - ARO declarations, - Rolls, (If the AD troop fails It's PH roll, the effect of the declared ARO attacks are nullified in the next step and instead is deployed on his player deployment zone), - Effects, damage saves & guts
This is an honest question - did you read the whole of what you just quoted, where I said that the rules text isn't good enough? I'm providing the intent as a temporary measure so that players can actually use the Skill, until CB let me re-write it properly. OK. I'll happily place my AD Trooper right behind the enemy in my Deployment Zone, without granting them an ARO.
Ehm... what? sorry, I don't understand. Maybe is some kind of a language barrier (I'm not an English native). Can you develop your point a little further? If I understood right, the intention of the current version is to make a PH roll before (out of the normal sequence) to see if enemies go ARO in the first place. Isn't kind of the same to Let them have ARO either way and nullify the effects of their AROs if the AD troop fails but without layers of unnecessary complication regarding the order sequence? And regarding me explicitly saying "ARO attacks", I made it because you skip the shitstorm that is originated if you nullify all kind of AROs... some possibly could understand that this could end up AROS like nullifying controlled on the way. I don't see the problem if the ARO is not an attack, what's the worse case scenario, some enemies in an specific 8" radius being able to reset or dodge for free? I don't see a big issue in letting some troops to move and reposition a little in reactive if they really want it.
Your suggested update has Combat Jump Troopers that fail their PH Roll be placed in the player's Deployment Zones after AROs can be declared. EDIT - which messes up the Order Expenditure Sequence far more than the actual Combat Jump Skill.
yeah, and Attacking AROs become nullified on the resolution step if the CJ troop fails It's Test (don't skip that part). There are skills that nullify attacks on a success (dodge, reset, zero pain), I dont see Why a fail can't do sort of the same. The result of the suggested change obeys the order sequence and with almost an identical result to the intended mechanic. The only situations where the suggested change affects one of the players is one of the following 2 Attack AROs become nullified (disposables are wasted). Reactive Troops that declared dodges can move. On the current version, the Combat jump troop deploying on It's player's deployment zone border could be generating an ARO , On the contrary It would not get an ARO in the suggested one. But let's be honest ,If the active player deploys It's AD trooper with LoF on purpose... is gonna end up locked without cover and probably with bad ranges too. It's not so far away from deploying on your border without providing LoF. The chances of this becoming an exploit are very low. I don't think is such a big issue. If the troop jumps is precisely because It doesn't want to deploy so far behind and want's to fall close to the enemy or in an advantageous spot. I think a change like that is a small price to pay If you want a general rule like the ORDER EXPENDITURE SEQUENCE to be absolute. No other skill has an ARO declaration sequence after the resolution step. It's confusing and causes weird interactions. EDIT: There may be a better version of the change. It's not my role to choose the final version wording, nor I'm being paid for it. The main point is submitting combat jump to the main rules and the same order sequence of every other skill while avoiding weird interactions and special cases
I have a general question for hacking, but more specifically with this skill. What is the duration ? In N3 there was a column indicating 1 turn or 2 turns. Controlled Jump seem to be effective "as long as it is active" and is also placing a "Sup:CJ" token next to the user. So... is the program active until the token is removed ? Is it only removed by executing another skill that also places a Sup:x token ? That is what seem to be implied in the Supportware Programs paragraph. Once I run Sup:CJ in my turn to land my own combat jumpers, then it is active in the enemy turn ? With that being true, I don't need to ARO with it as I can pro-actively do it in my turn.
One Supportware per hacker, one supportware per beneficiary, unlimited duration until cancelled (e.g. Hacker going to Dead, Hacker declaring new supportware, etc) Page 59 IMPORTANT ◼ A Trooper can benefit from the effects of only one Program with the Supportware Label at a time. ◼ Each Hacker can only sustain one active Supportware Program at a time. ◼ A Hacker can cancel an active Supportware Program by declaring another Program and expending the corresponding Order or ARO. ◼ A Supportware Program is automatically cancelled if the Trooper or Troop Type targeted by the Supportware is targeted by a new Supportware Program, or if the Hacker running the Program enters Isolated State or any Null States.
