mimo

More details of what you want to do and where would help: All entities including gaia ones as trees? and inside petra? If yes, you can simply do something like for (let ent of gameState.getEntities().values()) { if (!ent.position()) continue; let distSquare = API3.SquareVectorDistance(yourPosition, ent.position()); if (distSquare > yourDistance*yourDistance) continue; ... do what your need with this entity ... } You can even create your function getEntitiesAround using this loop. But note that there are a lot of such examples inside petra, with such a loop used with all kind of entity collections (if you are not interested in trees, you'd better use another much smaller collection).

I've stopped caring about it. But if you want to try, basic trade serialization of course works (otherwise we would have much more errors like that). I think it must be linked to the fact that the AI is run only every 8 turns, and if a market is destroyed between the last AI turn and the serialization, this could maybe do some errors. But as long as we have no answers on when and how the error occured, we are loosing our time.

Any problem understanding "describe exactly what you did." in order to reproduce the error? and why put 3 games in a zip file when we need only the one with the problem.

That can't be true as the error message tells it happens during serialization (so when saving a game). So can you describe exactly what you did. Or possibly you loaded the savedgame and saved it again immediately? If yes, can you upload here the saved game.

ok nice but still, the important comment i wanted to say is that most of these changes won't apply anymore when A23 is released, and a more durable solution is to do these changes in svn (either directly if not mod-specific, or add some way to ease the modding for the others). I'm not sure there will be any time difference, but i agree such early-return would be better for readability. Patch welcome!

@SirPope I'm not convinced it is a good idea to try and adapt petra to hyrule in A22. There are big chances that by the time you have something working nicely, A23 will be out and you'll have to redo big parts as there were a lot of changes in the last months. I would rather advise you to adapt Hyrule to the svn version (which is something which will have to be done anyway, so will be time well spent), and then only adapt petra to hyrule. Then your work won't be vain and you may get some help (i've no time nor interest to debug A22 problems, but would be ready to help on problems in the current version). And as leper said, patches which improve mod support can be added in the svn version.

@wowgetoffyourcellphone No, this patch is only intended to follow the naming convention of the templates currently used in the vanilla svn game, while facilitating the work for future changes. When somebody submits a patch homogenizing the current and new naming scheme (but also cleanup the inheritances of the old templates and update the Identity Classes of the new ones) between the currently used and the new templates, he will only have to change the naming in the AI accordingly.

Sure, they are fine (and the new models are really great ). That was just a warning as i see some people getting exited, with sentences like "That would be the way to do it without adding any new code".

Be aware that some (if not most) of these changes would require changes in the ai (like a prereq for cav or towers, or removing ranged or cav units from barracks), and i would not want 0ad to neglect SP games. So as long as there are not more people working on the ai, that won't work.

It could be that your svn is damaged (happen sometimes). Try removing the binaries/data/mods/public/simulation/components directory, and then svn revert.

That error is what i would expect if reading a game saved before r20276

You've just discovered an important point: people have another life than 0ad, so the time they spend on the game is limited. Nice progress! All this part just does not make any sense, and you'd better put back things in their true perspective before saying even less sensible words: - the purpose of the speed change was to ease future changes or mods, and it was a good move (imo same thing should be done for vision). If that would have caused a problem to existing mods (which was not the case), then the forum is here for discussing how to solve it. - balance change? i don't see what's wrong with them. Although i agree some of them are still premature, it doesn't hurt to already have them as the people involved would generally not work on other aspects of the game. - fixing missing brackets? that just mean that you don't understand coding, and it's usually better to not talk about what you don't know. - removing random maps? lol, and we could even push that brillant idea farther, removing all maps to remove all gameplay problems. More seriously, same argument as for balance. people are free to work on what interests them, even if not the most urgent problem of the game. And personnally, i play almost exclusively on random maps! Thus, instead of grumbling against missing core gameplay, you'd better take a good JS tutorial and learn how to program (that's how we've all started), that would be more constructive. But for me, the current weaker point of the game is not so much gameplay, but performance. That's something far from trivial and needs somebody dedicated to it during several months, which nobody does currently. Another weak point of the game is missing animations, and that's also something you could try to learn doing instead of complaining that the game won't be finished before years

Seems to be fixed with firefox 56 update!

I'm not sure the previous answer was clear enough if you are not used to the way it works So to take an example, in your gerudo barracks, you have in the ProductionQueue units/gerudo_sandsniper_b That means that all civ capturing that barracks will be able to train a gerudo_sandsniper_b To prevent that, replace it by units/{civ}_sandsniper_b (as we usually do in vanilla 0ad) so that when a civ captures that barracks, it will only be able to build its own sandsnipper if it exists ({civ} will be replaced by the name of the civ owning the barracks)

I think LimitRemovers is what you were looking for. Chek in special/player_ptol.xml how the civil centre limit is removed when a hero is produced.

In fact, there is a high chance that your bug is https://trac.wildfiregames.com/changeset/19981 and is thus already fixed in svn. Are you sure you also reproduced it in svn?

I've no idea what is done in the mod (and don't have time to try to know), but just load a few maps with vanilla game and with your mod and you will see the difference No because this new error you get has nothing to do with the previous one. Are you sure you don't have a JS syntax error when adding the warning? Otherwise, I've just tried a game between AIs with your mod and did not reproduce the error.

I don't think it is the map generation as this is much worse that in vanilla game. It should be something you do during initialization.

I've not been able to run your mod: I first selected a skirmish map, and there were a lot of errors linked to skirmish templates. So i tried a random map, and then the game froze at startup. Have you tried to run it using the zip file from your git repository? Anyway, can you add in line 312 of ai/common-api/entity.js (i.e. just before it crashes in your stack) if (!bonusClasses) warn(" Template " + this._templateName + " with Attack " + uneval(this.get("Attack")) + " has no bonus with type " + type + " bonus " + b); And copy here what is printed. That should help understand what happen.

and where is your version of the mod compatible with svn?

Yes, can you give more details: A22 or svn? only when loading your mod or also in vanilla? if only with your mod, have you added some attack Bonuses?

Yes, i think we all agree on reducing vision ranges. I had also an attempt already at https://code.wildfiregames.com/D76 But from these trials, i think that: - we should change ranges of range attack accordingly (except maybe for catapult, no units would have range exceeding vision at that time) - we may have to decrease a bit walkspeed, otherwise reducing their ranges will make ranged units more vulnerable And i now believe it would be much better to first start with a "cleanup patch" which would not change any values, but replace them all using relative templates: choose a basic Vision and RangedAttack Range (possibly different for Units and Structure, i don't know) and make all changes in the templates relative to it. Then we (or mods) can easily play with different settings and understand the changes, while currently everything is dispersed in tenth of templates files.

was fixed in https://code.wildfiregames.com/D858

yep, seems that there is a missing protection in that function when the field template does not exist. You should add if (!gameState.getTemplate(gameState.applyCiv("structures/{civ}_field")) return false; before the line let maxGatherers = ... That should be enough

Everything is possible, but that will need quite some change in the code.