s0600204

At least it was a fairly recent old release (Debian (stable) users get A17 (released Oct 2014) unless they explicitly include the backports repo...)

Congratulations. There are a couple dozen people playing online in the A21 lobby currently. Try some of the mods? Argue on the forums about game balancing? Share your secrets for success against the AI? Explore any maps you haven't played on? Up to you. And welcome to the community.

Applicable ticket: http://trac.wildfiregames.com/ticket/643 And some previous discussion on the matter: https://wildfiregames.com/forum/index.php?/topic/17461-gatherer-counts-of-limiting-and-displaying/

Yay! Okay, fair enough. If I may suggest then that you make that clear in the description of the unit in question, as otherwise players might wonder - if they've built everything they can build during the space of a game but never captured a merc camp - where the "Iphicratean Reforms" tech is. While I'm on the subject of clearly marking technology requirements in the gui, are you aware of ticket #3670? I mention it because after playing a little of your mod, I think it may impact you to a greater extent than it would core 0ad, and I'd like to get it right. Anyhow, back on topic (slightly), although the structree can be coded to work around every unit having a ProductionQueue component (but no actual entities listed within), I would think that there'd be a (admittedly tiny) performance hit in-game from such an approach. YMMV.

Okay, been looking into this. The below is based on the code currently on the HEAD of the master branch of your GitHub repo. I've assumed you've modified all the relevant requirements' to take into account the modified entity requirement. I've also only looked at the structree (for now). Anyhow: The biggest problem is that your repo's copy of the globalscripts/Templates.js file is out of date. Don't remove it, instead replace with a copy from 0AD core, as... In your new copy, replace line 370 with ret.cost[type] = template.cost && template.cost[type] ? +template.cost[type] : 0; so as to prevent errors about your glory resource not being mentioned in your techs' cost requirement Other problems that cause errors: The `athen_champion_marine` unit requires a technology (`mercenaries/athen_reforms`) that can only be researched by the `merc_camp_egyptian` structure, which cannot be built by any Athenian unit. The structree doesn't like this. The mauryan (indian) shipyard (not dock) has the ability to research the `celts/health_warship_oceanic_transports` tech. Or, it would, except that this tech requires the `celt/unlock_warships` tech which cannot be researched at or by any entity trainable/buildable by the Indians. Again, the structree doesn't like this. There are a couple of things that you do, that core doesn't, namely: Instead of putting requirements of a pair tech in the `pair_{foo}.json` file of that pair, you put them inside the techs of that pair, which is a little repetitive. You've added the production component to every unit, causing the structree to think that every unit can either train a unit or research a technology. Right. Now to have look around in-game. Edit: After playing around a bit in-game, yeah it seems like it was most likely the out-of-date globalscript file as I didn't get any error messages. That said, the structree makes a few assumptions it shouldn't, so ticket.

First draft: http://trac.wildfiregames.com/wiki/ModdingResources Try

Unless things have changed recently, the creation of wiki pages on trac is still restricted to trac admins. If one of them would like to create a page (perhaps linking to it somewhere on the "Modding Guide" page) the "scripting notes" in the readme of the original resource_agnostic mod (https://github.com/0ADMods/resource_agnostic#scripting-notes) could be used as a starting point, albeit with a few alterations (the "To Remove a Resource" instructions are wrong). I'm busy with work for the next week or so, but if no-one else has done it by then I'll look into amending the instructions to match the current implementation. But I'll need the page created first... Edit: feneur has very generously granted me the permissions on trac to create wiki pages. So unless someone beats me to it, I'll get a wiki page written and up within the next week or two.

Some time ago I wrote a patch that altered the ResourceTrickle component to allow the option of limiting the trickle rate by the percentage of territory controlled by the player. Essentially, the more territory lay within a player's territory borders, the faster the trickle rate. I'm not suggesting that a territory-limited-trickle should be added to houses, but perhaps on a CC, market or palace... It was never committed, but for those interested, it can be found on trac: http://trac.wildfiregames.com/ticket/3321 (it's the second attachment, and might need rebasing)

I've pushed a couple of commits to the repo on GitHub. As long as you're comfortable acquiring the mod from there, Aristeia should (heh) work with the current A20 release without any problems. That's alright. I'm a terrible artist. We all have things we struggle with. I don't mind doing the scripting so long as I have a clear idea of what the end result should be. The list of proposed civs for the mod, along with the current design documents, can be found here. Sometime ago I implemented the scripting side of the New Kingdom Egyptian civ as close to the design documentation as I could (at the time). All that's left to do there IMO is the art/texturing/etc. I was considering starting to implement the scripting for... uh... the Assyrians, I think... but then @Zophim (author of the design docs) posted this so I elected to wait. And that was a year ago. He does say that he encourages the research into and collection of information regarding the civs. So if there's a civ on the above list that you wish to research... go for it.

Very nice. I really like the look of the Seleucid buildings. Incidentally, d'you maybe want to remove the Macedonian props from the `death` variant in the actor file? At the moment this happens when the market is destroyed in-game: Yep, the Macedonian barracks pops in for the ride into the ground! (Appears on the death of the Seleucid barracks as well, although that's not as obvious.)

Ponies Ascendant has been updated on GitHub so that it works with the recent A20 release of 0AD. Download and enjoy!

If we treat your mod as a testing ground for "what-if"s, then, yes. Noted. Will look into it.Apologies for the delay. Fix submitted (http://trac.wildfiregames.com/ticket/3682), and committed to SVN (http://trac.wildfiregames.com/changeset/17384). Edit: Update to inform about fix having been committed.

If I may put forward my two pence: I agree with the fact the phasing doesn't "feel" right. But I'm not sure that getting rid of phasing altogether is the right move, it just needs adjusting to fit the concept of the game. I also agree with the basic idea of these: On a slightly off-topic note, one thing that's bugged me for a while is the current appearances of the civil centres. My problem is that they look (particularly the Roman one) like city-phase structures. The first (or second if you're playing Nomad and build a dock first) structure you build upon deciding to settle in a completely new area is a large, stone clad building with fancy statues? Really? IMHO it would be better to have the civic centre starting off as a tent and a couple of flags stuck in the ground, and then developing as the game goes on to a more solid, permanent looking structure. On a slightly less off-topic note, in RoN, you placed a "Small City". Building enough buildings around said "Small City", it became a "Medium City" automatically. And again, more buildings and it became a "Large City" and eventually a "Metropolis". Each stage had a visual change for that city, and increases in health, defence and the radius width in which the player could place buildings and have them count towards that City's building count. Anyhow, getting back to the point - I think that "phases" need to reflect the status of your presence on the map, rather than be actually research-able. What I might suggest is that instead of keeping them as technologies that you have to research, they become automatic upon certain limits. Let me elaborate: My basic proposal is to have something similar to RoN, and to what Wraitii suggests. A player places a Civic Centre ("CC" for short), and it is built into its initial "Village" form. Place enough buildings around it, and the ability to upgrade that CC to its next state ("Town") is unlocked. This new state has better defence, higher garrison limits, greater influence on territory borders and a larger radius in which buildings can be placed to count as belonging to that CC. Same again to upgrade to a third, "City", state. Each CC upgrades separately to all the rest on the map. So where does phasing come in? Well, when a player places their first CC, the player is automatically transitioned from the "Nomad Phase" to the "Village Phase". When any one of a player's CCs on the map is upgraded to its "Town" state, then the player is automatically transitioned to the "Town Phase". And ditto, when any one of a player's CCs upgrades to its "City" state, the player is advanced to the "City Phase". Essentially, the player's 'current' phase is that of the most advanced CC the player controls at that point. And yes, this means that if a player loses their only "City"-state CC, they revert back to the Town Phase (or Village, if they have no Towns), which makes sense as they no longer have a "City" on the map. (CCs don't revert if they lose buildings.) So phases become conceptual and representational, rather than something manually researched, whilst remaining something that can be easily checked for in requirements of techs, buildings and units. (Essentially as a quick to check to see if a player has the necessary infrastructure to support more complex structures etc). We could even go slightly further and make it so only barracks near a City-level CC can train City-phase level units, Town-phase-level structures can only be built around town- or city-level CCs, etc. Checking what phase a player is in would be used for statistics, tech requirements, and to permit towers, walls and fortresses to be built away from CCs. (I like building towers on cliff edges. If I can only build stone (town-phase) towers near town-/city-level CCs, then my defensive options are curtailed somewhat.) By having CC-upgrades manually triggered by the player (rather than automatic upon a given number of buildings like in RoN), then (a.) CCs could be cheaper, with the CC upgrades being expensive, and (b.) there could be a pair-choice that could provide bonuses to nearby units/buildings in/of that settlement (ie. wgoyc's mercantilism vs agrarianism = bonus to nearby markets/traders vs bonus to nearby farms) thus permitting settlements to specialise. Anyway, long post, sorry. Thanks for reading. Oh, and I don't necessarily agree on being able to upgrade every building. Wooden palisade outpost -> wooden defence tower -> stone defence tower, maybe. Barracks Lv 1 -> Barracks Lv 2... I'm not convinced.

A ticket was recently created on trac that proposes the creation of charts in the summary screen: http://trac.wildfiregames.com/ticket/3403 In the meantime, its been pointed out that the mod no longer works with the current development state of 0AD, so if you're running at the cutting edge of SVN and want to run the mod, here's an (unofficial) update: https://github.com/0ADMods/summary-charts (if you're still on A18, agentx's zip should work)

Noted. Will look into it.

The size of the "Footprint" is the size of the coloured box/circle around the base of a selected entity. It may have another use mind you, but... Wall piece templates (or at least the ones used in wallset_*s) all invoke the WallPiece component, which takes the form: <WallPiece> <Length>38.0</Length> </WallPiece>This is used by the wall placement code (see "simulation/helpers/Walls.js") used when a player places a wall in game.That said, I notice that the length given for the cart gate is shorter than the cart medium wall... which is evidently incorrect. Other given lengths may also be... off. While you're at it, would it be wrong if I asked if you would replace all the instances of 0*PI in the file with simply 0? And 2*PI/2 with PI? Edit: Added line about lengths possibly being wrong.

Siege weapons are capturable, and they are units. Which files are you modifying and how? And some units (like heroes, or any units in the immediate vicinity of a friendly hero) shouldn't ever surrender. Probably ties in to the concept of a morale system. This would most likely require modification of the UnitAI component. And as the 'wandering' would require use of the pathfinder, it would more likely make performance worse. Either I'm not understanding what you mean, or this would cause confusion from players ("Why have my gatherers stopped gathering and are now wandering off?") To be "skittish" means they run away when being attacked or an enemy unit gets too close (rather than standing their ground or attacking). I do sort of like this idea, although as idle gatherers tend to collect around their last drop-off point, they'd have to wander a fair distance to provide useful LOS. That said, having idle gatherers move a short distance away from said drop-site so other gatherers still gathering can get to it would help prevent congestion. Just my two pence/cents/whatever.

Oddly enough, that makes logical sense. To prevent 'resource quantity not set' errors, one of the base templates that most, if not all, the other templates inherit from will have food/wood/metal/stone costs all set to 0. So a structure that according to an in-game tooltip only requires 100 wood, will also require 0 food, 0 metal and 0 stone. I'd be tempted to suggest finding the template and changing the base values to neg inf, but that would probably cause other issues. Might be best to modify Cost.js to skip checking the current stockpiled quantity of a resource if the cost requirement for that resource is set to 0 (or less).

It works perfectly over here. Check you've modified the line correctly.

You can try it locally by changing the lines for food from "<element name='food' a:help='Food given to the player every interval'>" + "<ref name='nonNegativeDecimal'/>" +"</element>" +to "<element name='food' a:help='Food given to the player every interval'>" + "<data type='decimal'/>" +"</element>" +Be warned that there is nothing to prevent a player's resource count as marked at the top left of the screen from entering negative values. Feel free to come up with a solution to that problem. (ie. What should happen when a player runs out of food? Units start dying? Units desert to gaia? How should the game select which units should die/desert?)

slenderbro, welcome to the community. To help us to help you, could you tell us a bit more about your computer and the install setup you have. You're clearly running Windows, but may we inquire as to the version? Also, what version of 0AD are you running? You appear to have a similar (if not the same) problem to that reported here: http://trac.wildfiregames.com/ticket/3267. There, the reporter appears to have at some point transferred his entire "Users" folder to a different hard-drive (but somehow managed to keep the C:\ prefix). Is this also true in your case? Or any other possible oddities in your filesystem?

I'm sorry wgoyc, but I cannot reproduce the error. Like I said earlier, the variable mentioned in the error message is not used on that line. In fact none of the line numbers for civselect.js mentioned in the error match the actual location of the code they most likely refer to. Make sure your local copy of the mod is up-to-date. Or if you've copied the file to your own mod for some reason, please check you've copied it properly and in its entirety. Alternatively if you've modified it locally, then... well.