"generic" damage

[sdw195]

3. Added "generic" damage type

whats the syntax to use generic damage in

Code: Select all

(shpDamageArmor gplayership 0 0 20)

i tried using

Code: Select all

(shpDamageArmor gplayership 0 16 20)

it returned true but did not damage the armor
yet when i use

Code: Select all

(shpDamageArmor gplayership 0 15 20)

it does damage the armor

[Arisaya]

did you try negative 1?

[george moromisato]

It is indeed -1.

In the future (maybe someone can write a ticket) those functions should take a string value:

'laser
'particle
...
'generic

[alterecco]

It is indeed -1.

In the future (maybe someone can write a ticket) those functions should take a string value:

'laser
'particle
...
'generic

I have updated the wiki with this info.

Regarding the functions. Could we not just have a set of functions for converting between the integer and text representations? A'la (intToDamageType ..) and (damageTypeToInt ..)

Perhaps that is the wrong perspective, but it seems to me it is wrong to be able to input integers and strings on one side, and only get integers out on the other... the interface would benefit from being consistent in this case

[george moromisato]

I would like to eventually deprecate all uses of magic numbers. I think strings will be much more robust (and the performance cost is minimal).

It is hard to deprecate functions that return a magic number. We would have to replace them with a new function.

But it is pretty easy to have a function accept both ints and string.

[alterecco]

Hmm, right... it would be nice to move away from magic numbers. Adding new functions to work with strings, and deprecating the current ones is a solution, but eventually the api becomes really muddled (imo).

How about introducing backwards breaking changes in the 2.0 release? Is that even something you would consider? You could potentially clean up some of the inconsistencies with sta/shp/obj functions, and perhaps also the arm* functions.

[digdug]

what if the current functions could accept both magic numbers and strings ? They would remain backward compatible.
In the future, when eventually more strings will be added, the numbers could be removed from the functions.

[Star Weaver]

what if the current functions could accept both magic numbers and strings ? They would remain backward compatible.
In the future, when eventually more strings will be added, the numbers could be removed from the functions.

...

But it is pretty easy to have a function accept both ints and string.

I think the problem was not being able to return both a string and an int from the same function.

[george moromisato]

How about introducing backwards breaking changes in the 2.0 release? Is that even something you would consider? You could potentially clean up some of the inconsistencies with sta/shp/obj functions, and perhaps also the arm* functions.

That's definitely an option. Since Extensions have a version number we could use that to determine whether to use the 1.0 behavior or the 2.0 behavior.

[alterecco]

That's definitely an option. Since Extensions have a version number we could use that to determine whether to use the 1.0 behavior or the 2.0 behavior.

I like that idea! Would you like that we started a topic related to this deprecation? Perhaps we should wait and do it later on?