vts

Hi! The game becoming slow after a while is a known problem, primarily due to pathfinding and AI computation costs. See this thread: http://www.wildfiregames.com/forum/index.php?showtopic=15796

Officially Mythos-approved:

Nice! How many hours in paint?

Hi Andrea, That sounds very interesting! I'm not very knowledgeable about AI myself, so I'd be eager to see how this plays out As I'm sure you've noticed we've got a couple of bots in the making already; there's been some talk recently about joining efforts to move to a single definitive AI bot, but I'm not sure what stage those plans are at this time (I'll have to defer to the people directly involved for that). Nonetheless, I don't think that should stop you from being able to create a separate bot, and although I don't know how the current bots work, I suspect they'll find it interesting to see how yours does. Out of curiosity, if this is your master's thesis, how are you being mentored? I ask because your faculty is presumably not very familiar with our codebase to help out should you run into trouble, so you'll probably have to do quite some digging around in the code yourself. Also, the dev chat is most definitely open for everyone. Come hit us up on #0ad-dev @ quakenet!

Your file is hosted on a russian host and is called "don't open.avi" ...

This already happens for the construction of the foundations, so I don't see why it wouldn't be possible for repairs as well

Hi LTGoldman, This is indeed a feature that has long gone unimplemented. We're working on an implementation right now though, so it shouldn't be very much longer until we have a usable wall building system in place

Hi! Would you still happen to have those crashlog.dmp and crashlog.txt files so we can investigate the cause of the crash?

Should be fixed now in revision 11360

These messages are harmless. They were added in revision 11342 as part of a crashfix to warn to modders that something is wrong in their XML templates. To make sure we don't run into the crash again in the future, I added a testcase for it, which is why you're seeing them in the output. I'll see if we can suppress them somehow.

Looks fixed for me. * EDIT: the error reported by feneur I mean, I haven't seen OP's error occur yet

Dutch, English, French and a little German here. Yay for living in a trilingual country!

I'm quite confident that the particle emitter bounds are computed correctly; I remember inspecting them during the selection box update. I believe that update also added a method to grab a recursive version of a model's box (before that I think the bounds didn't include props recursively), so perhaps there's still an old call to the non-recursive version lingering somewhere in the projectile code. I'll have a look and see if it's an easy fix. * EDIT: committed r11062, try again now.

Hi! I don't seem to be on the list Pureon also seems to be missing? *EDIT: Too late ^^

You don't, it trips up my Eclipse instance as well. It's because the for each (var foo in bar) syntax is new in JavaScript 1.6. I suppose we'll just have to live with it until WTP gets updated to deal with JS 1.6.

Another thing I noticed: the engine is called pyrogenesis, not pyrogenisis Other than that, looks promising! Gonna be interesting to see what you make of it

You can also check out the git version from https://github.com/0ad/0ad. It has the autobuild binaries excluded and ignored, so that you can go nuts with custom builds without it complaining about conflicts in the binaries. One thing to keep in mind if you're on Windows is that recently the AtlasUI and Collada DLLs were also removed from the git repository (to prevent the same kind of conflicts for developers who are working on Atlas), so the first time you'll have to make sure to do an Atlas build (pass the --atlas argument to update-workspaces) K776 is in charge of keeping the git repository in sync with the SVN repo; I don't think it happens automatically, but I've never seen a delay of more than a few days, so it's not too bad.

Happy to hear it got fixed Inspecting the solution gave me a chuckle -- these kinds of bugs are so easy to write yet so hard to find, going back as far as ticket 99. Good thing you found it!

I'm not sure if I fully understand what you mean exactly, but I think that's basically the system we currently have, where we just have OpenGL draw a circle. The reason why we're changing it is because we want to be able to use textures for the selection outlines.

Well, colour me thoroughly impressed. The amount of work you've done in this timespan is nothing short of extraordinary. Can't wait to see what the future brings

Currently the dashed lines are used to hide the rally point's path inside the shroud of darkness. What would you suggest to use for that instead if dashes are already used inside a player's own territory? As for the minimap, I agree -- displaying rally points on the minimap would be very useful as it would allow for faster navigation than following the line on the map. What kind of visual indicator do you suggest for that?

How would this be specified to the engine? Then maybe I can read that setting and take it into account.

Well I haven't actually gone around creating any fancy textures because all that seems to be needed at this point are basic rectangles and squares. But to give you an idea, I've attached some of the textures that are currently being used: a 42x42 circle and its mask, and a 36x72 rectangle and its mask. It's hard to see against a white background, but they consist of a 2px black outline of the shape, enclosed in a 1px white border. The black outline is where the player color is applied in-game, and is matched by the mask texture. You'll notice that, to achieve pow2 dimensions, the 42x42 circle is enclosed within a 64x64 image and the 36x72 rectangle is in a 64x128 image with transparent filler on either side. This is probably easier to see on the masks though, as all the filler is of course also masked out.

Sure, any shape you like.