wraitii

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.

I'd be 100% fine with that. The GLSL support is indeed most likely not perfect and the renderer really could use a bit of work anyhow. Though still, I'd rather see you working on some other things in your to-do list first.

I think this is a legitimate issue that can only be truly solved with hard data: we need to know who doesn't support Glsl "fully" in the 0 AD player base. We're currently only requiring GLSL 1.10. Apparently some semi-old linux machines have trouble with them. If that's not fixable by updating the drivers and the number of people running such machines are high enough (~5/10% of the total), I think we'd have a good reason to keep ARB, despite whatever pain it might be. Secondly, I think that this won't necessarily allow us to do much fancier stuffs in the GLSL shaders because fancier stuff require newer versions of GLSL and OpenGL. Though it's probably much less of a hassle to have different GLSL scripts for different versions than different types of shaders altogether. Finally, I stress that ARB is indeed old, deprecated, and that it's already not up-to-date with GLSL in 0 AD's current codebase. I also agree it adds a lot of code in the C++, I've run into it once in a while and it's not too nice.

Hi Niek, It's good to see new developers interested in the project. AI development is actually very undocumented, as nobody took the time to document it properly (in part because it changes a lot, and fairly often). There are a few things on the Wiki though here. As lead AI developer (de facto), I'm working on Aegis (in the AI file, it's currently qbot-wc). I'm currently rewriting a lot of code on that too, so it's probably best for you not to start with that bot. If you want to get used to the code, check out how qBot works (in the AI files, it's the "qbot" folder, which includes the "common-api-v2" folder). If you have any questions, PM me or try to catch me on IRC (#0ad-dev) (it's not out of place, and there's no real place to ask this unless you want to post a proper application, in the dedicated subforum).

Updating the status. Major features: -we have exponential armor -we could probably get the MP lobby in "shortly". -I think Josh| is working on the Options menu, but I have no ETA on that. -Running/Charging, Capturing Buildings, Trample Damage and conversion seem out of the equation. I think the new music is sort of in. No idea about elephant animations. Bugs: -Ranged units turning bug is I believe fixed. Performance wise; We could probably quickly get in Kuranes' pathfinder patch (perf difference ranging from 5% to 15%, apparently, but it's better than nothing), and the RangeManager optimizations, which would improve that component's speed by about 900/1000%. RedFox wants to commit his shader rework as soon as possible. No idea on possible performance improvement (I mean it's most likely faster, but I don't know by how much). There are several other patches for performance, but those are trickier/impossible to review, which is annoying. Other stuffs: -we have a quite advanced attack notification patch, would be good to get into A14. -we also have a (working, iirc) patch for giving elevated units a range advantage. Might want to commit or not. -indefinite farming is being talked about, as well as regenerative resources, and new fishing behavior. -new corral features are also being talked about. Overall, as we ought to be in feature freeze, I'd say push back. Edit: Ah, also we have several OOS errors with AIs in MP but that'll have to be sorted out when I finish rewriting Aegis' core, which should be possible this week.

Yves, with so much work put into understanding the logic behind Spidermonkey, do you think you could write a (as comprehensive as possible) guide to good JS use in 0 A.D., what to do vs what not to do and things like that? Or is that out of your scope? (obviously after you're finished with this) I'm asking because I haven't really found serious resources about JS optimizations and it really varies form compiler to compiler so having a specific list of "Dos and Don't's" would be pretty cool.

A few you might use (second one might require photoshopping the black lines on the horizon):

Matter of fact, I'd like this: it sounds like a good idea to gradually replace resource gathering. We could task units to the blacksmith to create metal (perhaps with a wood->metal conversion that would be improved by technology?) instead of going to mine. The problem is that this would still mean a huge need for wood, which is quickly becoming a limiting supply in the later game. Not sure what to do against that. Perhaps some kind of "farm" building that would give out wood (start depleted, very slow repletion, can only be harvested when full or something). Obviously the market is another way to replace resource gathering late-game but it's not always usable and I think it would be good to have alternatives. I kind of like the idea of having "specialist" buildings too, but that might make this all too "Anno"ish.