All Activity

Sorry that I exposed it

You were supposed to find this easter egg while actually playing on the map.

Oh! Thanks! Sorry to hear - it used to work for me so far. Will look into this tonight.would you have more details , e.g. the xml that threw this error (byPM if you wsnt)

Thanks for making this @Grautvornix! I really like the wall drawing. I was getting some errors though. Maybe this is tied to that, but the walls didn't appear in atlas /Users/me/Downloads/mercator-0.9.0/atlas_maps/model_picture.py:320: RuntimeWarning: invalid value encountered in matmul normals = piece.normals @ view.T

New tests on the latest iteration. The bouncing elephants bug is now much harder to reproduce. When trying to gather them at the same point, the issue is much less pronounced than before: However, I was able to reproduce it in the following situations: Walking around corners: I think the bouncing effect is triggered when two or more units become blocked by objects or other units of similar strength. You can see in one part of the video that a single elephant gets blocked, but nothing happens because it has enough space to bounce. Later in the video, however, more than one elephant gets blocked from all sides, and that's when the bouncing starts. Yesterday we talked a bit about adding some kind of diminishing return calculation to reduce the bouncing effect as it keeps repeating. This could be a relatively low-cost solution in terms of performance that might address the issue. Moving through narrow paths: This is perhaps the most important issue to address. At some point, they should be able to "agree" on who gets through first. Common sense tells the user to destroy the house first before trying to pass, and it's perfectly valid for a successful attack to depend on the player's ability to move their units through narrow paths or turtle bases. However, it is still noticeable that more than half of the elephants get stuck in a space they should be able to pass through relatively easily: It makes sense that they don't turn as quickly as they do in vanilla and that, as a consequence, their attacks and movement take longer to execute. After all, we're talking about a huge animal. Somewhat slower and, in a way, "clumsy" movement is to be expected. Beyond continuing to tune the elephants' physical values, I think it would be worth considering some degree of overlapping. Not as much as what currently exists in vanilla, but enough to help reduce some of the clumsiness and to emulate a slight "compression" of their bodies when they are packed together. After all, they are organic bodies with some degree of flexibility, not rigid objects like tanks. Could we also try making their hitbox oval rather than square? This might help reduce collisions between them even further. This last comment is outside the scope of this PR, but I think it's worth mentioning: This testing also made me wonder whether it's desirable for elephants to prioritize attacking nearby units over buildings. In the video example, I send the elephants to attack the fortress directly. Then I press H to make them attack freely. The elephants prioritize attacking the units, but the ones in the back can't reach them and end up bouncing around without dealing any damage. Elephants are perhaps the only "hybrid" unit in the game, in the sense that, although they are not classified as siege units, they can still destroy buildings quite effectively. Perhaps we should consider giving them a smaller target acquisition range, so that in situations like this, they choose to attack buildings instead.

One could vibe code a tool which automates that, behind replay pallas the api is public

Would not reduce the impact of Mercator to his famous projection. As I wrote, he did other things as well (producing an Atlas). Regarding spherical maps, this is specifically a question to the game mechanics, i.e. a unit leaving through one side must reappear on the opposite side. this might have quite some consequences on pathfinding.

Just used an old map from the forum for demonstration

So @MarcusAureliu#s is OP?

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 ?