Deiz

Ah, nice catch. I'd forgotten about rally points also storing template names.

Yeah, the rule of thumb is that saves presently have virtually zero forwards-compatibility. As the game progresses to a finished state, the data structure will probably stabilize, and there'll be backwards-compatibility for at least a few releases, I imagine. For now, though, save compatibility is broken tens of times in between each alpha release.

Your patch is a little crufty, you ought to add -x --ignore-eol-style to svn diff. Style-wise you've got some K&R indenting in GetNeededRequirements, as well as a few tabs that are spaces rather than actual tab characters. As far as the content goes: I don't really like doing string replacement, because it means requirement tooltips will be inconsistent, much like the unit tooltips are (with some showing attack bonuses, others showing nothing besides a brief description, etc.). That said, the only way I can think of to avoid string replacement would be to have a look-up table in TechnologyManager, something like this: var tooltipClases = { "Village": "Village Phase structures (except Palisades and Farm Fields)" }; While the function that constructs the tooltip for a class-based numeric requirement would do something like: // reqs.numberLeft is your patch's reqs.number, my reqs.number is the untouched, absolute requirement. var tooltip = "Requires " + reqs.numberLeft + " more " + tooltipClasses[reqs.class] + " (Needs " + reqs.number + " in total)"; return tooltip; However, perhaps your approach is sufficient for now. There aren't very many technologies at present, and they have simplistic requirements.

Seems like the article gets quite a bit of traffic, about a quarter as much as the list itself. I suspect a good bit of the article's visits come from the list; it's not linked to from very many other places.

I would sooner implement game modes with laxer victory conditions, such as destroying all of the enemy's civic centres, rather than annihilating every single unit and unit-producing building.

Yes. All the GUI panels clamp to a predefined maximum number of icons. Quite a few of the limits can be reached if you really work at it, e.g. selecting all the Carthaginian unit-producing structures will hit the training panel's limit of 24, and if you select many types of units and buildings you can easily exceed the selection panel's limit of 16.

I went ahead and made my proposed change (12 garrison icons plus always-present stance bar). Most of the diverse civilizations have more than 12 kinds of ship-garrisonable units: 2-3 infantry, female citizen, 1-2 cavalry, 1-2 champions, 1-3 siege units, 1-3 heroes, healers, traders. Puts the lower bound somewhere around ten, I think that's about accurate for Spartans. Carthaginians probably sit somewhere around ~20 due to their special embassies.

This is a flaw common to all entities that can garrison units. I'd personally prefer to reduce the maximum displayed garrisoned units to 12 (from 16) and show the stance bar at the bottom. Having over a dozen different kinds of units garrisoned, even across all of your garrisonable entities, is pretty much the definition of 'edge case'. I suspect several civilizations don't even have 12 different kinds of garrisonable units.

Foundations also count towards buildings destroyed. Perhaps only committed foundations should count towards those statistics (occurs when the foundation is first reached by a builder, at which point the foundation starts obstructing units and such). Foundations are pseudo-templates that are created by CCmpTemplateManager::CopyFoundationSubset. They only have a small number of explicitly white-listed components (Minimap is notably absent). That particular function actually pre-dates the (current?) minimap implementation, so perhaps it's just an oversight. Edit: I'm wrong on the former, actually. The buildings destroyed counter excluded foundations.

Ah, I'd missed that. Fixed.

I think the training behaviour is desirable, as it mirrors the command implementation. The training command is sent to each entity individually, so if you have 3 fortresses selected and are trying to train a batch that requires 500 metal while you have 1400 metal in total, one of the fortresses will fail to queue the batch, but the other two will succeed. Buttons are supposed to be disabled when the red overlay is present. Can you tell me how to reproduce that issue? I can presently manage to do it because the overlay display is calculated at render-time, so if I click more than once per rendered frame, I can end up attempting to queue more than I have resources for. I was thinking that right click should probably decrement the batch size by five, much as left click increments it by five. That'd at least allow you to correct mistakes (whether your batch is about to fail or you just didn't want that many units).

Did a brief accelerated test with qBot, didn't see any issues (30 minutes, game time). Seems promising, but I can't confirm it's gone until I've played a longer game.

It's decidedly much easier for that to happen with wood walls because of their tiny obstructions. Infantry obstructions are 1.6m square, palisade towers are 4m square. Seems like you'd be able to get 16 builders around a tower. The palisade wall segments are only 2m thick, but builders can only reach 2m from their midpoint. Which is to say, they can reach 2m - 0.8m = 1.2m from the edge of their own obstructions, best-case. Because of the shortness of all the palisade wall segments, the towers often cover up quite a bit of them. So, you might have a 14m palisade wall segment, but worst-case up to 8m of that can be made unbuildable, so builders would be trying to cram themselves into a 6m strip on each side. When rebuilding a destroyed long segment you could get stuck indefinitely with as few as 6 builders. Perhaps it'd be good to bump up their obstruction depth to 3m so that builders can (almost) always build them, even in areas where they're overlapping a wall tower.

Can't definitively say whether r12507 fixed the aforementioned UV issue, but I played an hour-long match last night with no graphical glitches. There seem to be quite a few people that play SVN builds regularly, so I suspect no further reports of graphical weirdness means the issue's gone. Edit: Well, so much for that theory. At present I've actually got it occurring at all zoom levels. It flickers through various textures (the two glitched ones are very similar): Lighter Darker Normal

I've seen that before. The workers probably aren't idle, they're trying to gather an unreachable tree or similar. I suspect that it's actually two issues. Looking around the edges of a few circular random maps, it appears that entities are sometimes created outside of the map. It might be an off-by-one, or it might be that when placing entities, only the midpoint is checked for validity. The second issue is that these misplaced entities end up being valid gather targets, which is ultimately fairly innocuous, as entities shouldn't be in the world yet outside the rendered portion of the map.

I was nervous for a moment (thinking my recent changes broke something) but this is also present in alpha 10. There must be some special case that's being hit here, because land gatherers can switch from one resource to another without issue.

default.cfg currently has preferglsl = false, so thus far I've only experienced the issue in ARB mode.

Got some graphical weirdness to report. Examples: 1, 2. I've seen it on a variety of structures (Pureon has seen it too, apparently. Can anyone else confirm?) so I don't think it's an issue with any particular model, but some of the graphics code that's presumably been touched recently. Presently running with a simple config: windowed, fancywater disabled, vsync on. It's a rather strange issue. It occurs randomly and persists for a minute or two. Oddly, the textures are mapped correctly when zoomed in, and then promptly become corrupted like the above when zooming back out. Since it's zoom-dependent, it seems to me it might be a mipmapping issue, but I'm wholly unfamiliar with the graphics and rendering code.

I assume you're using the pre-built Windows binary. If so, this isn't a bug; r12486 requires an engine rebuild and the autobuilder is presently broken, so somebody needs to do the build manually.

I very much suspect this is a generic pathfinding issue that isn't dependent on any particular order. When I was working on gates, I'd often use the Romans sandbox as a testbed, and it was quite common for builders to wander off in odd directions after finishing a wall segment, mostly inside the FORMATION.WALKING order.

It's a case of being 'good enough', I think. There isn't much more that can reasonably be done, unless you consider getting licensing grants signed and notarized for every third-party piece of art to be reasonable. The worst-case, I suspect, is needing to pull the affected releases and put in a placeholder. I've seen it happen to a few projects that inadvertently included non-free material, and it wasn't terribly painful.

Having mucked around with 'z' quite a bit, I believe the GUI only attempts to blend objects that have rather similar z values. Which is to say, a translucent tooltip with very high z drawn over top of the main UI will make a 'hole' in the UI.

Are you sure you're remembering correctly? What you're describing sounds a lot like formation behaviour, however female citizens can never be members of formations. Formations are implemented as pseudo-entities which all formation members target and attempt to move with. They're destroyed as soon as the formation is disbanded, and the engine intentionally doesn't re-use entity IDs. A formation will be formed any time you have multiple formation-capable entities selected. For example, if you move two soldiers they form a formation and each target it. Say its ID is 1000, when they reach their destination it will disband. If you then give them a new move order, they will be in a formation with ID 1001, and so on.

I beat you to the punch and did the former in r12257. quantumstate is aware that qBot doesn't do anything with the worker elephant at the moment, and said he'll fix it when he has time.

I committed an update for wall building yesterday. In order for the engine to intelligently allow collisions between walls and wall towers (like GUI wall placement does) I had to introduce a new XML element, which went into all wall towers. The engine just needs to be rebuilt to recognize the new element. I'll prod k776 in case you're relying on the Windows autobuild. As a reference, r12259 is where the new element, <ControlPersist>, was added to the relevant templates. If you remove those elements you'll be able to run with an older build of the engine.