s0600204

Links to a couple of tickets that have been opened on the topic of the stdlib error: https://trac.wildfiregames.com/ticket/5152 https://trac.wildfiregames.com/ticket/5157 (Just to keep things cross-referenced, and people apprised.)

Hello! If you want to run A22 on Ubuntu 18.04, you can acquire it from Ubuntu's own package repositories. The package you're trying to install is, as the name suggests, for use with Ubuntu 17.10.

Error occurs because "obsidiana" is not a valid Type for the Minimap component. Unfortunately, to add it requires a c++ change. (Clearly we missed something whilst de-hard-coding resource types...)

May I ping you? Looks like it'll still happen in A23. Looking at gamesetup.js, the code that assigns a random civ to a player starts by making a list of available "cultures" (filtering out unplayable civs so as not to add their "culture" to the list (unless they happen to share it with a playable civ)), then randomly chooses a civ from a randomly selected culture - but does not check if the civs it's selecting from are all playable. In other words, SelectableInGameSetup needs to be checked on line 2182. So... do you want to fix it, or shall I?

Committed in r21688 (trac / phab). Thanks to all for bringing this to our attention, and your assistance in helping test the fix.

@mapkoc, the patch on phabricator has been updated, could we ask you to try it again?

Problem appears to be caused by a recent commit to the github repository. Please see the (four) comments attached to the problematic commit. (The fishing boat simply hasn't been updated yet. I believe it's on @stanislas69's todo list.)

It bugs because you have units, structures, and techs that (according to the xml and json templates) require either the town or city phase techs, but the xiongnu civ has no way of researching these. This might be intentional, in which case one solution would be to remove any and all town and city phase requirements from the units, techs and structures of the civ. An alternate solution would be to override the generic phase techs with civ-specific ones that either cost nothing and auto-research themselves, or are renamed to be more suitable for a nomadic civ. (The phases might be named "Village" -> "Town" -> "City" in the core game, but that doesn't mean they have to be so in mods. You could have them as "Traveller Band" -> "Caravan Pack" -> "Convoy" (or whatever's suitable).)

Dunno about "Static Obstruction", but the template of the "Shoushe" siege weapon was broken as a side-effect of r20804 (trac / phab). (And selecting the fortress loads that template so the "Shoushe" can be displayed as a build/train option.) Try it now.

The code doesn't know that until it tests for it. Which is what it's trying to do. Last time I saw the contents of your mod (the "v1.01 release", if my notes are accurate), you did have a copy of simulation/components/EntityLimits.js and it doesn't have the function in it. I can't remember right now why you have a copy of the file - and I don't know if you still do - but either update it or remove it. (It looks like the only differences between the version in your mod at v1.01 and the current SVN-version are the missing function, and some added lines in the Schema example.)

That would be something for @s0600204. (That language seen on that screenshot is german). *cough* D844

Got it. Try it now.

It should now. Not backport-able: you will need to update your mod to be A23-compatible to use it.

Therein lies the problem. (if you'd moved them to "structures/{civ}/*.xml" and "units/{civ}/*.xml" you wouldn't have the problem, and you'd have even fewer files in each folder.) The simplest "fix" would be to move 'em back (or into the "{structures|unit}/{civ}/*.xml" folder layout). A "code fix" wouldn't really be worth it, as A23 should be released within a month or so. Thus, any code "fix" for A22 would have to be replaced by another "fix" for A23; and would make it harder to upgrade your mod to be compatible with A23. Considering where the change would have to take place, a "code fix" would also be unpleasant.

1 - Fixed 2 - Unable to duplicate (or I'm misunderstanding you). 3 - Unable to duplicate. (In vanilla 0AD) Building a "Sentry Tower", upgrading it to "Defence Tower", then right-clicking the big entity icon: Template Viewer appears displaying stats of the "Defence Tower".

Thank you. I did say it was nowhere near complete, and clearly one of the things needed to do is check which files are actually needed and which aren't. (Did it for the gui. Mostly. Not so much for the simulation templates.) Doesn't have to be public. Github offers private repositories. (As previously mentioned in this thread.) GitLab does as well (and apparently offers them for free, unlike GitHub which requires a monthly subscription). Also, I'm not sure how GitHub handles repositories that are set to private but have "collaborators" (to use their nomenclature) who don't pay a monthly subscription. git apply {patchfile} (If you're using the command line. There should be an option in most gui abstractions of git that does the trick.) Of course, if you're going to put the project on github/lab it would be easier for me to fork and create a branch. That way you can see the changes split into discrete commits instead of all squashed into one as it is in that file.

https://trac.wildfiregames.com/wiki/Changelogs

Do you have a version for those of us who are not on Windows? (Or just a changeset perhaps.) Nowhere near complete, but as a start: hyrule_A23-squashed.patch (Could also provide it as a branch if there were some (semi-)public accessible repo...)

I can't find any variants or animations relating to crossbows in vanilla-0ad. @Alexandermb claims to have created and committed animations for infantry crossbowmen in this forum post, but there's no sign of that in the Terra Magna repository on GitHub (might not have pushed changes). There are animations for what (according to the file name) is infantry crossbow melee dating back to 2012 from @Kimball, but these (a) appear to be unused and (b) are not loadable in/by Atlas ("Didn't find any objects in the scene" / "Couldn't find object to convert" / "Could not load animation [...]" / "Failed loading, marked file as bad").

Yeah, that's a bug. Someone care to fill out an issue on trac? Please? It does not, no. Y'know, hypothetically, if the repository was on GitLab/GitHub/whatever (locked down so only a select few could see it if that's your thing) it would make things easier for those selected few to suggest fixes and improvements through pull requests. There's clearly a couple of people present who want to help with the scripting side of things. (Unless it already is, but you haven't told us...) Side-effect of the hero-choosing thing at game start. Usually, a technology that can't be researched at a building or unit, but is still a requirement for something else, is a cause for concern. This?: https://wildfiregames.com/forum/index.php?/topic/22904-how-does-the-armour-work

@stanislas69, art isn't really my forte but I've created a branch with what I hope are the required changes for Terra Magna on GitHub. Before it gets merged into master, could you check I haven't done anything stupid/missed anything, please? When you find the time. (The indenting in the actor files is all over the place. Tabs in roughly half, spaces in most of the others, with a mix of both in some files. Haven't done anything with it in the afore-mentioned branch so its clear what the pertinent changes are, but it would be nice to sort it out at some point.)

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.