alre

I am no historian, sorry about that. Anyway, I subscribe fully the idea of soldiers building rams and siege towers, and I would rather not introduce engineers, that look like unnecessary micro to me. If a soldier can build a house, he can also build a ram. I think a lot of ancient soldiers (like nowadays soldiers) were able to handle many different weapons, maybe both on horseback and on foot, and used what they had to, depending on what was required of them, and what was their favourite tool. Ideally, a lot of soldiers in any civ quiver should be able to choose from various different equipments, and change it on many occasions, mount a horse or go on foot, ecc. In practice, RTS generally make it a whole lot simpler, for gameplay reasons. A rhodian slinger-hoplite would have to choose between shooting and charging, while simple division between slingers and hoplites avoids the problem. In general, though, I'd love to see swordmen, like roman legionaries, throw javelins before charging. I don't think that would affect gameplay too much.

This idea feels a little bit complicate, but there is something I like about it: Now conquering a cc is really not more difficult than just destroying it, because if you damage it enough, with a bit of micro you can save it and conquer it easily, with a massive advantage, compared to just destroying it. I don't think this is a good thing for the game, so I like the idea of enforcing a period of assimilation before the cc is useful to the conquerer.

In some AoE, when a player starts building a wonder, everyone gets to know it, and where is being built. This makes wonders feel a lot more special, and adds a unique variation in gameplay. I always wondered why is 0 ad different in this.

A second proposal: - units can build rams and siege towers on any (even enemy?) terrain, like buildings. - to be able to build a ram/s.t. you may be requested to have completed some research only avaiable in third age (at the workshop? a the fort?) - units that build a ram/s.t. are instantly picked up when the ram is completed - when there is noone in the ram, it stops moving (it loses loyalty? it auto-destroys?) Now garrisoned rams are an incredible weapon, but are micro-intensive, this way they would be more realistic and overall less micro-requiring. This also resolves the contraddiction of having siege workshops in all civilizations, just for rams.

I like it. It would be even better, to me, if people could build ships on the shore like buildings, instead of having a dock building that creates them all at once.

Well I'm now on two different projects: I made a modded version of the Nile map, that changes the disposition of the players, and I think I will eventually pull-request it as an option that players can choose after picking the map. That was mostly to get familiar with random map scripting, the map I really want to create is one with mountains that don't play out as simple placeholders for obstructed land, but feel more natural and playable. A different terrain to battle on. To generate mountains, the idea I had is simple: given a portion of any shape of a raster map, sample a number for each pixel (the sampling distribution can and will affect the result), then make each pixel have elevation equal to the lowest neighbour plus the random value for that pixel. I made a proof of concept in R and these are the results (with different distribution for noise): I wonder if this simple idea alone can produce good loking mountains, but I need to tweak the distribution first. And to do that, I need to know how the heightmap affects rendering and how it affects passability. I didn't find anything about this. Also, a painter that makes any impassable terrain evident by applying a rocky texture on it, would be terribly useful, I didn't find that either.

Hello, I am trying to mod random maps, and I was wondering how things are going with new mountain painters? I have an idea for generating playable (partially passable) mountains, it's simple and works fine, but maybe you already have more advanced solutions. I for sure would need some directions. @FeXoR@smiley

and can you change that height locally?

I can't see how would that serve simplicity, to be honest. It's a fairly arbitrary choice for a subset of all units. Another possibility, that I'm advocating, would be all melee units, and to me that seems simpler.

Do I really have to repeat this? I opened this thread to make this exact point, it's nothing about resources and balance, it's about game experience and realism. Camels have weaknesses, I agree, I never said they are unbalanced, I just said they are part of a notorious combo... everybody knows that. Anyway, noone deploys swordmen to counter pikes. Apart from anti-siege missions, melee units are generally regarded just as target dummys, and that's where pikemen excel.

Yet, it doesn't make any real sense. After so much talk, I hope it's clear: it's a distortion of the game to have swordsmen dealing much more damage to rams and siege machines in general, than spearmen or pikemen. About the difference between spearmen and pikemen: since in the game only ranged units are really effective in inflicting damage, I'm convinced that civilizations that use pikemen have a notable advantage against those who can only use spearmen instead, because they both deal terribly low damage, but pikemen are more resistant and so they make better fodder units, wich is their only good use. Ptolemais notorious pike-camel combo is the perfect example of this.

interestinglog.html mainlog.html

vs2017.rar

THE PROBLEM HAS BEEN SOLVED the following files were uploaded during irc troubleshooting.

still nothing changes

For some reason I can't log in on svn (it says I'm being rate-limited), but I'm following a discussion there and I need a clarification: there is a difference in the game between spearmen and pikemen? I thought they were synonyms. If it's not the case, which civ has wich?

Trying to pick up the point of the discussion as we left it, I'd say there is enough consent on the fact that spearmen and other melee units should have a more similar profile of damage (no piercing), spearmen should retain some bonus against cavalry (the way it is is fine to me, although @Thorfinn the Shallow Minded argued that there should be less difference, I guess there is room for balance tweaking) and that swordmen should have some kind of edge over spearmen where cavalry is not involved. This is only fair, considering the bonus of spears against cavalry, even if it's been argued that this difference is not as easy to catch in history, as soldiers using swords generally would have throwing weapons too, and contestual advantage depended on many subtle factors we don't even know entirely. However, unless (until?) trowing side weapons are implemented, I think we can let swordmen have a little bonus over spearmen, or just higher stats overall. Mace and axe folks can have the same treatment. I think this is the best solution for making the game more intuitive to play for everybody, it's the best compromise, until new features are introduced in the game.

I tried that already, all solutions still appear "non compatible", although I have to admit I don't really know what I'm doing and what VS solutions are altogether. Language of the screenshot is italian.

found it, but after installing I don't see any change.

I can't find that checkbox. What's precisely its name?

what's that?

I installed the required version. Don't know about the toolset though. That would be a fine patch, very much AoE-ish.

after cloning the repo, I tried running the game as that post says, and the game actually started, but just the main menu and nothing else. Following this guide instead, the VS solutions appear non compatible.

I think any of the proposed solutions here is better than the game as it is now! My proposal is just the simplest alternative I could imagine, to be fair, I like so much better the system proposed by @ChronA in the other thread. Anyway, before adding a lot of cool functionalities, we should fix what's broken. I don't care how, if the fix turns up to be another problem, we'll fix that too.

found it.