wraitii

Thanks for the report, Pureon... I think it's again a case of unit garrisoning... I think you had an army of soldiers of some sort and you suddenly garrisoned all of them, causing the entity collection GetCentrePosition function return undefined. Any other report?

Yeah, typeof seems dodgy with anything that isn't explicitly a javascript type, that's why I replaced it with some other check... I'm not sure I understand Philip's explanation, but I guess he knows enough . Anyway, it's good it's fixed now.

I've got to say, I didn't really try to reproduce it... It's a weird bug for sure, I didn't either notice anything that would have caused a recursion... Perhaps it was a special case cause by something I did that was unexpected in Javascript... I'm really unsure what the circumstances of that particular crash were, though it was when an entityCollection tried to attack a gaia unit (iirc). Unless it comes up again, I think you can ignore it.

Allright... This being my last day of holidays before at least 3 weeks of hard work ( ), I'm releasing Marilyn in its current state as a "proof of concept", if you will. Please report any error, suspicious warning, or weird behavior, this will allow me to tackle them when I have time. Note: it should only work with SVN. There is one non-lethal known bug: sometimes, the game will freeze for ≈10 seconds, before resuming with lots of "out of memory" errors. Afaik, there is no following crash or problem, I don't know what causes this, any help is appreciated. If it causes a crash for you, please report. Otherwise, I haven't really thoroughly checked, but it should be mostly working, at the very least in the 15 first minutes. I haven't actually played a game much longer than that since I started recoding, so I don't really know what could happen . It does about all the things the former Marilyn did: -Attacking. It will create armies, and will send them after the strongest enemy (I think), though it might get stuck sometimes, perhaps. -Defend. Marilyn will reliably attack any incoming army, and will deal with animals and lonely scouts. I'm not too sure what happens if one of its unit is out of its territory, but that should be a fairly rare case. I think the defense manager is actually more reliable than the former one at this point, even though it's not yet fully implemented. -Build stuff, much like the former Marilyn, only it chooses the templates dynamically using a system of roles. -The economic aspect of things is basically the same, I haven't touched it much, but because the plan manager is not yet perfect, it may have a few troubles building enough villagers in the mid/late game. What it doesn't do: -Raiding... And some things during attacks, such as responding to being attacked. I haven't had times to recode this, as I've basically scrapped using the old Tactics Manager, and haven't really coded anything new to replace it. -It's completely oblivious to technologies. Do not be surprised if Marilyn builds a fortress as its first military building. -It won't build towers or fortresses for now (though most civs will likely build a fortress as its first military building, bar perhaps the Persians). What it does better: -The Defcon system for defense has been revamped, and now Marilyn will garrison/ungarrison females. The defense manager is also more clever, it's able to pause attack plans if it takes their units. -It's not "better" per se, but Marilyn is now mostly dynamic for unit training and building. All civs are supported. This doesn't change much compared to qBot, but you'll notice Marilyn training champions for its attack plans instead of anything, and building fortresses instead of Barracks, things like that. Technical side of things: I use entity collections everywhere. In the two "census "files, which are the unit/building info manager that Marilyn uses to know what it has/what it can build. In the defense manager, for enemy targeting/knowing which of my units attack. In the enemy watchers, that keep track of enemy armies. It's very neat, and very dynamic. Quantumstate, if you read this and have some time, I think it could be interesting to look at the code (most notably in the attack plans/defense manager), there are likely some stuffs that you can put into qBot. There might be a git repo in the file... Ignore it, I haven't updated yet. Marilyn.zip

I tried it quickly (in an inelegant way, and I want to leave the implementation to howlingflute anyway) and I guess something that ranges from alpha 75 to alpha 175 for a lack of resource from 0 to 500 would work well.

Good idea. Not sure if that's actually feasible, but I think using the resource icon and not the name would improve readability. Ever so slightly, but still. Also: it might make it look a lot like a Christmas tree, which would be bad, but have you tried coloring more and more red as the resource lacking are important (with alpha)? So that at a glance, we'd now how much we need more. If it works from an aesthetic point of view, it could be useful. I think the effect can be quite potent even with small differences in the alpha, so that it looks good, and useful. Edit: I also recommend changing your code in Unit_command.js to this: if(guiName == CONSTRUCTION || guiName == TRAINING){ selection.hidden = true; var totalCosts = {}; var multiplier = 1; if (guiName == TRAINING && Engine.HotkeyIsPressed("session.batchtrain")) multiplier = 5; for each (var r in ["food", "wood", "stone", "metal"]) totalCosts[r] = Math.floor(template.cost[r]*multiplier); var neededC = Engine.GuiInterfaceCall("FindCostNeeded", totalCosts); if(neededC.length){ //only put on the red overlay if the button is not already grayed out if(button.enabled != false){ button.enabled = false; selection.hidden = false; } button.tooltip += "\n[font=\"serif-bold-13\"]Insufficient resources:[/font]\n"+neededC.join(", "); } } It will show red properly if the user clicks on "shift", which is much more intuitive. It doesn't take into account the batch size, though, I'm not too sure how to get that.

Not sure if it always happen, but i've had this crash while making an entity collection attack: ERROR: JavaScript error: simulation/ai/Marilyn/entitycollection-extend.js line 10 InternalError: recursive object ([object Object])@simulation/ai/Marilyn/entitycollection-extend.js:10 ([object Object],[object Object],[object Object],[object Array])@simulation/ai/Marilyn/attack_plan.js:252 ([object Object],[object Object],[object Array])@simulation/ai/Marilyn/headquarters.js:1545 ()@simulation/ai/Marilyn/marilyn.js:128 ([object Object])@simulation/ai/common-api-v2/base.js:122 @:0 (It's using Marilyn but the code is the same in qBot, as far as entity collection attack() is concerned). Replacing it by this fixed it: EntityCollection.prototype.attack = function(unit) { var unitId; if (unit.id()) { unitId = unit.id(); }else{ unitId = unit; } var idArray = this.toIdArray(); Engine.PostCommand({"type": "attack", "entities": idArray, "target": unitId, "queued": false}); return this; };

This really looks like the real thing, Yodaspirine, great work. We need a cheat code: Assurancetourix (or whatever the translation for the bard's name is), and every celt warrior has its weapon replaced by a fish.

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.