wraitii

Yeah, that's what I meant. I think it's both the most realistic and the easiest way to institute a limitation on the number of workers.

A simple system would be to have markets resources slowly rise, and every trader would take from that stockpile. So if you have 10 traders, the first 3 would get resources, and the next 7 would not because the market has not replenished.

Terrain would definitely benefit from normal mapping and parallax mapping. Units, I still wonder because the camera is always fairly far away (though it could be used, of course). I think buildings could use it for the tiles/blocks of stone/whatever to a great effect. AO should be baked beforehand for units and buildings, to me. There's no real point in dynamically computing it in 0 A.D.

Interesting development tool, interesting to have in the game.

It works fairly well as long as the training follows... The hardest part is dealing with sudden needs (such as a fortress build) or with the aftermath of an attack, because you might want your females to chop wood or stuffs. Testing a very basic version in the early game against the latest qBot, it seems about 600/700 resources more efficient... Anyway, don't expect it too soon, I'm going to have a very busy week.

Allright, I originally intended to implement a complicated resource gathering system... Only, it's too complicated to be any kind of practical (because I need to plan for future unit creation, mainly). So, I'm changing my plans to a much simpler system: I'll assign my females to food gathering, and citizen soldiers to the rest. This won't change during the game, unless there is a particular need (fast collecting for a fortress) or a discrepancy (say, after an attack). It should prove efficient, as it's what most players do, with great success.

Yeah, the game is hardly balanced but afaik it was not a concern (or at least, a very minor concern) for the Alphas. Then again, 0 A.D. will have to come out of Alpha someday, and it looks like it could be soon enough (well, relatively). BTW, Mythos, I see you decreased starting resources to 300 each, that's probably something you want to put in the "release info" on the homepage.

Hence why I think, at least for the first age, it should probably be "5 buildings of the village phase or higher", aka "5 buildings".

Correct me if I'm wrong, but isn't it even weirder if you can't go to town phase while already having, say, 5 buildings from the town phase? Agree with the starting resources being lower. 1000 is a lot.

Is it really necessary for structures to be village structures then? It seems a bit counterintuitive to me.

Expect it within 2 weeks, perhaps 1. Apart from the many bugfixings, Alpha 10 features, as you said, neater walls, technologies, but also healing and AI improvement. And many many bugfixing.

Perhaps 2 could be implemented as "shift+ungarrison all" or something.

Well, removing "village" is a possibility, since you can only build "village structures" anyway. Perhaps "Requires 5 buildings" would probably be the most explicit/short. "Of any type" makes it looks like they must be the same type or something, it's kind of confusing. I still think 5 is a lot, BTW... I know 0 A.D. ain't much for rushers anyway, but perhaps it could be set to 3 or 4. Or perhaps as a civilization bonus.

The best thing is that Quantumstate implemented correctly something I was too bored to implement: counting how many gatherers work an any supply. I think i'll steal that code in return . I'll have to test the new qBot, it's probably going to be a great benchmark for my new economic implementation in Marilyn.

This looks very good already on buildings, I'm extremely unsure the game needs anything more for buildings, given the maximal zooming of the camera. However, Parallax mapping on the terrain could give a very cool effect for things such as grass, where it would be MUCH better looking, and I think you should focus your efforts on that.

Allright, following Pueron's advice, I'm revising the economic manager, and making interesting progress. The new idea is that I keep a list of resources that I want to collect from for each resource type (ultimately, perhaps subtype too), and then I'll assign the most efficient workers to each. Still much of a WIP, but I think it can be very efficient. And as it seems like Quantumstate added a way to count the number of entities working on a resource at any given time, I'll probably get some inspiration to do that from him.

Parallax mapping only really needs to be implemented for buildings and terrain, however, which considerably simplifies its adoption. This all looks particuarlry promising anyway, keep up the good work

Any update?

Oh yeah, should have remembered that from when I tampered with HDR on Ogre. I still think the effect is too strong, because for example in your screenshot the whole ground is bloomed... at such a scale bloom should only happen on extremely white stuffs, I think (which should solve the 'units lose their shadows' problem). But hey, that's for the art department to decide, and anyway, it's very cool .

Yeah, Mythos and Bruno seem to be on that... I've sent him a PM about this, but then I figured that it's probably not too expensive to count the number of workers on any given resource at any time, so the PM I sent him is really a non-issue... I intend to fix it, and along with some clever UnitAI, it'll be.

Yeah, the effects might be a tad too strong (it looks like someone upped the contrast a bit too much), but it does give this sort of "I don't know what they're doing, but it looks niiiiice" feel that is really cool. Not applying SSAO to the terrain would indeed fix the halos. My guess is that most units wouldn't require it either (or as a setting for really advanced graphics, since that would computationally be slower.). Afaik, specular is dealt with on a case-by-base basis already, can't SSAO be done that way too? Buildings could use finer SSAO, while most units hardly benefit from it. For the terrain, you could have, on the contrary, a very rough filter that would have the effect or pretty much not detecting units, but would make the inside of forests darker or something (perhaps a huge downscaling, or something, I have no idea of the technical details behind all this).

Ouch, that hurt . i've got to learn to play this game properly... Anyway, thanks for the test... I noticed Marilyn being quite confused when you attacked during her attack, which shouldn't be... Will look into that and this error.

I think it's because of a failure to reload the GL screen or something... They're aware, it's been disabled in the last SVN afaik. Though I liked it, this CTD was the fastest way to quit the game when debugging

Good to know, thanks! Allright, I'll keep watching. No problem about the technologies, take all the time you need, better done well than rushed. Another thing about the API: I see you use "VectorDistance" for "ByDistance" filtering... I've done checks in the past, and at least on my computer (but I'd expect on most), it was faster using SquareVectorDistance, even with the added multiplying (though by very little). Since afaik this will trigger for every position change for every entity in any entitycollection that requires it, I think it could be a, however little, welcome addition (if for some reason, one comes to do it 1000 times per turn in some extreme cases, it could make a difference).

You're a very good beta-tester in that Allright, it's fixed in the lazy way: it won't return an error, and the code should still work consistently. There's no practical and cheap way to check if the unit has a position in entityCollections.