Radagast.

Variation picking depending on biome/terrain texture? Sounds very useful for building a wall stretching from a desert to a glacier. The winter wall segments variation on glacier terrain texture would then be able to get automatically picked. I think currently we have random variation selection with the awesome feature that trys to maintain previous selections when promoting units (such that units keep their beard).

True, though that's suboptimal, not only due to player colour but also as the player should be allowed to choose sides (triggers already support multiple players, see e.g. Yves' multiplayer trigger map because triggers can be distinguished per player (in the trigger code, not when querying for trigger points. i.e. querying for trigger point "A" will give you all trigger points called "A" of all players.)). Good idea stan. We could have such walls if we deal with obstructions + forbidden classes. Perhaps if we create a stream small enough (less than obstruction minimum size) we might be able to build ontop of it. Or if we leave out the middle obstruction of the wall segment? (In the xml at least there is an option to define such a gap. it's used for bridges' border to not make units wall directly on the edge of the bridge.)

Yes, that sounds awesome. The allied AI taking over your units is possible. Like Sander said the cinematics should be replaced with automating ingame camera movements. Engine.CameraMoveTo(focusTarget.x, focusTarget.z);Engine.CameraFollow(entity);Using setJumpCamera makes knowing some coords superfluous, though in general it's beest to know the most important coords. Or figure them out via var cmpTargetPosition = Engine.QueryInterface(targetEntity, IID_Position);if (!cmpTargetPosition || cmpTargetPosition.IsInWorld()) return ;var targetPos = cmpTargetPosition.GetPosition2D();var x = targetPos.x;var z = targetPos.z; // note: y points up! not zjumpCameraPositions[index] = {x: Engine.CameraGetX(), z: Engine.CameraGetZ()};

ok, great stan. Then let's make those settlers move.

I figured new entities can be spawned even without the player existing when the map is loaded? Is this correct? (Then my getting-rid of AI question is obsolete.) As i see it. it means players can be added dynamically later in the game? It terms of mp, we could even make observers control those new entities. btw. what happens if owner is null? is it Gaia? s/It terms/In terms/

I need a bit of help as of how to knock out the AI. Is it possible to have two human players, one being trigger controlled? Or how else could I get rid of the AI other than overriding the AI files (not talking of UnitAI or BuildingAI here, but of bots). Also I have no idea how to load a map, i.e. play, without victory condition at all? My guess is adding an empty Victory condition in maps/scripts/ . Or should the complete campaign's map.js go in the maps/scripts/ folder? Instead of residing next to map.pmp (terrain) and map.xml (map/entities/player data).

For me moving those special entities not works even if I get them selected. I need to have at least 1 "normal" entity selected. I would prefer having the ALT key to refine a box selection. But it might well be that this is a GNOME issue.

I fear playing the campaign will be less fun if I did. TASK means WIP. There are still some technical issues to resolve.

Part I: A Gallic Day. Available soon. Part II: A Gallic Excursion. Part III: Gauls getting to know the reasons. (inside the city) Part IV: Gaul's last stand. Part V: Gaul's fate. Missing artwork for Part IV + V: Roman Hero: Caesar

It's a bit tricky as ALT wants to move the window. Thus I first have to start box selection, then press ALT and finish the box selection. This way it works for me.

Excuse my misunderstanding, Gronvik. I didn't know you not wanted to build upon 0AD or our engine but want to create a game from scratch. Though I think 0AD is not too far away from a city-building experience and could be turned into one. And if not 0AD's javascript part, then at least reuse the engine?

That's not hitting the nail. Of course they were excellent. I never doubted that. I talked about a model in terms of mathematical model. In this context, the hard counters are a fix, and a rigid + manual fix too. What you state is no different from a pure soft counter model. Adding parameters to a model obviously not suddenly means you don't have to "make it respond well to each other". In contrary it's indeed getting more complicated if you still care for the other parameters. If you don't care for them anymore, then the hard counters are a shortcut. My previous post was indeed not clear enough concerning that bit of information. I also think alpha + scythetwirler's balance branches are a good move in the right direction as seen from the changelog. Correct, less parameters imply an easier model. Though as stated in my previous post I noted "don't care for the other parameters anymore" or at least take balancing those parameters less serious, which then makes hard counters indeed the easier way. Ensembles studios clearly knew what they were doing.

You don't have to know programming, it's enough to know how to edit XML, to draw (pencil or digital) or know how to create textures or how to model 3D models. If not, it's still no problem, you can learn editing XML fast. Though a Github repository would be no bad. And personally I like transparency which fits nicely to open source. In general I think it could work if you can recruit people from other forums (those in this forum here are already pretty involved and therefore don't have enough time to really move something forward for your Caesar successor). Do you plan reusing the e.g. Roman factions currently in 0AD, i.e. Roman Republic (and later Empire)?

It's not that there is noone working on it. There is a lot of effort put into it. I think if historic_bruno weren't distracted by other issues we had, he would even have something by now (he has already tried multiple approaches and I'm confident he will some day - no matter when - fix these AI saved games).

Nevermind, we can approximate the OnRegionLeft|Enter with OnRangeLeft|Enter. The on TerritoryLeft+ Enter broadcas messages are interesting. I have to subscribe to those messages but I think it's not required for the current map.

Thank you. I figured a OnTerritoryLeft event would not be bad. Could this be a bit generalized? i.e. SOLUTION Afunction OnRegionLeft({arrayOfCoordinateArrays, isEnabled}){ // connect the coordinates as polyline // somehow check if the unit left the region (probably costly! that's why we probably better use solution // { uppermostStar, bottomLeftStar, bottomRightStar } return { unitID /*=> via unitID we can get the current pos3D*/, pos3D_intersectionMovementRegionBorder, pos3D_directionOfClosestRegion }; * /| / | ..*..*..... .' '.. | region | |_______| }Or if there is a way to have territory without buildings then OnTerritoryLeft(playerID, isEnabled) would be enough. Edit: I figured returning the unitID is enough as when the OnRegionLeft event is triggered then the current unit position is exactly all three stars' positions at once! SOLUTION B Instead of an event, we use an interval trigger, where we check all registered regions' unit lists. Finally we'll have #regions + 1 arrays to that in union contain all units (the +1 because that's the list where the units are assigned that are no longer in any of the registered regions). When setting up the interval a callback function should be given that determines what happens: OnRegionLeft, OnRegionEntered. The difference to solution A is that we not have to examine unit positions on every move command. Though this solution B might even be more expensive in terms of performance than if we check if the move command's target position is outside of the region that contained the unit + if it's also in a new region.// ... (interval trigger, see above) // The callbacks:function regionLeft(data = { unit_id, region_id }){ // do something}function regionEntered(data = { unit_id, region_id }){ // do something different} This functionality is pretty important for me. OnRangeLeft and OneRangeEntered is not enough as Range is only a range and not an arbitrary polygon.

Trigger points can't be moved directly it seems. Though removing and readding could work as alternative? trigger points define an owner, there note that not the player territory where the trigger is placed is the owner but each player can have its own triggers. General (non-player specific) triggers are assigned Gaia? Other than that nice work, the trigger points even graphically show the correct letter. Is it possible to have more than seven trigger points? Can I simply create a new template for a trigger point? It seems I have to create a mod for it if I wanted more trigger points.

Depends on the model. In general we try to model the real world history. If we realize we can't get to a realistic result (i.e. a cavalry flanking manoevre et alia) then we decide to go the easy way and simply create a hard counter for cavalry vs. infantry. (this parameter also has to be tuned to make it balanced but it might be easier than tweaking plenty of variables) We try to tweak plenty of variables (dexterity/stamina, morale, speed, armor stats, attack, strength, attack range, vision, attack frequency, health points, ...) as long as we can still hope to get to a realistic result this way, not needing to introduce hard counters in the model (a shortcut, rigid + but also a complification and a somewhat static + manual solution). * the last paratheses target the hard counters.

When running in a terminal: pyrogenesis -editorI sometimes terminate the program via CTRL+C. Though it's not working for Atlas. It's no real problem and very low priority but I thought perhaps I'm missing something and it's my fault at the end. Running LTS12.04 .

Oh, didn't know you added it to Atlas. Now that I have an Atlas running, I will check it out. It's no problem if programming triggers has knocked all the chruch mice out of your church shieldwolf. Programming is not the easiest thing to learn. (it first and foremost takes time) A trigger point has coordinates right? Will check the examples ...

The hard counter system isn't bad, it's the easy way. It's a fix for a balance failure. It's also the quicker solution as you pointed out. It's somewhat a shortcut and overriding the soft counters (so that imbalance there doesn't matter anymore). We'll see if we have to use that fix at one or the other point. It's quite probable, but I would also like to see how far we can go without needing that fix.

I guess the problem will be how to insert trigger points in the map xml? And how to later reference them in the map.js ?

True, the goal is to determine the size on the fly (this may also be used to check if it was downloaded correctly, e.g. if only 54KB are shown, but the mod is 700MB big, then this may indicate us that the user should redownload the mod). 0ad is the unique name. We had to separate it because the user might have the great idea to rename a modfolder (what we can't prevent). That's why we had to define the unique ID as the mod.name in the mod.json. Leper noted in the Code that it may best be renamed to 0ad instead of public. We can't really decide it currently I think and better wait. The problem with naming unique mod ID public is that then people would no longer recognize it as they only know the game's name 0ad and would wonder what that public thingy was. That's my fault, I had some issues with my progs as I use spaces only for all other projects but 0AD. Now I've settled on smart tabs, i.e. only the beginning of the line will be turned into a tab. Should be fixed in the next commit.

((I wonder how they created those clothes as those have to work with the unit mesh's animations? In the end they really created a new mesh for each unit type oo )) Those feathers + medaillons we could indeed add as props, at least as variations. Though currently the art department is busy with the Seleucids. And with Art department we talk about two people.. oh no it's even three currently.

Now mods simply have to define a mod.json file in the highest mod folder (e.g. mods/myMod/mod.json). Thanks to leper for this uni- and simplification. leper has now completed the engine side. The GUI still lacks: - A working scrollbox for the description row. - The preview images on hovering a mod row. - Execute topological sort button (+ test topological sorting really arranges mod dependencies prior to the corresponding enabled mod). btw. Philip yet again improved performance by 15%. In combination with the next spidermonkey ES31 I think we could even have a not so laggy release soon. :-) There are so many other improvements by the prog + art teams that I can hardly wait for the next release ... Edit: For mod.json examples see the Aristeia, Millennium or Rise of The East mod. https://github.com/0ADMods/China/ https://github.com/0ADMods/Aristeia/ https://github.com/0ADMods/millenniumad/