wraitii
-
Posts
3.395 -
Joined
-
Last visited
-
Days Won
75
Posts posted by wraitii
-
-
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.
-
2
-
-
Planned, but will not be added in the following days. I've got to get the rest to work first.
-
1
-
-
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.
-
This is due to the bot doing some basic terrain analysis at the start of the game.
About that... How "possible" would it be to allow the AI to initialize before the start of the game (ie during the creating map" part)? That woul allow for some slow calculations such as terrain analysis to be noticeable.
-
Well, I'm not really using entity collections since I was never sure how they worked... Mainly the "entity" class, afaik. I like most of the changes planned so I'll likely upgrade when it's released and I get time (thoough I'll be on holidays again by that time, so I'll have, well, time)...
Is the "UnitAI further support" going to be implemented? That would be a huge argument in favor of upgrading for me. (reading your qBot post, looks like yes).
Anyway, thanks for the support
-
A little further progress report, I've begun coding... The classes implemented to store and count buildings and units are basically done, though I'm adding new functions as I need them. It's fairly interesting, since it allows to do a lot of counting in a faster way, and it's also more dynamic (units are no longer hardcoded, which would help with mods, scenario, or new civilizations ultimately). I'm now working on having everything work with the new system, and changing everything I'll need to change, which is a lot. Not sure how long it's going to be.
-
I believe to do this efficiently you'd need three classes inheriting from a "basic sound manager"...
-A "music" class would deal with musics... It would support pauses, fade ins, fade outs, and presumably only use one "Stack".
-An "ambient" class which would perhaps have an "ambient" sound looping, and occasional animal sounds or things like that (2/3 stacks at most)
-An "effect" class which would deal with short effects: GUI sounds, unit sounds, … They should be played immediately or not at all. I dunno how many "stacks" you'd need for that, probably a few to support simultaneous effects.
-
I'm supporting Jericho too, if a new wall system is made... Not sure about Jerusalem, it's a bit too religious for my tastes, particularly given the timeframe (no christians nor muslims back then)...
SVN users
in General Discussion
Posted · Edited by wraitii
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.