All Activity

Small comment: naming a map editing tool "Mercator" while having nothing to do with the ubiquitous Mercator projection would be like naming a financial tool "Crypto" while having nothing to do with cryptocurrency. But this leads me to a bit of an unrelated question: do you think it's possible to make spherical maps? To map a whole planet.

Having played around with Atlas and a post processor/analyzer/converter post Atlas (https://wildfiregames.com/forum/topic/169808-map-making-support-and-conversion-tool-post-atlas/?do=findComment&comment=762301 ) I thought it might be useful to add a few capabilities to Atlas without actually changing it. My initial concern was the difficulty (for my clumsy attempts of editing) to place walls with segments and turrets properly algined and without gaps. Hence, I started defining a tool that replicates the in-game way of placing walls by dragging and connecting rather than placing individual elements. For this the tool would manipulate the Atlas-generated xml-file and hand it afterwards back to atlas for further editing and final touch. Well, implementing this handover in both directions, Atlas --> tool and tool--> Atlas, certainly allows manipulating other simple things in a kind of co-editing mechanism. Important to note: ATLAS is and will remain the primary tool mastering all the map creation complexity. My tool tries to help offering a few workflows only preserving Atlas' role as the master editor. So currently the workflow can be like this: You define a maps basic parameters, game characteristics, player characteristics etc. - either in Atlas or the new tool (in this case with a handover to Atlas). Then Atlas is used to sculpt the terrain and place landscape items. The tool can read the xml file output by Atlas and visualize both in 2D plan view and in simplified 3D what has been placed where and for which player, listing all elements. If desired, a wall or palisade can be drawn like in the game and gates can be added by simple selection of a wall segment. The tool also allows placing enitites of all kinds selected from a list with little images representing what the entity looks like in game. The game's rules where entities can actually be placed are explicitly applied (e.g. no hous in the ocean or on a cliff slope). Handover back to Atlas for modification/manipulation finalizing, whatever. If finalized, it is certainly possibly to use post-Atlas tool to verify a map works Oh, and finally, I had to find a name for the tool (used to be "prep-Atlas" similar to "post-Atlas"), but then I thought I should be a bit more creative. With a probably a bit to much creativity enhancer made from grapes, I cam up with this silly story: A character in history used and improved historical maps and related all to the legendary King Atlas of Mauretania, said to have been a geographer and astronomer (potentially related/referring to the Greek mythodologic Titan Atlas). This occured many centuries later (in the 1590s) when the Flemish cartographer Gerard de Kremer (Merchant), latinized Gerardus Mercator, came up with a map collection in a book named "Atlas" referring to that King and/or Titan. Our tool also came much later than the Atlas tool and uses its maps and tries to improve a bit. Strictly speaking the name "Mercator" in this context is not at all related to the 0AD timeframe, but, hey, the game calls a roman trader rightfully "Mercator" as well) So here is the first BETA version for people willing to test: mercator-0.9.0.zip README.md CHANGELOG.md

Thanks @Asher for testing and finding this out: despite an already converted copy existed, outputting it again converted it again, i.e. it deleted the copy and made it afresh from the untouched source. (there was supposed to be a warning ("Anything you changed inside it is lost") but bueried into a longer warnign text that nobody reads (I wouldn't , so your replacements went with the old copy. The new release 1.9.2 (QUICKFIX) now will make sure: Every change made in a copy is now recorded inside the copy, so the record survives a restart. Output over a changed copy says "the converted copy is your output", lists the changes map by map, and keeps them by default (Esc keeps them too). Only "Convert again, losing them" converts again. Frankly, this developed into an unecessarily complex "slideshow" of confirmation windows and a lot of bloat text. For the time being it works, but I have to look into the logic a bit and try simplifying it.

I see I missed quite some posts from before: Indeed, equalising height was important (same reason ships would use towers), but the gangplank (epibathra) was used as early as the Siege of Motya in 398 BC. Indeed, because of the additional weight (another reason I proposed to change this tech to Raw Hides). I think only helepoleis could handle that (the one built at Rhodes was not the only one), or later towers from Imperial Rome (which could anyway spontaneously collapse, like at the Siege of Jerusalem in 70 AD). I also had helepoleis in mind when proposing champion ships and engines, since it would be a powerful siege tower unique to the Macedonians.

No, that would be far too complex - what I have in mind is more a wrapper tool that helps defining the map/game/player characteristics, then hand over to the real Atlas for terrain sculpting, but then help placing entities, particularly walls and palisades (as a start) and visualizes that in 2D and a simplified 3D map. I am trying to use the new tool with Atlas in a kind of "pair-editing" (the tool only looking at and manipulating xml, Atlas basically everything). Atlas is very powerful but appears complex to me. The new tool is an attempt trying to reduce complexity where possibly without actually taking away Atlas powerful capabilities. Confirmed: convert_again deletes the copy and regenerates it from the untouched source, wiping any replacements. Please wait for a yet another version 1.9.2 .... (also saw a lot of documentation flaws that needed fixing). (thus demonstrating why short release cycles can be dangerous even with a lot of (automated) testing.)

I added a replacements for things on a map, then I went to the convert tab, and clicked output, and it said there were fails. I then go back to the findings tab, and it undid all the replacements I put in

Like your own version of Atlas?

Undermining/countermining seems somewhat represented by direct infantry attacks on walls already (I see @Grautvornix just beat me to it). Adding it would be worth it only if tunnels/terraforming are somehow added to the game, but this doesn't seem a big priority to me, all things considered. What really needs to be added/improved first is the ladder/siege tower unloading on walls, and the fighting on top of them, without making walls even more obsolete, and that last bit is the tricky part. For starters, ladders should make units climbing them more vulnerable, and siege towers should be extremely slow, but I think none of this would be properly balanced without wall towers automatically shooting, which is something that was removed in the past already, I guess because spamming them was too OP. My view to balance all this is that walls shouldn't include wall towers, but instead wall segments should be upgradeable to towers (I use this word for both current sentry and stone towers) that shoot automatically (imagining thermals would damage engines), for a more appropriate cost. Spacing limitations between towers would of course be considered. I know it seems this adds micro, but it really doesn't: one has to build towers behind walls anyway since wall towers are useless without a garrison, which is a waste of units and micro, and this should just improve what's already automatic. In conclusion: wall towers should be removed, while walls and towers should be better integrated, with towers and gates automatically doing anti-engine fire damage (additionally having attested catapult towers is something I already proposed), with garrisoning improving all this. Posted ranged infantry on the top of walls would shoot (like now), while melee infantry would fight unloading enemy units better.

@Asher Please see the latest release 1.9.1 in the first message of this thread (the onyl functional change). There are other changes inside as I am also preparing a second tool to prepare, support, manipulate and visualize Atlas maps. The two tools post-atlas and the new one share common components hence the update of atlas-common 1.4.0 package (I actually should rename that to make clear this is not linked to the actual atlas tool in 0AD). I'll publish a first version of the new tool shortly in this part of the forum.

Instead I would like to suggest walls that can be walked on (mechanics: moving garrisoned soldiers sideways replacing the next empty slot) towards the area of attack. Then, there could also be a successful attacker moving along the wall in the same way - garrisoning a wall segment from a siege tower or a ladder (and only from those) could be possible with a certain probability.

My amateur "historians" opinion: Isn't the typical infantry attack on walls somehow representing kind of an undermining? (frankly, you may hit a stone wall for a VERY long time with a sword, a spear, or arrows, even with an axe, but without ny thing breaking ewxcept your own weapons.This is why city walls were so successful until the late middle ages, I believe.)

Perhaps it could unload them slowly. It would be cool to have battles on top of walls like in total war but that would take a lot of work.

Yes

Hi, Let me start by expressing how much I love the unit motions. The inertia aspect bring more depth to the units, and with the newly tweaked values, it's a good balance between realism and unit control ability (also micro). I especially love the turns cavalry make. that really gives the vibes of medieval cavalry going for raids. The unit animation sync needs to be handled though, so that the stop-animation syncs with units stopping, by that's a minor thing. As for the elephants. O.M.G. That thing is so fun to play. Elephants pushing and trampling units is so fun, and I wouldn't be surprised if this changes births a few elephant lovers in-game. The infantry units having different values from cavs and eles makes the most sense to me, tbh. It gives infantry agility, and tighter controls which their qudra-pedal brothers can only dream of. I'll try to recruit more testers for this and see how people feel about this in general, but I for one really love this and hope this gets pushed in the next alpha. Cheers.

A direct way down and up to replay pallas would be the best in long term. Up: In bulk and with some save rails (e.g. no games under 4 min., no special setups for test with unlimited resources). Down: In bulk, also with conditions (of players where I lack replays). The current zip way over the web interface is limited AFAIK in the number of games and the user would select these games by hand currently. What I described here was more peer to peer and easier to mod. A "share replays mod" could look like this: In the lobby one could have a new button "share replays" next to the others (host game, join game). Instead of the normal game setup one would have the normal setup chat, no game/map setup, but conditions of the games one would like to share. E.g. 4vs4, 3vs3, over 4 minutes etc.. With mod setting "incompatible" and only buddys able to join. That way RangerK and I could sync our data bases without wfg beeing involved (except of the game displayed in the lobby). Both would benefit the LocalRatings mod

Is that something worth adding to replay pallas ?

Then we should have countermining as well since there should be a way to... well... counter it.

Another option could be undermining. It was used by the more technologically advanced civilizations too. Probably easier to do than ladders (just a guy with a pickaxe).

Like this? (next release will have it) =============================================================================== == isles-r28 <- pack.zip output: C:\x\mods\isles-r28, 12 files copied mod.json: ... ---------------------------------------------------------------------------- maps/scenarios/greek_isles.xml renamed gaia/flora_tree_oak -> gaia/tree/oak (3x, r27) ---------------------------------------------------------------------------- maps/scenarios/delta.xml renamed gaia/flora_tree_oak -> gaia/tree/oak (3x, r27) ---------------------------------------------------------------------------- 2 maps: 2 changed, 0 needed nothing; ... =============================================================================== Result: no failures left - ...

Ladders are a common early siege method. It may be a good way to compensate for erm... less complex civs in case siege tower has a prominant role for others.

Aside from the Helepolis at Rhodes i'm not sure armored siege towers were that common. i think some factions could be able to uprade them to have artillery and to have rams (current model could be used for artillery siege tower since it has the firing port) Helepolis could be unique to Macedonians, a heavily armored tower with artillery (very expensive and you can only build one).

As for their use, it does seem they were used more as archer platforms at first but starting in the Hellenistic period were ocasionally use to climb walls. Ladders would be perhaps more common for climbing (although probably more difficult to animate).

Could you add dividers in the console in the convert tab please, so you can easily determine what goes with what map

post-Atlas V. 1.9.0 is now available (please refer to the top of this thread to download). Fixed interlock between post-Atlas and the game when accessing the same archives Analyze tab: Player balancing information (staritng resources per player) fixed map enlarged preview Findings tab: fixed more replacement rules now also including actors and props double click to open "fix selected" window (thanks @Asher!) a mod's templates can be replaced with the game's own. (thanks @Asher! Please let me know if you find any bugs, or if you have more ideas and suggestions

I should make an art task for more siege tower models. That way folks can post up some references. If we're going to go through the trouble of creating more siege tower models (which we should), then perhaps each civ's siege tower should look somewhat unique. I also agree to giving it to move civs. We need to make them more useful and less buggy, but that doesn't mean they can't have them yet.