wraitii
-
Posts
3.395 -
Joined
-
Last visited
-
Days Won
75
Posts posted by wraitii
-
-
There are only slight compatibility issues between Leopard and Snow Leopard, which was a 20$ minor "major update" of the system, mainly to streamline everything. It was massively adopted, so supporting 10.5 has no reason to be a priority.
-
Not as of now... I'll try to reproduce the error anyway, since it's fairly bothersome and I have reasonably sped up the attack plans.
-
Yeah, that comes from me sucking at this game so I don't really know what's efficient enough. I guess 2/3 units would indeed be better, but it might require a bit cleverer movements from the AI to not get his units killed in a few seconds, which I do not have right now.
I'm trying to improve the performance of my plan managers but it's proving harder to do than I expected... I'll look into the "defense error" thereafter.
edit: can't seem to reproduce the error you're having... Any details on how to do so?
-
This error is confusing me... I'll look into it. I'm not sure what's causing the lag... The economic manager has been sped up quite a lot, but there is something in my attack plans that lags terribly...
Btw, what map were you playing?
Anybody noticed that Hellenes cavalry raid specifically target your villagers?
-
That is weirder. This should work:
if (!unit || (unit && !unit.position()) ){ -
Mmmh, it looks like line 279 also needs to be changed to this:
if (!unit || !unit.position() ){ -
Ever been to 0ad.com? Let's just say it doesn't return the expected result
-
Yeah, making an AI work properly for absolutely trivial tasks such as where to build a mill is what makes you realize the human brain is amazing.Marilyn restarts attack plans all the time for now, but it's "wanted", because it's the best way I found of making it work fairly properly for now.
@Pedro Falcao: yes, she ignores the fog of war... But I made her only detect incoming army in her territory to compensate. LOS I think could be added by some changes in the C++ code (there is support for human LOS, apparently AI LOS is possible to have at some point), but it would increase lag.
Attacking your rams however works as designed... The way the "battle manager" works now is to send units deal with each group of enemy , so your rams were detected a a new group and units were sent.
-
Is this AI deterministic, in the sense that if the player will play (theoretically) twice exactly the same, then the AI will react exactly the same?
I was just thinking, if you have a modular queue manager, you can arrange the queue with a precise formula that will consider all the input to produce the perfect output, but you can make it adaptable, so it will learn during the game (or between games).
Am I making sense or is it a completely different thing?
You're certainly making sense, but I do not have the skills to make it "non-deterministic". I'm not sure there is a point either. I think the AI in AoE3 is a bit what I'm trying to achieve : deterministic, but able to store a few things (such as "when the player attacked") and sort of react to that. Optimally, I'd like to be able to do that and better, but I'm unsure I have the skills required (I'm not a real programmer... Hell, I'm not even a programmer at all, I'm studying economics.)
I also have very little idea of what the team wants for their AI, though seeing what was already achieved, I think my ideas are not that faraway from theirs.
@Zaggy1024 : indeed.
-
Okay, yay new version.
Actual improvements this time around:
-Attack plans are better, and I implemented a "raid the villagers" type of attack... It's much of a work in progress, like the attack plans in general (this is really the one area that's freakin' hard to implement... No wonder most AIs use "create an army and send it to enemy base" as a means of attacking.). Though not all civilizations will benefit from it (It uses cavalry swordsman, and I think only hellenes have an early access to those. It'll be changed in the next version). Test it out on Oasis.
-Attack plans are now started if the "maximum" amount of units are built.
-Generally more efficiency during attacks for attack plans and defense.
-gatherers should generally stay on their resource for longer, ie the AI will change their task less often.
-Queue manager changed again: more readable, more efficient, more modular (individual plans can be set as "most important"). Generally better and more efficient.
Technical stuff:
-Attack plans use their own queues, and generally rewrote those a lot. More modular now.
-Cleaned up the code further
-In the "reassignIdleWorker", it checks if they did something before and puts this as the top priority. This is good: workers will change tasks less often.
-Tactics can now split and regroup groups after initialization.
I'm not 100% sure every new stuff is bug free, but I playtested it fairly thoroughly, so it should work. Report any bug you encounter, as well as any weird AI reaction.
Edit: darn ,still a problem I left over with garrisonning... Replace line 285 of "mil-Tactics.js" by this:
if (!entity || !entity.position())
And line 279 also needs to be changed to this:
if (!unit || (unit && !unit.position()) ){Speed improvements over the economic manager are a bit countered because of the modifications to attack plans, but overall on "time warp" it's still faster than qBot on my computer.
-
I can't see what would cause that, unless you played a civilization that has no known ranged infantry (the Romans perhaps?)... Anyway it's not important because that part of the code has been completely rewritten.
-
Okay. Perhaps if you're someday coding pathfinding for ships specifically, you could reuse this for charging horsemen... I'm fairly sure they'd behave in fairly the same way.
-
I'm really not sure that the third feature is compulsory.
-
He has done a few modifications, but nothing fundamentally different, I think.
I'm not sure what you mean by your second question, could you rephrase it?
I've finished updating my attack plans to allow for more precise unit construction (archers, javelins and not only "ranged"), planning for raids. It was a bit of a pain, but it works.
-
No, I just decided during the Christmas Holidays to create a new AI. And since QuantumState, maker of qBot, is too busy to really work on qBot, I though I would keep on improving it.
@Pureon: that's planned, should not be too hard to do at least basically.
-
I can tell you with 100% certainty that you have indeed garrisoned a unit right before the unit appeared
.Okay, so since that seems to be taken care of, I'll now proceed to try to actually add stuff. I've already made the AI stop changing its workers of task every minute, so it behaves more humanly (and efficiently)
-
Mmmh, I forgot about garrisoning making the position undefined, this must be it because there's no way the units that are sorted by this function are dead. I'll give it a try.
(What's fun is that I really, authentically suck at this game, so I never try to garrison anything. I'm even unable to defeat my own bot.)
edit: Yup, garrisoning a soldier makes it go mad because I completely forgot about that possibility. Easy fix.
Anyone else tried playing around a bit?
Fix: line 378 of defence.js, add:
if (enemy.position() == undefined) // unit is likely garrisoned. DO not check.
continue;Edit: actually elsewhere too, I'll continue to playtest with some garrisoned units to see if there's any other spot.
Line 428 of "attack_city.js"
if (enemy.position() == undefined) // likely garrisoned
continue;Edit^2: darn, also in defence.js, line 200, replace the if condition by this one:
if (enemy.owner() == ennemiPotentiel.owner() && enemy.id() !== ennemiPotentiel.id() && enemy.position() !== undefined)
-
To notice the speed improvement, you'd have to check the profiler on time warp. It becomes very obvious then (otherwise, this function is called once every 10 turn so it's not that noticeable)
These errors are very weird... Apparently, enemy units that are supposed to exist don't. I see absolutely no reason why... Any particular action that was happening when you got those (attacking marilyn, destroying her?)
The warnings are "normal" debug warnings, though, you can turn it off in "Marilyn.js".
-
Allright, I've decided to upload this newer version a bit early, mainly because it's fairly interesting... The main feature is speeding up of the "reassignIdleWorker" function, by dividing the map into subsquares and looking in those. It's really much much faster on maps where there are tons of trees involved. On Gambia River, this newer version is easily 5 times as fast as qBot, sometimes more. There doesn't seem to by any bug left, though if you notice any "dodgy" behavior in the "looking for resources" area, let me know.
Other things I did: clean up of the code, I removed many unused functions that were left-overs from qBot or early development... Actually implemented garrisoning citizens in case of major attacks. I did a lot of fairly small "sanity checks" that should remove most of the "error: whatever is undefined" errors, though I'm not sure I got them all. Fixed a little bug that could happen on some map with houses.
(BTW: qBot should have a check in "accessibility". If the "start" point is undefined, there's an error).
So now I can start the more interesting stuff, such as actually adding features.
Edit: bug noticed thanks to Pureon. It's not a gamebreaker but you'll get a ton of error messages if you garrison a soldier:
Fix: line 378 of defence.js, add:
if (enemy.position() == undefined) // unit is likely garrisoned. DO not check.
continue;Line 428 of "attack_city.js"
if (enemy.position() == undefined) // likely garrisoned
continue;In defence.js, line 200, replace the if condition by this one:
if (enemy.owner() == ennemiPotentiel.owner() && enemy.id() !== ennemiPotentiel.id() && enemy.position() !== undefined)
-
Allright then. Indeed, it's more logical that way.
To do some "idiotic stuff", I've tried renaming the app bundle... Still works.
Atlas starts, but I get a wxWidgets error when I try to move around :"../src/osx/cocoa/combobox.mm(114): assert "item >= 0 && item < [m_comboBox numberOfItems]" failed in SetSelectedItem(): Inavlid item index."
-
A slight concern: what about horses? Are they assumed to be able to turn 90° in an instant? They will one day be able to charge, how to implement this?
-
There is certainly space to simplify my code, even without any API changes... I've modified stuffs from qBot while not necessarily removing them, changed things, made some pretty idiotic design choices now and then (It's now changed, but I asked the "game" for the entity associated with an ID... By asking said entity to give its ID. In other words, I asked for informations I already had while using it).
I'll try to clean the code, to remove most errors, and to optimize the code for the next version... I'm currently cutting the map into smaller squares for the economy manager so it won't have to loop through every resource on the map each time it wants to assign a unit a task... It's working much faster (on Gambia river, a forest-ridden map, it's at least twice faster for each unit, so it's quite quickly 5 or more times faster), but it demands quite serious code change.
-
Well, there are 4 batches of wood on the right and 8 on the left... My concern was more about "reachability"... The players on the left are much closer to the wood since it's more packed... This is not a huge concern, but I'm reminded from my old AoE II age that this can sometimes make a difference (particularly since they wouldn't have to build a dropsite)
That's why I suggested moving the town centers a bit farther from the Nile: all players would benefit from building a dropsite in the early game.
But it's not really anything too important.
-
Gave a look at your code, I see why it would be fairly complicated... Given the way the map is designed though (river starting from the top going to the bottom and the sea is at about 2/3 of the map), perhaps you could factor in a "WATER_WIDTH * Math.max(1,(iz - (mapSize*0.6) / 10.0))" instead of simply "WATER_WIDTH", which would effectively enlarge the width after you reached 6/10 of the map's height.
(I'm not sure this code is clear to you, I think I used your variables, if you have any questions, do ask).
edit: giving this a try... For now it flooded the whole map, which was fairly fun but not very playable.
edit 2: gave this a few tries... it's possible using a finely tweaked "1/(-x+2)^3" sort of function, but given that the lowest part of the island is not always exactly on the same spot, can't be done every single time.
raiding party
in General Discussion
Posted
Anyone played EUIII around here? Perhaps the "+10 X" should simply float above the killed unit. The problem is that it may crowd an already quite crowded battle area...