wraitii

Perhaps when ringing the bell, soldiers would deposit their resources to the nearest dropsite, and instead of garrisoning inside, would start fighting. I guess a variable could be used to store which entity they were working on before, so that they would return to it after the bell 'unrung'. It'd be nice to have a list of dead units though (something along the lines of (lost 10 stone workers, lost 5 food workers...)), since otherwise the player would have to count manually.

Hi Quantumstate... A few more questions about the API. First, I'd recommend adding the "NOT" filter. It can be useful to check something like "Not a worker". Filters["not"] = function(filter1){ return {"func": function(ent){ return !filter1.func(ent); }, "dynamicProperties": filter1.dynamicProperties}; }; Secondly: you give every entity collection a "this._ai" property... It works as a reference and not as a copy, right? Javascript is messing with my brain about those things. Third: I sometimes get a "length NAN" error with entity collections if I don't ask for the length immediately after the entityCollection's creation. I guess that's an initialization error somewhere. Finally, and this is perhaps more of a general question, it seems that after some times, using a lot of entity collections, I get a "out of memory" error in GUI/sessio.js, in an (eval) or something... It doesn't always happen, and judging from the profiler, the AI script doesn't seem to overload. And there is no following crash. Any idea what this error is? edit: oh, and any ETA on AI support for technologies?

Okay, I've done this 5 good days of work during my holidays... I'm getting close to being on par with the former Marilyn, but not quite. I've also redone a ton of stuffs, because some things weren't fully logical, or simply to make it better.I'm using entity collections pretty much everywhere, it's fairly nice. I'm going back to school in 3 days, and I'm going to have a lot of work for at least 3 weeks, I'm unsure how fast I'll go. I'll probably also try to support technologies before releasing the new version.

I do understand it's not the highest priority (though something in the GUI would be fairly neat)... it's simply something, as far as art is concerned, that should be considered, and imho done at least to some extent. It's sort of "expected" in a game like 0 A.D. Since 0 A.D. is set on a fairly short time period, and given that it's "village->town->?", it makes sense to try to convey the feeling of more activity instead of redoing everything, which anyway would be a bit too hard.

There could be some sort of graphical change when you grow in phases though... Like dirt tracks becoming true roads, perhaps more "actor" props in things like markets (more merchants)… It's very much a graphical thing, but it does look very cool... And I think it's better for 0 A.D. not to have building meshes change (à la AoE) but rather small textures/props change to reflect the passage from village to town etc. Also: it's nice to always now which phase you're in, having the progress bar in the top bar would be a good addition.

If you've got the data on hand, I can upload my SVN mac version which should work as long as you put everything in the right folders (it's not in a nice package, but it works). @Quantumstate: still, it'll have to be done at some point . Indeed, very good progress has been made since the beginning of the year, the game is really coming through. It's "basically" feature complete, and has yet to be optimized, but it's extremely promising.

More work for the AIs Very cool, though. What's left to implement, as far as big features are concerned?

Ah,I'm a raider/rusher/gonna kill your villager kind of player. But I'm merely an tech rusher. I played AOE 2 relying exclusively on my speed to advance in ages. I once stopped a rush with a castle. 0 A.D. is currently very unsatisfying for people like me.

AFAIK, units on ships are already "in", but I'm not sure the graphics are handled. It might only work with archers, too. I think waves/more ship animations are part of what the team wants to do ultimately, but it's not top priority. More eye candy stuffs right now is possible, but laggy because the game is not nearly optimized enough. Farms are intended to be overhauled for alpha 11 (not the next one), being infinite, with only 5 workers at most on one farm at a time, and diminishing returns for each worker. Also: bonus if the farm is built on "arable" land. I'm fairly sure fishes are intended to deplete ultimately. I think it was discussed... And if I recall correctly, already in ancient times overfishing was a problem. Your "outpost" idea kind of defeats the interest of territory, which is to have to build big buildings to expend, I think.

Mh, no, actually, should either be === "undefined" or === undefined, not sure which one works. I did that because if it is undefined, it will send a warning. It's not a huge problem ,I think it still works properly, but it can be a bit baffling.

I suggest, in entity.js, replacing the "ressourceSupplyAmount" and "RessourceCarrying" function by those, who check whether those parameters are defined: resourceSupplyAmount: function() { if(this._entity.resourceSupplyAmount == undefined) return undefined; return this._entity.resourceSupplyAmount; }, resourceCarrying: function() { if(this._entity.resourceCarrying == undefined) return undefined; return this._entity.resourceCarrying; },

That's supported already, qBot simply doesn't do it because it's not necessarily the most efficient way to place buildings, rotating them all over the map (I do that with Marilyn because I find it more aesthetically pleasing, and it looks more natural). The problem with walls is actually two-folds: walls that pre-exist must be "discovered", I'm thinking of the Iberians now in scenarios... In that case, the AI must learn there are walls. And we need a way for the AI to rebuild destroyed walls/disband and rebuild larger if needed. It's certainly possible, it just requires some work. Then again, not more so than a proper attack system.

Looks like good progress. AI building walls would, imo, first require that we implement actual terrain/chokepoint detection. I'm fairly sure using a basic circle/square that encompasses most things we could do a fairly efficient wall building (walls cutting through forests would be nice though). What is harder is detecting the presence of walled in buildings. Note: the AOE3 AI actually can build walls, even fairly well, it's only deactivated (it's in one of the scripts. ) because it won't try to rebuild broken walls I think (which comes back to my second point: being aware of the wall is harder than actually building it).

Testing Marilyn against SVN qBot a bit today... I found qBot not so efficient at collecting resources (well, compared to what I recall it being). It may be a problem of some sort, perhaps map dependent, but it built units at a very slow rate, and only manager to raid me on Oasis 10 after 8 minutes... I think it did better somewhere along Alpha 8.

BTW, I've given this 30 minutes today, and the thing is now basically "api-v2 compatible", which thanks the the unitAI state and the new entity collections, will prove useful in the long run. Here's a breakdown of what is still to do (in gross order, but I'm forgetting things): -finish upgrading the files -finish the new plan manager, and make sure everything works properly -rewrite the code for resource collecting by shifting the focus from the worker to the resource. (ie now, we for each worker look for a resource... I think doing the opposite would be better), or perhaps a mix of the two) -rewrite the attack plans code to use entity collections… and a few other things -write the enemy manager using entitycollections -write the new micromanagement manager -??? -Profit.

I'm afraid that's going to be fairly hard to do properly, since I'm currently upgrading Marilyn to the common-api-v2, requiring SVN... And there isn't much to show yet, I haven't finished rewriting everything to the same state (been lazy).

Thanks for the answer Quantumstate... I guess I'll have to copy the code in a modified way for my unit/building managers, but i'll use entitycollections for the enemyWatchers. Retreat must be dealt with for small raids if you want to keep the army... For anything else, unless a specific unit must be preserved, it can be overlooked, I think.

Confirmed: you have introduced a bug between qBot and the common-api-v2: the gamestate GetEntityById function no longer works: this is because when creating an entity, it tries to access "entity.template", when it should try to access "entity.templateName" in that particular case (I think the other cases work properly).

I've gotten a bug with the "Gamestate.getentitybiID" function as used by qBot... Apparently, you changed something, and now the Entity function wants to access "entity.template" when, in that case, it should access "entity._template._parent", unless I'm mistaken... Any information?

Getting the attacks to work properly and humanly is ridiculously hard to do, I must say. I've given this a lot of thoughts on Marilyn, and it basically requires tons of things to only begin to work as expected. However, one could likely hack something together.

I'm really wondering how much I should update Marilyn with the new persistent entityCollection system... It seems to rely on basically the same principle as my "unitInfoManager" (keeping track of units and adding/removing them as they appear/die). Did you do any specific optimization? I might just use it for the enemy and the attack plans/ "micromanager" managers which I plan to implement.

I'd be ware of the "plastic model" effect that specular can give... On the shields, it makes them appear really shiny, almost plastic. Using "noise" on the specular images might reduce the effect.

Planned, but will not be added in the following days. I've got to get the rest to work first.

I'm working on the new plan/queue system... This is going to prove difficult, as I 'm not keeping the queue system to allow for a few different stuffs... But I must say, it was very convenient .

This is actually a special case: only in the desktop or in windows set to act "like a desktop" (not sure how to phrase that, ie not lists) does it matter. In the dock, the whole "block" is clickable anyway. When viewed in columns, it's all clickable too.