wowgetoffyourcellphone

Maybe? Perhaps that's what's missing. Where does it go? Health?

A turreted unit on a wall just ungarrisons when the wall is destroyed. I personally think they should die. Depends what others want I guess.

Somewhat true, but it also depends on the rig.

lol, depends. The poly count for the soldiers and props would be reduced by half and you'd probably not have many battalions, maybe 10. lol. Anyway, hypothetical is hypothetical.

The only problem with that patch as-is, is that the catapult doesn't die when the ship does. lol IMHO, turreted units should die when the turret dies. That includes walls and any other structure we might add it to (fortress for example).

Yeah, the building "details" are scaled to fit. Yeah, if you're reducing unit sizes by 50-75%, then you'd for sure need battalions. And not just 18-24 units per battalion like my proposal. 64+

So, yes, this is nice. Heavy Warships can come with catapults already turreted. In my suggestion, these would be smaller than normal catapults to fit on "bireme" sized Quinqeremes. Garrisoning troops onboard can still add to arrow count if we want.

There never can be consensus on anything. lol If anything, I'd go the opposite route and forget about "units on the deck" and turretable stuff (unless the ships comes automatically with a turreted catapult or it's some kind of upgrade). Manually placing stuff on the decks would be a pain for anything more than a half-dozen ships. If you just want small squadrons of ships for your naval combat, then I guess that's fine, but you still have the huge problem of the scale of the current ships. I think the engine should allow for manually turretable things, but the core game should streamline the ship combat and shrink the ships to around the current "bireme" size.

Right, but their units are making mincemeat of your meat shield. And now since your meatshield is dead, their meatshield can walk right up and kill your archers.

When you select a group of units, the UI chooses a "primary" unit to determine a few things, such as sounds. I think the primary unit in a selection is determined by "Entity uid". While this isn't ideal to say the least (IMHO, it should go by preferred class, so Hero->Champion->etc.), it's probably efficient. Unfortunately, in this case if the unit with a lowest uid in the selection doesn't have acknowledgement sounds then you won't hear anything.

Question. Why would the player want their archers to ignore the enemy's meat shield? Whoever wins the meat shield fight usually wins the battle. It's something I've been meaning to ask.

This one here is my biggest peeve. Any hero or unit with a training limit reached turns the queue off. Ideally, the queue should only queue up 1 instance of the hero, similar to techs.

Thank you for parsing the issue. This is the solution I went with and it fixed the issue! @anony5496 This will be fixed in the next release.

The Seleucid idea sounds like something out of a single-player campaign.

Not a bad reference. The iron parts could be different colors/metals.

No, only wood and stone.

Here's the section function placePlayersNomad(playerClass, constraints) { if (!isNomad()) return undefined; g_Map.log("Placing nomad starting units"); let distance = scaleByMapSize(60, 240); let constraint = new StaticConstraint(constraints); let numPlayers = getNumPlayers(); let playerIDs = shuffleArray(sortAllPlayers()); let playerPosition = []; for (let i = 0; i < numPlayers; ++i) { let objects = getStartingEntities(playerIDs[i]).filter(ents => ents.Template.startsWith("units/")).map( ents => new SimpleObject(ents.Template, ents.Count || 1, ents.Count || 1, 1, 3)); // Add treasure if too few resources for a civic center let ccCost = Engine.GetTemplate("structures/" + getCivCode(playerIDs[i]) + "/civil_centre").Cost.Resources; for (let resourceType in ccCost) { let treasureTemplate = g_NomadTreasureTemplates[resourceType]; let count = Math.max(0, Math.ceil( (ccCost[resourceType] - (g_MapSettings.StartingResources || 0)) / Engine.GetTemplate(treasureTemplate).Treasure.Resources[resourceType])); objects.push(new SimpleObject(treasureTemplate, count, count, 3, 5)); } // Try place these entities at a random location let group = new SimpleGroup(objects, true, playerClass); let success = false; for (let distanceFactor of [1, 1/2, 1/4, 0]) if (createObjectGroups(group, playerIDs[i], new AndConstraint([constraint, avoidClasses(playerClass, distance * distanceFactor)]), 1, 200, false).length) { success = true; playerPosition[i] = group.centerPosition; break; } if (!success) throw new Error("Could not place starting units for player " + playerIDs[i] + "!"); } return [playerIDs, playerPosition]; } Here is the line (471): let treasureTemplate = g_NomadTreasureTemplates[resourceType]; I tried bypassing treasure generation by setting the starting resources to 1000, but then I got an error for line 475: ERROR: JavaScript error: maps/random/rmgen-common/player.js line 475 Script value conversion check failed: v.isString() || v.isNumber() || v.isBoolean() (got type undefined) placePlayersNomad@maps/random/rmgen-common/player.js:475:12 @maps/random/mainland.js:192:18 ERROR: CMapGeneratorWorker::Run: Failed to load RMS 'maps/random/mainland.js' Line 475: Engine.GetTemplate(treasureTemplate).Treasure.Resources[resourceType])); Could the "problem" be that Delenda Est's treasures give more than 1 resource? A few months ago @Freagarach made it possible in the core game, so I ran with it. This could be an edge case not tested for?

Looks like it's getting hung up on the treasure generation for some reason.

Do you know which files deal with the nomad mode? @Freagarach @Stan`

You just quoted my opinion.

https://trac.wildfiregames.com/attachment/ticket/571/atlas_minimap.jpg Revisiting. It would be very nice to have a minimap for Atlas for Alpha 27. Especially with the new minimap icons implemented, it would be supremely useful. @trompetin17 Along with @Langbart's new minimap.

The problem with the bribe mechanic is that it was implemented and then boom, no one worked on making it more interesting. There were some minor tweaks, sure. But any further design work on the feature died due to disagreements. For instance, I'd expand it to include all support and citizen soldier units and then give it some kind of cool down time between bribes, or make the cost of bribing increase exponentially while there are active spies, but the cost settles back down once all spies are expired. But consensus wasn't reached so now the feature sits unused and unimportant.

Maybe because nomad mode places female_citizens, when DE doesn't have female_citizens?

All civs now get a battering ram, and I think it would be good for the base game to have a simple "handheld" battering ram for some civs. Or perhaps all civs get this handheld version in Phase II, with a "Covered Ram" upgrade in Phase III for some civs. The Norse "Portable Ram" in Age of Mythology: Something like that, but with 4 dudes. Delenda Est has one from Millennium AD, but the ram log looks way too big and the way they hold it doesn't look right. The log doesn't seem to have weight, while the Norse one does.

Need one for the Han Chinese as well.