AttachEffect.Cloakable Bug

dodgevipergts · Chem Warrior **Joined**: 31 Jan 2011

Infantry which have the Cloakable.Deployed Tag are not cloaked by a weapon which uses AttachEffect.Cloakable. No matter what they only cloak when deployed.

Atomic_Noodles · Defense Minister **Joined**: 05 Oct 2011

You answered it yourself. Its an override and prioritizes cloaking only to work on the units when deployed...

_________________
~ Excelsior ~

Graion Dilach · Posted: Tue Oct 28, 2014 11:31 am Post subject:

As far as I seen last time, the same happens in case one uses CloakStop.

_________________
"If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more...

dodgevipergts · Chem Warrior **Joined**: 31 Jan 2011

Atomic_Noodles wrote:

You answered it yourself. Its an override and prioritizes cloaking only to work on the units when deployed...

I wasn't asking a question...

Atomic_Noodles · Defense Minister **Joined**: 05 Oct 2011

You seem to be becoming grumpier like us too.

_________________
~ Excelsior ~

ApolloTD · Commander **Joined**: 19 Nov 2003

I would not call this a bug from a technical viewpoint and what you ask for is a exception to an override...

Problem is, technically cloakstop/deployedinfcloak units always have a cloak but they are simply kept disabled until meet the condition and thus you can't add cloak from an outside source such as AE as unit basicly has it already and if it did allow it, this could cause serious issues for game engine when it might run double instance of cloak or frankly just crash if you went deploy cloakinf and also had AE cloak enabled.

To avoid all that would demand coding more exceptions to disable the other when other exists and so on.

I don't think this is gonna get changed...

dodgevipergts · Chem Warrior **Joined**: 31 Jan 2011

ApolloTD wrote:

I would not call this a bug from a technical viewpoint and what you ask for is a exception to an override...

Problem is, technically cloakstop/deployedinfcloak units always have a cloak but they are simply kept disabled until meet the condition and thus you can't add cloak from an outside source such as AE as unit basicly has it already and if it did allow it, this could cause serious issues for game engine when it might run double instance of cloak or frankly just crash if you went deploy cloakinf and also had AE cloak enabled.

To avoid all that would demand coding more exceptions to disable the other when other exists and so on.

I don't think this is gonna get changed...

That would be a shame if it isn't changed, it would make the stealth stop and deploy tags far more useful, for me at least. According to Ares documentation stealth generators work still though.

I'm sure AlexB will confirm weather theres a possibility or not.

AlexB · Commander **Joined**: 31 May 2010 **Location**: Germany

Alas, the documentation is not as clear as it should be. Passive cloaking from Stealth Generators will cloak the unit regardless of this tag, but active cloaking ability, like Cloakable=yes and cloak veterancy bonus, will make the unit uncloak if undeployed. AE gives active cloaking ability.

Quote:

Infantry can be made cloakable only when deployed. When undeployed, the infantry will decloak again. This only applies to Cloakable=yes or the CLOAK ability. Cloak Generators will cloak the infantry even if not deployed.

One can now argue what part of the documentation is wrong. It does not cover all cases. If sentence 3 is wrong (and it's not "only" these examples but all active cloaking mechanisms), all other sentences still hold. And it would be consistent with AE which says that "the unit gains cloaking ability".

I would have posted this about three hours earlier, but PPM didn't like to accept this.

edit: grammar

_________________

Millennium · Posted: Wed Oct 29, 2014 9:38 am Post subject:

Curious though, I've never even gotten the CloakStop function to work at all. But every time I used it, I combined it with VeteranAbility CLOAK. Could it be that this is a similar issue and it somehow prevents CloakStop from working?

_________________

AlexB · Commander **Joined**: 31 May 2010 **Location**: Germany

CLOAK ability indeed overrides CloakStop. If the ability is in effect, CloakStop is not respected.

_________________

Millennium · Posted: Fri Oct 31, 2014 3:14 pm Post subject:

That makes sense.
But for rookie units (which do not have CLOAK in effect yet), CloakStop doesn't seem to work either if CLOAK is a VeteranAbility, but maybe I'm doing something else wrong. The only two times I've tried using this setting was kind of like this:

[HUNT]
CloakStop=yes
VeteranAbilities=CLOAK
Primary=HuntressGun
ElitePrimary=HuntressGunE

[HuntressGunE]
DecloakToFire=no

So she's cloaked when standing still while rookie, cloaked while standing or moving when veteran, and always cloaked when elite. CloakStop on Rookie did not work.

_________________

AlexB · Commander **Joined**: 31 May 2010 **Location**: Germany

CloakStop=yes needs Cloakable=yes on [HUNT].

_________________

Millennium · Posted: Sat Nov 01, 2014 2:30 am Post subject:

Oh, my.
If CloakStop overrides Cloakable=yes, then Veteran CLOAK wouldn't override CloakStop either, right?

_________________

AlexB · Commander **Joined**: 31 May 2010 **Location**: Germany

A unit may cloak if it is cloakable or collected a cloak crate. If CloakStop=yes, the unit is forced to be uncloakable if it is moving. But: If the unit gained cloak by veterancy, is always cloakable.

Other way around:
CLOAK veterancy bonus in effect? Yes: Cloak. No: go on.
Is unit Cloakable=yes or collected cloak crate? No: No cloak. Yes: go on.
Is CloakStop=no or standing still? Yes: Cloak. No: No cloak.

This is simplified and ignores cloak gens and all the other tags Ares added. CloakStop=yes essentially specializes Cloakable=yes to prevent moving units from cloaking. CloakStop=yes does not per se allow a unit to cloak.

_________________

dodgevipergts · Chem Warrior **Joined**: 31 Jan 2011

Late reply. Theres no chance of it being changed then? Oh well thanks for responding anyway. Makes the cloakstop and cloakdeploy tags completely useless to me atleast though.

AlexB · Commander **Joined**: 31 May 2010 **Location**: Germany

I have to make decisions at times for hese kind of things. Otherwise I'd had o add two tags, one that takes precedence and one that does not. And most likely I'd still miss the case when anyone maybe wants a unit to not cloak on the move, but also not if it is deployed.

If more consider this an error though, I'll revisit this feature and change it. (Not sure how atm, because I have to see how i can distinguish these two kinds of cloak.) Otherwise, I'll change the third sentence in the documentation to include all means of active cloak.

_________________