wraitii

I'd really like something more organic than a hard limit. Perhaps add an "Unfertility" aura around buildings in general, except a mill which would work opposite? And you'd have a nice overlay when placing your farms? And then we could have pretend-farmlands by placing invisible static entities with that aura too. (can auras decrease by distance?)

Also note that the AI tears those walls down because it can't really deal with them.

Thanks Yves for that one, I've fixed the "template/.xml" issue (normally), might commit it shortly. edit: no, sanderd already fixed it on his own.

we should run the GC every turn for testing purposes.

I can't seem to be able to reproduce any of those, so I'll ask for the commands.txt to be posted so I can see what happens.

That seems absolutely huge, even for compiling. I'd post it over to the Spidermonkey forums. Maybe an issue with rooting.

It seems linked with Gameboy's and Yves' on IRC this morning… I'll look into it tomorrow, I was working on synchronised random seed but I've run into a dead end and it's just too annoying.

I'm bailing out.

I will say for the record I'd be interested in a brutally realistic and unbalanced mod.

We disagree on the definition of "what's right". I do not see how that leads you to think we have the "same mindset as them". Also "them", game companies, are far from all being kill-all-the-fun-give-me-your-money companies. That means you're not agreeing 100%. Maybe because you're trying to force 0 A.D. to be a different game than the game it is. It's not a biased sentiment, it's following the game design. It was never intended in 0 A.D. that you were able to starve your opponent. Again, this is not a simulator. As for your point about being a long-term hardcore fan: we are happy to have long-term fans. But we assume that most fans agree with us on the general design of the game. Your feedback is about changing the core design of the game, in ways that we do not want. It is however totally applicable for a mod, which I would encourage you to try doing (and I'm sure others would). Also: disagreeing with you doesn't necessarily mean we are "retaliating", just responding.

When did this happen? At the start of an RM/Scenario/skirmish? If so, which?

The animations generally look alright, but you definitely need to make them feel more organic: on the idle one the head alone moves in the end, on the attack one the back of the body doesn't move at all. I know you've said they were concepts, so you're probably aware of this, but I just want to make sure.

I'm opening this up after reading some more discussion about farms and obstruction sizes. It seems like the consensus in the team is that farms should be bigger, so they're harder to defend. We also discussed making farms depend on terrain and have more profitable and less profitable terrain for farming (see this). I believe the fundamental issue with our farms is that they are large buildings with an obstruction. Making them larger means you will be able to build them in even fewer places, which is annoying. So what's the solution for organic-looking farmlands? Make farms smaller, and limit them to one worker. If our farms were, say, 2x2 tiles, we could plot many around and it would be able to look pretty good (particularly if the decals extend a bit), the fields would actually look occupied by workers (instead of just going around), and it would still take up a lot more size. Then we can add fancyness such as irrigation auras or stuffs like that if we want.

We had a good discussion about the fact the farms should be way bigger back then, but never tried it...

I feel like this is getting metaphysical and the arguments could be said of anything old and new with very little rephrase. Regarding the JIT issue, we mostly discovered that it was a JIT issue, so it would likely be much easier to debug such issues this time (others of new kinds could, it is true, arise). What we have already discovered is that the new Spidermonkey is stricter about lax syntax and things like that, which are sources of weird, unpredictable, and hard to debug issues. We also know that it supports multi-threading to a greater extent. And regarding performance, there are several stuffs beyond just compilation magic that could help us, such as new objects (Maps and Sets) which possibly could speed the AI a lot. On 1.8.5, I do not believe the AI will ever be efficient enough. GC is quite likely to get faster, particularly if it can be fragmented (which ought to be able with the newer spidermonkeys). If anything, this should be a separate branch on Git. Somewhere you can just try it easily at some point, to see how some changes react. If we're going to get economic, the opportunity cost of not trying the upgrade is just too high.

I'll give it a look. There's an issue currently, the AI gets stuck on farms, it's because of this morning's changes, I'll fix it tomorrow.

Rodmar: interesting ideas, I hadn't really though of many ways to extend this but that could be nice. Like a "stone age" gameplay that tries to still be fun without all the fancyness. Ludo: Thanks

I agree with Micket that it's too blocky so far, but I encourage you to do your own too, as we do want variations. if you know how to, perhaps create a very high-poly model with sculpt or textures to achieve a grainy "old granite" effect for the normal textures.

Could you give me some input on how early an "early rush" would be to you? Also with how many units did you attack?

Gameboy: I haven't committed the fix yet.

Gameboy: That's now fixed Lion: thanks for those, I don't think they're fixed yet, I'll look into it.

greenknight: did you say you saved and reloaded before trying? Because that would break the AI in many ways and is expected not to work too well. On the other hand, I haven't noticed the AI getting stuck on Alpine Valleys. It started really slowly on Deccan plains but that has been fixed, so now it should work mostly properly. Still, it's far from perfect anyhow.

I've given a look at this the other day and have been completely unable to understand what happens. Collada seems to load the skeleton properly, so the issue is with the model. But importing/re-exporting in Blender fails. And there has been no obvious changes that would have broken the boar.

Those errors should be fixed now, thanks for reporting them.

I agree with Yves that the GC improvement in the future seem far from trivial to me. GC is slow in 0 A.D. and leads to a bunch of other issues, so that would be very nice, and if only for that, the upgrade is worthwhile.