-
Posts
110 -
Joined
-
Last visited
-
Days Won
2
Posts posted by vts
-
-
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" ...
- 1
-
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
-
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!
-
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.
-
Hi! I don't seem to be on the list Pureon also seems to be missing?
*EDIT: Too late ^^
-
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.
-
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.
-
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!
-
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.
-
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
-
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?
-
I believe walls, wall towers, and gates will not flatten ground.
How would this be specified to the engine? Then maybe I can read that setting and take it into account.
-
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.
-
Yeah I noticed that. I guess what I was asking was... can you do rectangles and ovals?
Sure, any shape you like.
{SOLVED} Game becomes slow and choppy after about 10-15 minutes...
in Help & Feedback
Posted
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