wraitii

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

Do you mean this is the error that appears when you activate the waves?

sounds like I messed something up in my latest SVN commit, I'll check. edit: definitely not getting it, and your latest edit indicate it's pretty weird. Could you repost your mainlog ? edit2: wait, wasn't it with you I already had encountered an issue on IRC? Seems like the same deal.

You shouldn't have that setting with the latest patch, are you sure your SVN is properly updated?

I must say, I'd like that. Could allow to set "strategies: all/rusher/boomer/turtler", or whatever.

Okay, I just committed a fix for the GL errors I encountered. Historic_bruno, Atlas updates should now work, I had managed to forget committing the necessary file. Lion_Kanzen, could you retry, I have made the requirements for water different so you should be able to get it to work. I also removed the "3D waviness" setting leaving only "HQ waviness", I felt it was kind of redundant.

Gave it a listen, it's on Alpha 10. Early criticism: the houses are built reaaaaaally slowly (and I must say, I kinda agree). He also seems to believe that villagers are useless, since soldiers do the same and better (I guess it should be more explicit that farming is faster with females). And he really stresses that. He says it's technically more like AoE3, gameplay-wise more like AoE1 (in a good way, mostly). Then he goes on rambling about himself for a while. He says it's a really good game, but it's good drawbacks. Getting wood and building stuff is slow, so he says the early game is really slow. And he says that not needing barracks is both good and bad, for obvious non-rush reasons. He talks about all buildings. He seemed to have not fully understood the market (apparently he didn't notice you can click on other resources to trade with something else than food.) Says you need a powerful graphic card. Overall I'd say it's a pretty favorable review. @Ludo: moi, du coup. J'suis de Tours, mais en prépa ECS à Paris.

alt-f I believe.