Free Lua cloak isn't free

[Forboding Angel]

One thing I have been noticing with my cover gadget is that if you use engine cloak that is supposedly free, if a unit has a cloak cost defined in the unitdef, it isn't actually free.

Is this behavior intentional?

[FLOZi]

From wiki ( http://springrts.com/wiki/Lua_SyncedCtrl#Unit_LOS ):

Spring.SetUnitCloak
( number unitID,
boolean cloaked | number scriptCloak,
[ number decloakDistance | boolean decloakAbs ] ) -> nil

If the 2nd argument is a number, the value works like this:
1:=normal cloak
2:=for free cloak (cost no E)
3:=for free + no decloaking (except the unit is stunned)
4>=ultimative cloak (no ecost, no decloaking, no stunned decloak)
The decloak distance is only changed if the 3th argument is a number or a boolean.
If the boolean is false it takes the default decloak distance for that unitdef,
if the boolean is true it takes the absolute value of it.

So if you are just doing Spring.SetUnitCloak(unitID, true), then yes, that is expected and desired behaviour.

[Forboding Angel]

Ok, so basically you just told me that I've found a bug... I think.

This is what I'm using: Spring.SetUnitCloak (uID, true ,2)

This is the gadget: https://code.google.com/p/evolutionrts/ ... _cover.lua

[FLOZi]

Reread my post.

Your args are:

unitID - self explanatory
true - this is a boolean, so it is setting cloaked to true, not setting the scriptCloak number
2 - this is a number, so it is setting the decloakDistance

You may wish to read up on http://en.wikipedia.org/wiki/Function_overloading if you are not familiar with the concept, or perhaps you are just not familiar with the syntax in the wiki API (, is a new argument, | is an overloaded alternative argument).

[Forboding Angel]

Well tbh, the wiki stuff should be on one line for ppl like me who have trouble abstracting. Like this:
Spring.SetUnitCloak
( number unitID,boolean cloaked | number scriptCloak,[ number decloakDistance | boolean decloakAbs ] ) -> nil

Why all the |'s and [ ]'s tho? Meh all the above (in this post) doesn't matter, but thanks for setting me straight.

[FLOZi]

a | b means 'either argument a or argument b' (where a and b are different types)
a , b means 'first argument a then argument b'
a, means 'first argument a, then, optionally, argument b'


So:

a, b | c, [d | e]
Means; argument a, then either argument b or argument c, then, optionally, argument d or argument e.

Which you will notice is the structure of Spring.SetUnitCloak arguments.

[Forboding Angel]

Ahh, gotcha.

[smoth]

Well tbh, the wiki stuff should be on one line for ppl like me who have trouble abstracting.

. . . .

forb come on man. It is a pipe you didn't think OR reading it?

[Forboding Angel]

No, I honestly didn't. In php or is ||. I don't know all the operators used in other languages. For example, in lua, ~= means not equal to. In php it's !=.

Php is the only real "programming" language I know. I know various bits of others and even a tiny bit of c++, but not enough to immediately understand something like that. I know enough lua to be able to tinker around and make my own shit based upon others work, but I don't know enough about what I'm doing to make it worth even an honorable mention.

To me, | means separated, and || means or.

[hoijui]

in other languages, | is bitwise-or, and || is logical-or.
as for an API documentation, bitwise-or does not make sense, | is used as logical-or. you may think of the reason as: to reduce overhead.
having both , and | as separators would not make sense.

[SirMaverick]

in other languages, | is bitwise-or, and || is logical-or.
as for an API documentation, bitwise-or does not make sense, | is used as logical-or. you may think of the reason as: to reduce overhead.
having both , and | as separators would not make sense.

+1
In this context those are not bitwise operations. The API documentation uses regular expressions.

[jK]

in other languages, | is bitwise-or, and || is logical-or.
as for an API documentation, bitwise-or does not make sense, | is used as logical-or. you may think of the reason as: to reduce overhead.
having both , and | as separators would not make sense.

+1
In this context those are not bitwise operations. The API documentation uses regular expressions.

it uses a type of EBNF

[Forboding Angel]

It seems like you guys are thinking that I'm asking for it to be changed. That isnt the case. I simply needed to have it explained to me.

[smoth]

ah.

[FLOZi]

in other languages, | is bitwise-or, and || is logical-or.
as for an API documentation, bitwise-or does not make sense, | is used as logical-or. you may think of the reason as: to reduce overhead.
having both , and | as separators would not make sense.

+1
In this context those are not bitwise operations. The API documentation uses regular expressions.

it uses a type of EBNF

Oh man, flashbacks to this fine Germanic gent:





Anyway I guess there should be a brief explanation of the syntax being used in the wiki articles but I'm not sure where to put it.

[AF]

hmmm I feel we'd have been better off with something more like the way Wordpress documents its APIs ( though improvements can be made there too )

[Forboding Angel]

Yeah the wordpress codex is incredibly well done.