s0600204

Good; and, uh, no. (4k monitor? Lucky you.) Nothing besides the `gui.scale` config option which (can't yet be set via setting page in-game and) affects the entire gui.

Okay, I've done a little patr(e)onising... @The Undying Nephalim from playing around, I can tell you have two distinct problems with the Zora civ in the structree: The first is easily solved, and is caused by a typo in your `simulation/data/civs/zora.json` file. Under the section "StartingEntities" you have River Patrol units listed twice and the second instance misspells the unit's template name. The StartingEntities entries are used primarily by the random maps to know what to give the player to begin with, but also by the structree as a starting point to working out what a civ/faction can build/train/research/etc. As to the second - and why the structree thinks that nothing can research the town and city phases - the Zora are lacking something that the other factions do not: technologies that supersede and/or require other (non-phase) technologies. And guess what the structree currently uses to work out the phases... I've written and submitted a fix for svn/A23 (found here), but that doesn't really help you on A22 (as the code's changed and been relocated in the interim). As a stop-gap measure to get it to work (at least until you move your mod to A23 and can take advantage of the above fix), you can grab a copy of `load.js` from the A22 state of the 0ad repo (here), place it the appropriate location within your mod (`./gui/structree/load.js`), and replace the `unravel_phases` function within the file with the following: This assumes you don't have any custom phases, don't have any more than three phases, and that those three phases are named the same as what's in Vanilla 0AD. And when you do move/update your mod to A23 (whenever that gets released) please don't forget to erase this file. Hope that helps.

The link in question points to a post containing an image that can also be found here on the @play0ad twitter feed, and here on Facebook. These two posts on LordGood's twitter feed are also relevant and may be of interest. And to answer your question: yes - at least in Atlas. They might not be made part of a civ's build order in-game (discussion is ongoing as to that), but they should be available for map creators to place in Atlas.

Diagnosis from afar is going to be tricky - we don't have access to your current changes to see what's what. However... WARNING: JavaScript warning: gui/structree/helper.js line 177 reference to undefined property g_ParsedData.phaseList[0] For some reason, the structree is struggling to build the list of phases for the zora civ. Without seeing your templates, it's hard to work out why, but it's possible there's a problem with how the structree is parsing tech superseding. (Also this may have already been resolved for Alpha-23, as there has been an update to that part of the code since the release of A22.) WARNING: The "Town Phase" technology is not researchable in any structure buildable by the zora civilisation, but is required by something that this civ can research, train or build!</p> WARNING: The "City Phase" technology is not researchable in any structure buildable by the zora civilisation, but is required by something that this civ can research, train or build!</p> Custom phase technologies for the zora? Might be something either isn't using them, or pointing to the phase techs of another civ. Could also be caused by a unit, structure, or technology shared between two civs, one with custom phase techs and one without. Or it may be some other reason I can't diagnose/think of currently. ERROR: JavaScript error: gui/structree/helper.js line 170 ReferenceError: techName is not defined This error is caused by a typo in the structree itself in Alpha-22, since fixed for Alpha-23. (The line in question should refer to `phaseName`, not `techName`). Even corrected, it is likely that a Warning or Error would still be issued here, as an additional consequence of the cause of the first Warning above.

Fixed. (Aristeia and Millennium AD also updated.)

>> Nescio said, >> Do you also have a location (e.g. github) where one could easily browse or view individual files of your mod? > The Undying Nephalim said, > I don't at the moment but I could set one up. If you created one (and remembered to keep it in sync with your changes) it would mean we could see the current state of code easily. Would also mean that you'd only need to zip-up your code when you wish to make a release. If you're concerned about privacy, or limiting who sees the code between releases, I believe GitLab allows you to create Private repos for free (unlike GitHub where you need a paid subscription). In addition, both GitHub and GitLab also provide a project wiki that could be useful for documenting certain things, such as faction lists. Or a table which cross-references which resources are gatherable by which faction. These wikis can be locked so they can be read, but not edited, by the public. As to resources, as mentioned a couple of time already, there are a couple of things we'd need to know that affects the faction-specific resource code: What should happen when faction "A" gives (through tribute) faction "B" a resource that faction "B" cannot ordinarily gather? (Zoras giving the Gorons Coralmold, for instance.) What should happen if faction "C" comes across a treasure that it cannot ordinarily gather? (Stalfos come across a crate of Food, for instance.) What should happen if the units of faction "D", who when killed drop a certain resource, are killed by faction "E" who cannot ordinarily gather that resource?

Your simulation/templates/template_unit_infantry_ranged.xml file needs a <ProjectileSpeed> line under the Attack/Ranged section, ie. <ProjectileSpeed>75.0</ProjectileSpeed> (The file is inherited by skirmish/units/default_infantry_ranged_b.xml which is used as a placeholder on skirmish maps until replaced by a suitable civ-specific template.)

I can't say I fully understand why, but it appears to be a conflict/problem with the file "art/skeletons/Trebuchet.xml" added to Delenda Est in commit id d34479ebc748 "Lots of Kushite stuff." This commit/file also causes errors when trying to load `fauna_shark`. In addition, the `fauna_walrus` and `fauna_elephant_asian_infant` also give errors in DE and not in vanilla, but these appear to be issues with their templates.

It appears the official (binaries) repository of OpenSUSE contains 0ad at A21, and 0ad-data at A22. There also appears to be a ticket open to move a compiled A22 version of 0ad from the "games" repository into the "official" one.

Committed: https://code.wildfiregames.com/rP20020 Thank you @stanislas69 for the patch, and apologies it took this long to review and commit it!

From the templates in-game, yes. The place where "blacksmith" is mentioned as a first-phase building for the Celtic civs is on the website (https://play0ad.com/game-info/factions/) which, although nice to read, is either out of date or wishful thinking. (At the moment there's no point in moving the blacksmith to the first phase as none of the techs can be researched until the second.) The Spartan team-bonus text found in-game as part of the "Civilisation Info" or "History" page was rewritten in May to reflect the actual implemented bonus. (As were all the descriptions of all the team bonuses found via that page. They should now all be accurate. The information about special buildings/techs, heroes, and civbonuses... not so much. We're working on it.) The only place the "Allies can train Spartiates" thing is still mentioned is in the original design documents on trac, where it serves as part of the project's history and thus is not likely to be changed. (If you happen to find it written elsewhere, do tell us so we can correct it.)

It appears I did some time ago... there's a pull request waiting that should was intended to bring the repo up to A22 compatibility. It's roughly 2 months old, and a quick 3-way ai match reveals that there's at least one problem that either I didn't catch at the time or has appeared since. I'm working today, so fixing that is either going to have to wait until tomorrow or fall to someone else to look into it. Depends on how desperate you are... Edit: Done. Ponies Ascendant should now be A22 compatible.

Well, it shouldn't cause breakages, but if it does, we'll soon know: https://trac.wildfiregames.com/changeset/19960 And thanks to @fatherbushido for the patch

Oh heck, that takes me back... I even worked on that with @FeXoR for a short period, until he assured me he could continue on his own. I seem to recall it was before the time when the team started preferring let instead of var when declaring variables... I think the patch even pre-dates elexis and leper falling out with one another... the first time... *trails off, lost in memories* *ahem* It'll need updating, but it's mildly annoying how it hasn't been finished and committed in all this time.

The tech description and tooltip attributes, as well as the aura auraDescription attribute, are currently translated, so we're not touching those at this time. Admittedly, it's true that the contents of the description attribute are not currently visible inside 0AD (the viewer will change that), and you're right, they should be checked and standardised at some point. (Also, I'd like to find out why auraDescription was named auraDescription, and not simply description. Or tooltip as that's what it's used as...) That can come later.

WARNING: Function getWallAlignment: Unknown style: egyptian (falling back to "athen") (Reproducible by playing as the Egyptians on the "Fortress" random map.) This is a failure of the random map scripts that cause them to be mod unfriendly. Currently, the only solution is to include a modified copy of the entirety of the "rmgen/wall_builder.js" file, (just to add one line) which I'd rather not do. ERROR: CCacheLoader failed to find archived or source file for: "art/textures/skins/skeletal/arrow_spec.png" There's no reference to this image in any of our files (or in the files of 0AD vanilla or Delenda Est or Millennium AD or Rise of the East/Terra Magna), so... I can't find it either. ERROR: Mismatch between model's skeleton and animation's skeleton (35 model bones != 29 animation keys) Assuming this is the Ramesside Swordsman actor... should now be fixed.

Aristeia as-is is currently A22 compatible. The changes implemented thus far as part of the redesign process have been kept separate for now, but are also A22 compatible. All that needs to happen is for the redesign changes to be marked for inclusion into the file that people download so as to run the mod "Aristeia" on their computers. This action, once taken, can be reversed, but not cleanly. All in favour? Anyone against? After that, we can discuss making a "release" of Aristeia, if you desire one.

It's possible, yes. It's just more gui. One possibility: changing the session gui to add a button that only appears when the Civic Centre is selected. Another possibility: What @vladislovbelov suggested. (There is no example. He was describing a possibility.) Requires changing the session gui to support hiding icons instead of greying them out in certain circumstances. Quite literally https://trac.wildfiregames.com/ticket/2243 https://wildfiregames.com/forum/index.php?/topic/20156-issue-with-territory-management/&do=findComment&comment=310314 So, mod support then?

(Knew I missed one.) Should now be fixed. Please update and try again.

Hello modders! After some deliberation and discussion, we are planning to (temporarily) purge all History Strings from all templates in vanilla 0AD. These can be found in the xml files in the folder simulation/templates/ between the tags <History></History>. What won't be touched: The simulation/data/civs/*.json files. (For now...) Anything else in the template xml files. The technology files. The aura files. The reason we have decided to take this action is simple: The History Strings are not currently shown or used in any capacity in game. We wish to show them in game (specifically, using D297). But, they first need to be translated. There are a couple hundred of them. Adding this many strings to transifex in one go is unfair to translators. We also have to check the strings to make sure they are okay (make sense, well spelt, grammatically accurate, historically accurate, etc). Thus, many of the strings will end up changed or removed, making much of the initial translation efforts pointless. So the plan is: Dump them, Remove them, Review them, Add them back, in batches, over a number of months (so as to not stress our lovely translators). Why are we telling you this? This is a big change. Some of the mods you maintain contain history strings. You might want to check that they are okay as, if everything goes to plan, by the next release they will be visible to your players. Also, we may be looking into changing how History Strings (and historical content in general) are stored. If you have any concerns or queries, post below. Thank you for your attention. (And it probably won't happen until next week at earliest.)

Okay, first, quick and dirty proofreading: Secondly, where would we put this? I wouldn't want to add it to the athen.json file - not really the right place for it IMHO. I'd be very wary of adding such a lot of text to the respective template file. To be honest, I've been coming to the realisation that there are some entities in this game of ours that warrant a fuller description, and heroes are some of those. We've taken important historical figures, some for whom an entire book could be written - and we're limited to expressing their life, achievements, and legacy in a few paragraphs. Hardly does any of them justice. *sigh*. Anyhow, keep going. Next draft?

Well, actually the patch fixes the structree working out in what order phase techs occur... It's because the xml only specifies elements for three unit trainers, and now that units-who-can-research and units-with-upgrades (including the pig-which-can-be-set-on-fire) are included there as well... I can't remember why I chose to limit it to three, but four is the most that would be able to fit before we'd need scrollbars on a 1024x768 screen. But yeah, ticket #3038. Would like to have another look at that once A22's out the door. (That and the max_size patch I posted to trac ages ago.) Been (slowly) working on a cleanup patch for scrolling generally, might make the implementation of #3038 easier/simpler. (c++ is not a language I'm fluent in.) But I'm getting off-topic. As requested: https://code.wildfiregames.com/D645

At a guess: when the foundation is placed, 0ad chooses a variant from each group based on their frequency, and the end result is a combination of these choices (the mesh is chosen from the first group, texture from the third, and so on). If there is no frequency defined for a variant, then that variant won't ever be chosen. When the units in-game reach the foundation and start building, 0ad switches to the specifically named "scaffold" variant in all the groups that have a variant by that name (if a given group doesn't have a variant by that name, then the output from that group doesn't change). In the unedited 6x6 foundation file wgoyc pasted above, we can see that the second group has both both an "Idle" and a "scaffold" variant. The first has the eyecandy bricks and piles of wood etc, but the latter does not. So when 0ad switches to the "scaffold" variant, all the eyecandy disappears. The edited 6x6 file works because the eyecandy is in a different group which happens to not have a variant with the name "scaffold" and so is not affected by the switch. Essentially, his suggested change based on the 2x2 actor is correct. So just make a patch based on that, and make similar changes to the 8x8 foundation actor.

@wowgetoffyourcellphone The Chinese Imperial Court depicted in your video uses the 8x8 foundation template (which is also bugged in the same way). Looking at your mod's files it appears that all the fortresses, except those built by Carthaginian, Briton or Scythian units, use 6x6. For which, the changes you suggest should work (at least they do for me). (As a further note, I notice you have copies of several foundation actor files in your mod which seem identical to those in 0ad-vanilla.) @stanislas69 Do you feel like creating a patch against 0ad to fix this? (And perhaps sort out the inconsistent indenting in the affected files at the same time?)

Most likely too late to get into A22, but this should solve your problem (I know you already have a copy of this file in your mod): diff --git a/gui/structree/load.js b/gui/structree/load.js index 1559722..a1710a4 100644 --- a/gui/structree/load.js +++ b/gui/structree/load.js @@ -212,6 +212,10 @@ function unravelPhases(techs) phaseList.splice(reqPhasePos+1, 0, myPhase); phaseList.splice(myPhasePos, 1); } + else if (reqPhasePos < 0 && myPhasePos < 0) + // If neither phase is in the list, then add them both to the end + // and hope that later iterations will relocate them if incorrect. + phaseList.push(reqPhase, myPhase); } return phaseList;