Warzone 2100 Forums

I understand. The goal should be that "scripts never break".

I am just not sure how to ensure this, in general, when it is the underlying multiplayer data and rules that change.

We could trap old IDs and translate to new ones in the code, I suppose. One ID translation table might solve many such future problems, maybe.

Per wrote:I understand. The goal should be that "scripts never break".

Can you explain me what it means in warzone2100 context?

That scripts built for older versions of Warzone keep working in the future.

Unfortunately, if the scripts keep breaking due to implementation of new content. You're faced with an ultimatum, remake them from scratch, or find ways to add on to the code and hope for the best. At this point, adding on will just add on garbage, you really need to consider flagging down the master snapshot and remake the entire code to better suit the new API.

I'm sorry, but when there are too many compatibility issues, there's really no choice.

As long as there's a way to determine what version of the API you're working with (often by examination of specific functions, globals or constants) then in JS it's relatively straight forward to handle the changes in the API. Problems arise when something changes in such a way that it's very difficult for a .js script to determine whether it's in an environment before or after that change.

It's also important to note that the changes we are currently experiencing are part of a process to deal with some age old problems in terms of the WZ architecture. Due to limited time availability, it's not possible to do re-writes - it's generally better to nudge things in the right direction over several iterations. While this can be frustrating for modders affected by the changes, it has the advantage of maintaining WZ's evolution, without which devs, modders and end-users alike would probably lose interest.

Per wrote:I am just not sure how to ensure this

Well, so, ... what do you think about the proposal above? It can help quite a lot. If we eliminate dead links, our scripts will always find something with that name.

I can try making a patch this weekend; it will also probably help in nicely resolving this issue.

NoQ wrote:Well, so, ... what do you think about the proposal above? It can help quite a lot. If we eliminate dead links, our scripts will always find something with that name.

I can try making a patch this weekend; it will also probably help in nicely resolving this issue.

I am not sure it will work quite like you think. Even if you populate the internal data structures with duplicates, these duplicates won't be enabled, researched and upgraded like the originals, since only the original IDs will be targeted.

aubergine wrote:As long as there's a way to determine what version of the API you're working with (often by examination of specific functions, globals or constants) then in JS it's relatively straight forward to handle the changes in the API. Problems arise when something changes in such a way that it's very difficult for a .js script to determine whether it's in an environment before or after that change.

It's also important to note that the changes we are currently experiencing are part of a process to deal with some age old problems in terms of the WZ architecture. Due to limited time availability, it's not possible to do re-writes - it's generally better to nudge things in the right direction over several iterations. While this can be frustrating for modders affected by the changes, it has the advantage of maintaining WZ's evolution, without which devs, modders and end-users alike would probably lose interest.

IMHO it is good idea to make high level js api over current api. It will help to make small changes in low level api with out breaking old mods.

It should be object based api (like https://developers.google.com/maps/docu ... erence#Map). I has some expirience with maps, I like this api approch.

I don`t like current api. It takes too many chars to do simple things. (see high level implementation of distBetweenTwoPoints https://github.com/haoNoQ/nullbot/blob/ ... js.inc#L23) There is some other good ideas as cache. Adding standart js library will make mod development more easy and api changes more smooth.

Per wrote:I am not sure it will work quite like you think. Even if you populate the internal data structures with duplicates, these duplicates won't be enabled, researched and upgraded like the originals, since only the original IDs will be targeted.

Yeah right

I'm not quite understanding how the new cyborg body system works with cyborg engineers. What i see now is that while trying to produce cyborg engineers my AI produces walking legs without bodies and throws them into attack (believing their droidType is CYBORG). Same applies to mechanics, i guess, but im not using them.

completeResearch(...) seems to do nothing unless surrounded by hackNetOn/hackNetOff, when it causes a desync on trying to use the technology (bug or feature?)

P.S. trying to use it from rules.js.

NoQ wrote:completeResearch(...) seems to do nothing unless surrounded by hackNetOn/hackNetOff, when it causes a desync on trying to use the technology (bug or feature?)

Did you make sure it is called simultaneously on all clients?

Aha, i think i know what's wrong. I'm running it from eventStructureBuilt in rules.js (trying to make building a structure unlock technologies); it is only called for the current player.

I wonder what other events are called for the current player only when defined in rules.js.

Added new function setReticuleButton(id, tip, filename, filenameDown) that defines the look and tooltip of the reticule buttons. The filenames are the ones found in data/base/images/, with no path. Callbacks and stuff will be added later.

Added new function syncRequest(req_id, x, y, obj1, obj2) and new event eventSyncRequest(from, req_id, x, y, obj1, obj2). This unassuming pair allows you to synchronize javascript functions that would otherwise cause desync in a game, as any sync request that is generated is a tiny bit later triggered as an event simultaneously on all clients (and all scripts!). Great care must be taken to define only sync requests that can be validated against attempts at cheating. For example, if for some reason a sync request is defined that allows a player to order a unit to hold position, you must check that the request comes from the player that own this droid. Any unused parameter can be filled with null or zero; the obj parameters can be omitted.

It would have been nice to have a varargs for this function, but I saw no nice way to implement that.