wraitii

Here's a mostly finished version of the Egyptian Fishing Boat I made earlier. Texture is shippable. It'd need a fisherman and animations, obviously. Currently around 1000 tris, can be easily reduced to anything up to 250 tris. edit: looking at it, I'd need another band close to the top, where the width of the hull is minimal, to explain this. But other than that and some small tweaks I think this is good. edit2: I can't decide if it's too yellow... How is papyrus supposed to look when dry? edit3: Enrique mentioned lowering the deck (and probably the whole ship) in the water, too, which I forgot to do.

Almin: I have no idea if it's a classic system. I even have no idea if it's the best, but it works nicely enough. And it wouldn't change a thing for serialization, no. historic_bruno: BTW I've answered you here and haven't heard back from you, and there are fairly important issues at stake there.

It's actually not that easy to just save the AI state. If you restart from scratch, it's going to make terrible decisions... You need to save what it wanted to do with its villagers, things like that. Sure you could try to guess it backwards on loading, but some stuffs won't work (defense, attack…), and the way the AI is coded currently makes this extremely unpractical too (sadly). Fixing the Ai for saving games is actually not extremely hard, but doing it right is hard. And tied with how javascript fundamentally works, which might change as we are considering upgrading.

We haven't yet sorted out issues on how to serialize the AI efficiently, so sadly this will take some more time Gameboy.

To be honest about AI things like that, just tell the developer (me) how it works and the developer (I) will adapt. I've got an unadded optimization for entity collections, too, that uses a real array (basically if an entityCollection is not going to change much (few removals), then I keep a real array for iterating instead of an associative one. I wouldn't worry about that too much since it's so inefficient in Javascript that I might want to try it in C++ someday.

I'm not completely sure what started that error… It's happening on the normal AI too, but I haven't found the error, it's very odd.

I like (love?) the Uffington white Horse, but that might be because AoE 1 had that (or stuffs that looked like it anyway) and I remember 5-year old me thinking they looked amazing and were the most mysterious thing ever. Frankly, I still think so. There's not a single piece of ancient art that looks that modern in my eyes (looks like something Picasso might have drawn). edit: can't find any screenshots of the AoE 1 stuff, but I'm sure I haven't dreamt it…

It didn't actually change, I just fixed it. I still have quite a bit of work on the AI, in the end (naval stuffs remains semi-buggy and unoptimized, and the economy is not quite as good as it used to be as I've changed stuffs semi-blindly). Historic_Bruno, I agree about the errors, I'll have to look into them. The "wrong spot" one is annoying as right now the AI can't do anything about it, really. Fixing this means making plans resilient (probably easy to do) and means making the game send messages to the AI that a building placement has failed. This is more advanced behavior (tied with allowing the AI to scout the planned area beforehand for, say, Civil centers) and not started yet.

feneur: I'm thinking that's wrong. If we implement a coherent system to have options (not the mess we have right now in the c++ code. Seriously adding a new setting is horrible), we will need to have settings for each feature anyway, so it's actually easier to have them all layed out in an "advanced" tab. The actual work is getting the right settings for low/medium/high (and having a coherent "preferred settings" function).

Yeah, I'd like that too. Simple settings, advanced settings, just because I like doing random stuffs with my settings and I don't care about some stuffs (say shadow filtering or distance fog) but love having some others (AO…)

Interesting as usual. I agree about method #2, if we document it modders can just reuse those even for completely different stuffs.

I like 2 more solely for being more "realistic" (I'm assuming here that the max amount is the critical mass over which the fish population can't go for lack of resources etc.) I don't think the micro issue is really one, it seems like it'd be really really really complicated to do properly (but AIs might manage it).

I like the idea. Using tech pairs, we could have some interesting decisions.

Sanderd17: probably in source/tools/atlas/game interface/handlers/elevationhandlers.cpp Atlas source is a real mess, defining a brush is done in like 3 places...

I'd recommend looking at how others GUIs do it and pick the best system, for that. Though I probably won't be able to help, I certainly support any work on the GUI

Looking very good so far, a few comments: I really like the "more options" screen the look of the "separators" is really cool, and it works well where it's used (which includes match setup). However, I feel lik the background gradient doesn't really work for the diplomacy window. Given what you're after, I think solid colors with vertical separators would be a better choice (sort of what you did on the match setup screen). I'm not a huge fan of the colored blocks. Looks too colored, imo. There's probably a way to tone it down, but trial and error is key here I think. The arrows for the dropdowns look too big and too textured to me, compared to the rest. I know "flat" design is really in right now, but I think a solid, smaller, perhaps slightly more orange arrow would work better (also, they're asymmetrical, which looks weird). But generally I really like the direction, clean, dark, with drop shadows to separate elements. The "more options" screen in particular looks really excellent to me. Diplomacy is the one which I like the least, I much prefer the array in the match setup mockup. A final remark: the "number of players" button is overkilled, design-wise. I think it's too small, vertically, to need the gold separators.

nietkb: those warning are actually normal, we're using spidermonkey and thus it supports stuff like "for each" (though I usually avoid it as it tends to be slow). I'll check your patch.

The tiling does look abnormally present here... I'm guessing it's the angle of the picture, at some angle it looks really visible… I'm not sure there's an easy way around it unless we get new animated animations though. Anyhow, really cool settings, Mythos!

nietkb: this is a bit baffling to me. Does qBot work when you start it? Also: I know of no way to reload AIs live.

No real changelog, I've been rewriting a lot of stuffs so I just need to check if anything breaks. The AI is likely less capable than current Aegis at the moment, but that's to be fixed soon. If you need to focus, I'd focus on attacking the AI and see what it does. Edit: okay new version, debug is now off by default. AI learned how to hunt again, fixed some bugs, added some optimizations, and changed a few other stuffs. I'm not sure if the AI is currently strongest on medium, hard or very hard difficulty. Please update to latest SVN, I already committed some non-strictly-AI changes, the patch will only affect the AI folder. edit2: of course the patch didn't apply… Fixed. edit3: Posted the two folders as an archive for the patch-deficients like me. Put the two folders in public/simulation/AI (erasing the current ones) AI.patch files.zip

Yeah, for some reason I decided against that because there is a whole folder that's new. I'll post a diff later today though, because it's not logical thinking. edit: done. edit2: actually I'll crash if you finish any foundation, I'll post a fixed diff later. edit3: should work now. At least that is fixed. AI.patch

Okay, I'm posting the files to the upcoming version of Aegis for debugging. Please note that this will probably not work fully like expected, and please report any weird behavior and any errors. I have not yet put back some optimizations I did for the earlier Aegis, so it'll probably be (slightly) slower too. You will find it under Aegis (wc) in the game menu. It's a bit of a hassle to install, sorry about that. Unzip "simulation/components" in the "binaries/data/mods/public/simulation/components" folder. Unzip "simulation/components/interface" in the "binaries/data/mods/public/simulation/components/interface" folder. Unzip aegis.zip and common-api-v3.zip in "binaries/data/mods/public/simulation/ai" Unzip ccmpAIManager.cpp in "source/simulation2/components". It's needed if you want to activate debug mode (which is currently on by default). You will need to recompile. aegis.zip common-api-v3.zip simulation:components.zip Simulation:components:interface.zip CCmpAIManager.cpp.zip

niektb: common-api-v3 is not really designed to be used without the shared script at the moment (it's a little buggy). You can try setting "useShared": true in data.json, that might fix those errors.

albertus: This is currently a bit of a problem as the AI easy mode is still too strong. There is currently no real "dumb" AIs though you can try playing with testbot. To play with tesbot, go to binaries/data/mods/public/simulation/ai/testbot/, open data.json, and remove the "hidden": true line (you will have to remove the comma at the end of the line before that one.) Testbot should be much easier to play against. If it's still too strong, I recommend you get used to the game without AIs first. Making the easy mode easier is however planned, and there should be an easier AI in Alpha 14.

1. Technically, none. However the common-api (all versions) provide a few custom classes and a few basic functions. A function called "HandleMessage" will be called every turn (with the game state as a parameter, and optionally the shared component). You can check this in the file base.js in any common-api (though v3 uses the shared component which makes this slightly more complicated). 2.Yes, if you can make one work. 3.Because they weren't designed that way. It isn't required.