Jump to content

vts

WFG Retired
  • Posts

    110
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by vts

  1. 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!

  2. I think units just automatically moving from wall segment to wall segment to repair them should, well, be automatic. Doesn't seem to me to be something that should be unlocked. Should just happen from the beginning of the game.

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

  3. We compute bounding boxes of particle emitters correctly (I think), and treat them like any other prop on the model. The problem might be that we ignore the bounding boxes of all props when deciding to cull a unit during rendering (and if the unit is culled then no props are drawn). That should be fixed to either use the correct bounding box, or to cull and submit each prop model independently.

    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.

  4. As for not working with standard conventions, the big thing that throws Eclipse for a loop is your implementation of "for each" loops. Usually, and according to Eclipse, a for each loop is implemented as "for(var x in array)" but in 0 A.D. it is implemented as "for each(var x in array)", which is why I'd turn off debugging in Eclipse... I don't want to be buggered with 300 error messages because of small things like that. Unless I have an outdated version of Eclipse and an outdated memory of Javascript syntax O.o

    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.

  5. 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.

  6. This error has always existed, but it was not noticeable with narrower FOV (about 1.7% error at 20 degrees FOV, compared with 10% error at 45 degrees, it gets worse the wider you go). Only the horizontal (x) coordinate was affected and you would notice it especially in the far corners of the game view.

    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!

  7. I don't know anything about graphic stuff, but i was wondering if there isn't some way to calculate how the circles should be positioned on the ground and just throw it on the screen at the correct (pixels?) location? Please don't pay much attention to this post, as i'm totally layman on this subject.

    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.

  8. I like the rally point to be dashed line with in the territory and a solid line outside own territory.

    Also it would be better they shown in miimap too.

    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?

  9. Could you show us one or two examples of the texture files?

    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.

    post-12941-0-82577900-1318264566_thumb.p post-12941-0-22979200-1318264575_thumb.p post-12941-0-50806100-1318264736_thumb.p post-12941-0-07376700-1318264746_thumb.p

×
×
  • Create New...