wraitii

The theory behind elevation map is sound, and there are no "problems" in itself with it. However, any map plane must have its own refractions/reflections rendered, which is expensive (refractions might be done in one pass, reflection cannot). Furthermore, the code isn't currently done for it. However, I believe it could be added at some laaaaate point in development.

My internet is giving me a little trouble, could you reupload the image in JPG or something?

Done for me too. The game has really become playable this year, and it's been amazing.

Hadn't heard the second one in a while...

I wish for Rise of Nations 2. Still the most awesome RTS I played. The only one easily moddable, too.

WhiteTreePaladin: That's not supposed to be normal, however I've changed the settings to force the use of the fixed fucntionon some graphic cards, which might just include the HD 2500. I guess it could be changed.

Yeah, I encountered the "shadow object" possibility, where something could make a GC-ed object actually reappear as the memory was still there. But I doubt your problem is linked to that.

If I understand it correctly, str is a global c++ variable where you store some text in function 1 using ConvertArguments. I believe this copies the value to a new memory address, ie str and "textfromscript" are not pointing to the same memory address. Which means that even after a GC that should destroy textfromscript, str still points to the correct text, and thus function 2 can access it. It doesn't seem related to the GC. The question is whether ConvertArguments actually copies the variables, but I'm assuming yes. (edit: str is actually defined twice in your code, both as a global variable and a local one in "main", which might mess things up...)

Okay, latest version for the time being. More streamlining, I redid the defense manager so hopefully now it works about properly. Early naval support: the bot will try to attack you over sea (won't do anything else with its dock though). May bug, but it should mostly work. A few other things have been fixed or improved upon. The procedure has slightly changed, so take care. historic_bruno: I've fixed a crash that sounds very similar to yours, could you try again?

There should be no additional lag for water getting deeper or not… I'm not too sure about these kind of things, but you may want to ask Myconid, such a bad lag sounds really not normal.

I noticed the decal vanished pretty suddenly... it'd be worth it to spend some time making them vanish in a more interpolated way before deleting them.

I can't seem to be able to reproduce any of those, though I recall the first one happening to me at some point… I'll post a new version today, I think, could you try then if they still appear?

That's my recent changes. I'll change it, I had done that to avoid problems (I encountered a bug when doing differently, but it ended up being unrelated to this code). Edit: okay, changed the logic, the warning should not appear anymore. And no, there are 3 cases: both reflection and refraction, reflection only, refraction only. The "both" case I had made a mistake on and so it appeared similar to one of the others.

A plank in front, with a visible opening would probably do the trick. Small concern: your ship would never float that way, your renderings have the water line way too low, and it might have some effect on the mesh itself, you should try with a higher water line how it looks.

Just posted a new version. Fixes a few fairly critical economic/attack bugs, and also allows retrocompatibility: qBot will now work (you'll get a small warning but I'll fix that).

Your fix seems clean and it looks like it's working for me (I build strictly non-bundled, though), so I'd say this one has been sorted out.

Perhaps one of the 'spikes' in the middle of the dock could be bigger than the others.

From what I understand, this would also be used in the simulation code to calculate things when shooting. It seems to me like this makes more sense as a new (optional) component for each entity.

Yup. I just updated the AI.7z archive with a new version that should fix most of the defense bugs, and perhaps some weird stuffs in attack. Should also allow the AI to reach city phase, there was an issue with a recent change.

Might be me, but given how the other Mauryan buildings look, this temple feels a bit too "simple". Could be texture-fixed though I guess.

Geek: not quite yet more powerful, this is still a beta, I know for a thing it'll bug here and there . Particularly in the defence, I'll probably post an updated script for that at some point of the day. @Lion: this means you have to run the script "update-workspaces.sh" and that you must recompile your game. Edit: I'm not quite sure what I've done yesterday, but the AI seems to run really fast right now.

I moved it for you, if you have some information about "position", someone could change the title of your post too.

Just so I know... This new shader causes hardware issues for some people who don't have the hardware to run it, but they probably don't know why, and this is going to cause bug reports when Alpha 12 rolls around. I believe I should try to add some sort of quick check/limitation to the parameters, however: I have no way to tell users that it's because of their hardware that they can't use feature X or Y. Furthermore, I don't believe I can deactivate a ticking box?

Given the state of the animation system, an overhaul might not be a too bad thing... From what I understand, it's basically making a ton of stuff originally wanted impossible. (Then again, this goes toward pushing the release date further away. We need an update on what we want)

Alright, in the interest of speeding AIs up, and for setting new groundworks before further development, I've been for the past 2.5 months working on some new AI API. It's mostly done by now, and I'm beta-testing it. In this interest, I'm posting the WIP version here so anybody can try it. The installation process is kind of tedious and requires being able to compile, sorry. (edited as of 11/11/12) This implements an (optional) shared component between AIs, mainly to speed them up but also to try reducing their memory signature. It also include the latest version of Aegis. I've rewritten the defense system to be faster, and have found Aegis to be generally slightly faster than qBot. It's also usually more efficient (though the defense could use some work in that aspect, it's not yet perfect). it includes a very basic setting for difficulty in config.js. The AI and the v3 API also support technologies to some extent. Aegis will go up in phases (it's currently the only tech it researches, though). It will also try to attack you over water by transporting units in ship. Retrocompatibility is assured: you can start a game without using qBot only, or even no AIs, or a mix between qBot and Aegis bot (one using the shared component, the other not). The memory heap has been reduced to a maximum of 24 MB, and the garbage collection made slightly more efficient in particular right before Aegis starts a pathfinding, so you should get fewer OOM errors. Procedure to test: Go to binaries/data/mods/public/simulation/components/interfaces, erase the "TechnologyTemplateManager.js" file. Put the files from "Simulation.7z" in source/simulation2/components/ . These files replace older ones. Put the files from "AI.7z" in binaries/data/mods/public/simulation/ai/ (replace the existing files, don't combine them). Apply the patch. Run update-workspaces. Recompile. Run the game and choose "Aegis Bot". PM me for mor information. AI.7z API3.patch Simulation.7z