Warzone 2100 Forums

Everything else in JS API uses tile co-ordinates. Why would you want to use world coordinates for enumRange?

It's the opposite. I don't want to use them, but currently the function forces me to.

Ah, sorry, my misunderstanding. Yes, it should certainly use tiles like everything else.

JS allows placing non-VTOL weapons on VTOLs in buildDroid().

NoQ wrote:Also, range parameter in enumRange() needs to be converted to world coordinates or something like that.

Ouch. Please make a bug ticket for this, so I do not forget.

Made #3896 for four easy issues found today

NoQ wrote:Made #3896 for four easy issues found today (:

Why you think this is bug "JS allows placing non-VTOL weapons on VTOLs in buildDroid()." ?
is that wrong?

i worked with droid design code in my experiments. imo many things should be reviewed. So i think adding new restrictions to droid templates is not good.

curious how cyborgs templates will be handled in scripts...

Why you think this is bug "JS allows placing non-VTOL weapons on VTOLs in buildDroid()." ?
is that wrong?

The game runs certain checks (at least, validTemplateForFactory()) before producing stuff (good for, at least, disallowing AI cheating), so i thought this thing should be checked as well, for consistency.

Reg312 wrote:Why you think this is bug "JS allows placing non-VTOL weapons on VTOLs in buildDroid()." ?
is that wrong?

buildDroid() is meant to check if the template is valid (all components researched, for example), to aid debugging scripts so that they do not inadvertently cheat. addDroid(), on the other hand, deliberately skips such checks, so that you can add all kinds of interesting droids on the map.

Indeed, this would be fun to play with for custom campaign/challenge scripts. In particular, I would be very keen to see a Seraph Missile VTOL, even if just to play with as a curiosity.

It seems to me that supercyborgs are DROID_WEAPON. Was it intentional?

NoQ wrote:It seems to me that supercyborgs are DROID_WEAPON. Was it intentional?

I don't remember

It seems to me that droid type gives a mix of function and shape information. If you go by type, then DROID_CYBER_SUPER and DROID_CYBORG both are weapon droids. But for symmetry's sake, I've changed it so that super cyborgs are DROID_CYBORG, and that enumDroid() with DROID_CYBORG also gives you super cyborgs (but it will not give you eg repair cyborgs...).

Per wrote:I've changed it so that super cyborgs are DROID_CYBORG

Emm ... not pushed yet? Also, will it be in 3.1? Cause most of my scripts wrongly believe that super cyborgs are DROID_CYBORG.

It has been pushed. The fix would not work in 3.1, I'm afraid.

I'm still having troubles with using labels to replace my little pieces of objFromId-based code.

When label is not found, the game throws a debug message, and getObject() returns undefined, which is fine. When the label exists, but the object doesn't, it gets worse: the script crashes and doesn't proceed further.

What is the intended behaviour? Is it a good idea to make the game (on the C++ side) remove labels associated with the object when the object is destroyed? Probably it's a good idea to make getObject() return null when the label exists, while the object doesn't? If not, how should we deal with outdated labels on the script side?