hyperion

@wraitii I also thought about it a bit more and while there are cases that aren't that hard to handle they all need additional data beside a type specifier. Even if implementing them one probably still wants a pass par tout boolean to bypass the compat check. checksum_compatible might be a bit of an unlucky name though, checksums are also referred to as hashes. Also a user or first time modder will ask himself what it refers to. Maybe call the boolean skip_mod_compatibility_check instead.

The most fitting ones are where you reenact historic military campaigns of the 0ad heros. But if you want to send a centurion with his man on an odyssey to go save the princess from the evil dragon that's fine as well (finally a use for the dragon ). As for difficulty, make it so it's fun for you first and foremost.

Gather rates are high compared to carry capacity, making shuttling more important in 0ad than most other games I'm aware of. If you want to reduce importance of shuttling you have to make units spend more time gathering instead of walking, not the other way around. I think it was AoE III that does away with shuttling altogether.

If you want the json formatted for a specific tool I'd say make it a mod, unless there is just one such tool or one which basically defines a standard. Otherwise the json should be what makes most sense for 0ad. That format could also be used as a replacement for the current ini-style hotkey configuration which might be desirable anyway, so you can map a user facing string to the key value pair for instance. Then a script to convert it to different tools could be added.

checksum_compatible is probably insufficient. Make it map_pack, campaign, ui, extra_civ. Not saying this list is complete or the naming or even grouping to be good. The point is there should be a tag for each case you might want to handle separately in future instead of an "ignore mod compatibility" flag. That's obvious and nothing wrong with it at all. Though giving it a cursory glance whether the modder got it right or not when approving the mod for mod.io wouldn't hurt.

I already forgotten Sepultura, but the mention and your remark made me remember one of my favourite albums 20+ years ago

Those people have forgotten that there were releases where rushing was far to strong. Then everyone cried nerf rushing. After plenty assorted changes without touching the CS concept we are now at a point were people complain about the reverse. Also unit pushing which I think is part of A25 will have a major impact on the balance of this, so any discussion based on A24 I consider pointless. Basically if balance is completely outside reason after feature freeze do a hot fix adjusting the parameters that were used in the past to nerf rushing, else just leave it as is for now.

You can edit the map. Guess he just wants a map filter so random selection can be used (inferred from "when it happens I quit")

While the quality varies there aren't that many dupes in terms of gameplay. The least desirable is to just have a dozen good looking mainlands. Or in other words an awful looking but unique map shouldn't be dropped but marked as in need of work.

A blacklist is fine as long as it's from an authoritative source, like a government recommendation or a media company like bbc's to *beep* list. Then there are no discussions as to what should be on the list or not. Such a black list like any other won't solve the issue but shows attitude. Finding "trusted" and motivated people is very hard. Even if you have a couple such people to agree and enforce a consistent policy is tough due to different backgrounds and a huge grey area. This is a common problem and it's far from only wfg not being able to solve it for good. That it's probably out of reach to police it server-side doesn't mean there can't be client side tools like an ignore list. Both a blacklist with external source(s) and an /ignore <nick> chat command are one-time efforts to implement and I consider them suitable for wfg.

This is indeed looks like a rebranded rotary mill, vastly different from farmland in DE as in one of the poll options. If you'd called it building wells with an irrigation aura I wouldn't have been confused. The issues I raised are with the farmland concept which is vastly different from what you did. "Farmlands" is basically attaching a fertility value to terrain (per tile for instance). This doesn't only allow farmlands but could also be used to reduce yield in deserts or on top of rock. Wow had to settle with a hack in DE because proper support for this feature is lacking. Reverse importing this hack is something I'm strictly against. On the other hand the concept sounds interesting and can give map makers another tool to create unique content but needs quite a bit work design and implementation wise. Having prerequisites and restrictions are different, requiring a phase or tech like gunpowder to build cannons is fine. Restrictions on unique entities in history like hero or wonder aren't an issue either. Making houses dropsites or CC not being a dropsite are fine from a discoverability point of view. Whether people will like it is an other question.

That you can drop food at the CC you have to try once (well, the units will even demonstrate it for you), then you know how it works -> very easy to discover Clearly communicate as in a code comment, a forum post or some press release? -> awful discoverability About farmland itself: Where are the boundaries of farmland? What happens when the field is partially on farmland? What are the exact effects and how to present them in-game?

Resources as in cores, ram etc.

If min requirement is 1024x768 then gui.scale = 1.4 (1.40625) is the max supported for FullHD displays. So this isn't actually a bug per se.

I thought it was qbot and petra, but maybe qbot and aegis (around a13 to a15) would have to unpack some old tarballs to check though, quite a while since ... Anyway having more than one bot bundled is a non issue for players as long as they aren't bugged. One could be more beginner and resource friendly for instance. Dozens wouldn't make sense though. Participants would be less an issue me thinks, get a few professors to just tell their students about it. I remember a similar competition that was held by the department and about half the students participated. My ai lost in the quarter finals back then. Fond memories and a very good learning experience. The issue is more that the engine needs some means to enforce max resources used by an ai to make such a tournament meaningful. This mechanism would be good irrespective of hosting such.

No need to write it from scratch, renaming is just so you can let it play against petra. Some old releases of 0ad had more than one ai bundled. Wfg could also organize an AI tournament ...

Currently you can build your city as you like, but don't like how others build their cities, so to make all follow the same ideal let's add more restriction. Or add some boni no matter whether they can be reasonable communicated through the UI, people just can check the code (open source after all). How many people are aware of diminishing returns for instance? Some changes towards your goal easily discovered by players (whether they are desirable is another question): drop default arrows reduce garrison limit have CS have the same gather rate as woman

For eco stopping the ai from walking 200m for some berries would help a lot. Generally the ai doesn't mind large distances much when gathering. Danubius (map) would be a great benchmark for this. --- Adding to your initial list, ship trade is currently pretty much broken for the ai, so disabling it is an easy fix. In a perfect world to ai would be non-cheating. As for lower difficulty yet still interesting ai you could simply limit pop to let's say half what the player has at any given time. --- If you are serious about writing an ai, first thing give it a new name

@chrstgtr Before the meta was don't float resources, now the meta is don't float resources. The difference is you build your second barrack earlier. Unit production is still limited by gathering efficiency. As for rushing being less effective, there is no cav from barracks, better loom, changed unit motion, strong archers for defence and for p2 the rush units got nerfed or even removed and more. How come the least suspect change becomes the culprit. I really would like to greatly limit the permitted gameplay changes per release so people can still pinpoint what a change actually brought.

Even better outsource 12 of the existing civs so no one can complain about balancing anymore and development efforts can be spent on more important stuff! Seriously, han should be added. First to show appreciation for the work done, then for easier maintenance, lastly there is a rather large (potential) user base which has a much closer connection to han than any civ already in game.

@m7600 What I meant with a central command tower was basically an elevated platform from where you can see all the walls, so a commander can direct the defence from there with a few assistants waving flags which doesn't work with your approach. Anyway the last prototype looks great albeit more like a palace than a fort As for the texture colour, unlike in the west yellow is the colour associated with earth, so it's ok to assume yellowish earth to be rather dominant over there.

@alre There is a huge difference between requiring micro and rewarding micro. Let's take hunting, just a simple order is enough but micro like luring or driving the hunt towards dropsite pays off. As a casual player I don't want to be forced to micro but there is no drawback if others can gain an advantage by doing it. To much forced micro, not enough rewarding micro. To much as can be seen by the auto queue mod somewhere in the forum, I'm all for it if it's implemented to be less efficient than manual queueing. Not enough as seen by the mod in this thread, though not happy with the implementation I agree with the sentiment. Right, 0ad replaces micro with strategies like hiding in forests, rolling stones into a canyon that must be passed or in open combat with stuff like flanking manoeuvrers. Even if just one archer can kill 20 unattended archers but takes 10 minutes to do so it's like still not worth the effort. The point is micro battles need to be more rewarding than they currently are, at least a23 level, probably even more than that. I'm convinced that many changes between release are a mayor annoyance for casual players, worse if it's a back and forth like with training time proposed here. The situation after the change was neither better nor worse. So changing once was bad in hindsight, changing twice is worse. So can I take it you are against removal of turn rates as partially proposed here, as this only benefits a handful of top players while sacrificing neater unit motion and requires a new approach to single unit dancing on top?

Solving the single unit dancing I consider an intended side effect of turn time. The more important aspect is the much neater, less arcady unit motion. Freegarach saying this helping immersion I buy any day. Overall I consider the current turn times a good thing(TM). Just that it slightly widened the gap between p1 micro battles and p3 mostly macro battles which a minority doesn't like. Micro is essential skill for top players of rts, and the more opportunities to make use of it there are the better. Sure one should be able to be a strong player without excessive micro but getting to the top shouldn't be possible without. With that said I don't understand why microing against ranged units could be bad unless overdone, would be nice if you could clarify how you mean it. Picking "random" targets might indeed be sufficient against single unit dancing, however, the unit-ai being stupid is certainly another one of the annoying immersion breaking issues, so making it cleverer to some degree is certainly desirable. The randomized picking doesn't sound like the best direction to take this, unless performance doesn't allow for otherwise. Either have all units have reasonably good looking and plausible turn rates or drop it for all unlike this mod does, pretty please. PS: instead of slow projectiles another hit/miss test could be performed on impact based on unit motion.

Well, if the unit is dancing it can't attack, so it's fine to ignore it and to attack the others first (for this unit-ai needs to be changed). If all your opponents units are dancing you do little damage but won't receive any damage in return, this is completely different from the a23 abuse case.

The current logic is: if last targeted unit isn't dead -> continue targeting it, however stupid that may be for an onlooker. With this you can have one single unit attracting all enemies and dancing while your other units fire at the misguided enemy units. This is the case in a23 and is an abuse of dancing only possible with the current unit-ai behaviour and obviously annoying.