elexis

Really?

Those things are hard to guess. I'm glad you figured it out and we devs can recall that ext time someone runs into file permission issues.

Are directory permission issues actually ruled out?

As far as I see most if not all templates (including intermediaries) are already copied to Delenda Est. So the DE speed values aren't affected after all, no? Attached the unit_summary_table.html for delenda est and svn (after adding the "glory" resource to unitTables.py) showing that the intermediary template speed values didn't actually change in DE. So might not be that big of a deal, as the non-intermediary templates should therefore also have the same numbers. We 0ad devs often rewrite the entire thing from top to bottom to ease future changes and improve maintenance. But since DE doesn't change much of code but more templates, we can remember that for the stakeholder analysis for future template patches. unit_summary_table.zip

That problem sounds unrelated to the original post. The mainlog says there was an error on survival of the fittest. I suspect the map was played with a mod that adds a civ, templates or something. The freeze most likely comes from the fact that there will spawn 300 gaia units for each player if they somehow managed to survive that long. Combined with the fact that the Footprint component is extremely slow (we got a release blocker ticket around for that).

Busy atm. A phabricator proposal or a23 trac ticket would help scheduling this.

Merging could probably be done by not rendering that part of the circle if some other entity already has a range overlay with the same identifier on that exact location. (There was some related cleanup code, but if it was only D672, then there won't be merge conflicts) (Also there's still an attack range visualization patch around iirc)

In case one isn't familiar with a name, one can lookup them up in the credits to see the associated nick / realname, or searching for the name on trac also most often reveals the date of first contribution.

The territory is most probably computed correctly in the simulation, because the minimap shows it correctly. Must be a rendering bugs. If you know that its between 19000 and 19500, try a bisect, i.e. test 19250 and so forth, shouldn't be too many steps. (But if I had to guess, perhaps it was that CUDA update you spoke about)

(Thought it was D910, but that wasn't committed.) Notice the territory is visible on the minimap, strange. Yes, try a clean compile.

Hm right, that will surely make everyone happy

Luckily we have one (the non-cheated iso view one is linked above, the camera config option thing is linked in the ticket) ;-)

Could you get away with renaming metal to Rupee and switching the icon?

What does return do?

GetResources, GetCodes and GetNames needs an optional civ argument. If that argument is given (i.e. not undefined), then they should only return the results that match the civ. (Almost?) all occurrences in gui/ of these functions (see the commit I had referenced somewhere above) should pass the the civ of the current player (g_Players[g_ViewedPlayer].Civ or something). The simulation occurrences shouldn't be touched as they need to compute for units of all civs. (Also not sure if it's something the public mod wants to support. Possibly it could, but there should be some good use case analysis and ruling out of weird things like coming past enemy trade carts that loot tons of metal, killing the units and then not getting the loot. What about sending resources to an ally? What about finding treasures that the civ ought not to support? and so forth) Not hard to do, just costs time to go through all that code, as resources are used everywhere.

If I read correctly, the complain in the callstack is not reading the file but writing the converted file (must be the cache). So check for write permissions to the cache folder, see wiki/GameDataPaths. Note the released bundle doesn't use the cache directory as all files were pre-converted (or were that only textures?)

See also http://trac.wildfiregames.com/wiki/Changelogs

"civs": {"hylian", "gerudo"}, [] instead of {}

Oh, interesting. So which resources will be shown depends on the players civ then. So the resources json files could contain an array of civs that could be queried in all the places of the GUI. Those aren't few at all. Top panel, tooltips.js, barter & trade dialog, summary screen come to my mind. You might want to look at gui/ code in 18964 to identify more and exact places (there were few follow-up commits too). Perhaps the most maintainable approach would be to to make the four getters in globalscripts/Resources.js receive a Civ argument. One would have to check whether the summary screen likes that (perhaps it the totals might be off or something).

What role is metal going to play in your mod? If the player can gather, trade or barter it, it sounds like it should be visible. I didn't follow the thread so I don't know if it's too much work to delete the metal from the templates or to create metal-free templates inheriting the existing ones. (Originally there was a way to add disabled resources, but I didn't like the fact that the resource was still present in all XML files, i.e. leftovers and resource definition still in place).

(rmgen1 remedies include SmoothElevationPainter, createBumps)

(Might be a bit early, but I'd love to have this proposal on our schedule. So if someone writes a short ticket with component Maps and milestone Alpha 23 at https://trac.wildfiregames.com/ that might help with not forgetting this feature.)

Oh I like unconventional maps with chokepoints too (contrary to many lobby players). Using existing rmgen calls on top of your library was just an idea to improve the results of maps, not to replace your lib.

> I'll probably try disabling the hardware detection completely, but at least to me this doesn't sound like a real solution You can write a bugreport linking to this topic at https://trac.wildfiregames.com/, but as long as you're the only one affected and noone cares about the performance database, killing bugged useless code sounds perfectly fine to me.

Main Menu -> Tools & Options -> Settings (or was it called Options?). Or copying stuff from default.cfg to user.cfg at wiki/GameDataPaths if you're into that. But mostly try to disable GLSL. If that doesn't already solve it, I'd rather investigate where it crashes. It should be possible to debug pyrogenesis.exe in Visual Studio (wiki/Debugging), so that if it crashes, it would show you the line where it does. From that we can decide what it probably wants. If that site is too lengthy and if debugging over there isn't straight forward, Stan might answer which buttons to push. About numa, there is numa.h: The more relevant question is how it's used. One could check using svn blame or git blame which commits introduced these lines to find some context or check the code. I guess its only used for the performance database. It's only relevant if it has something to do with the crash, so just check the crash.