Re: Random WIP
Posted: 28 Feb 2010, 22:08
Not the same
Open Source Realtime Strategy Game Engine
https://springrts.com/phpbb/
...yes.FLOZi wrote:http://flozi.pwp.blueyonder.co.uk/spring/video.avi
(ffdshow, in case you were wondering, AF)
I guess it's pretty obvious what the idea behind this is.
I should point out that they aren't actually stuck together right now; though I've done that previously with other units. There are a few different ways of doing it, I'm still mulling over which is the best method for what I want to achieve. I just did it this way quickly so I could use the existing unit_hilite widget to test how feasible targeting the pieces would be.MidKnight wrote:...yes.FLOZi wrote:http://flozi.pwp.blueyonder.co.uk/spring/video.avi
(ffdshow, in case you were wondering, AF)
I guess it's pretty obvious what the idea behind this is.
Yes!
YES!!!!
HAHAHAHAHAHAHAHA!
Wonderful, good sir! You will be a celebrated figure! Your legend will never die!
Nice job!
Box collision volumes, layered like a cake. I'm having difficulties with getting weapons to not just 'hit' all three at once though, even with minimal collisionSize and AoEBeherith wrote:AF, your the only one who cant, or doesnt want to open these videos.
It takes me exactly 1 click to open it, and it doesnt even navigate away from the page. Set up your system to autoplay videos you download and stop pushing useless stuff (since you cant embed it into forum anyway <thank god>)
flozi: how do you handle the separate hitspheres?
why not just upload, the more videos of spring are on youtube the better the promotion...Beherith wrote:AF, your the only one who cant, or doesnt want to open these videos.
It takes me exactly 1 click to open it, and it doesnt even navigate away from the page. Set up your system to autoplay videos you download and stop pushing useless stuff (since you cant embed it into forum anyway <thank god>)
flozi: how do you handle the separate hitspheres?
I dabbled with that and it didn't seem to help much. Also there appears to be a bug with it in alt+b mode, if it gets hit once it stays red so you can't tell easily if subsequent hits, hit. Isn't there a performance concern of using that on a large number of units? Oh, also, the bounding box for each piece also bounds all of its children, so the bounding box of the root piece bounds the whole model, is that intentional? What difference is there then to just having a single bounding box?Kloot wrote:You could enable the (so far unused, AFAIK) per-piece collision detection system on each of the units-acting-as-pieces for more fine-grained control over that aspect.
Thanks, I'd forgotten to fix that. It happens because the last-hit piece is never reset.FLOZi wrote: Also there appears to be a bug with it in alt+b mode, if it gets hit once it stays red so you can't tell easily if subsequent hits, hit.
There is; it would probably be too expensive if those tanks are anything like *A Flash in spammability. (Note: so far I haven't done any large-scale profiling runs.)Isn't there a performance concern of using that on a large number of units?
Intentional. Models can vary a lot in piece-tree complexity and since the root piece is only guaranteed to bound all of its children for a model's default pose, I thought it was better to leave disabling collision detection for the root and/or other pieces (which can be done via the SetUnitPieceCollisionVolumeData Lua callout) to the discretion of game devs.Oh, also, the bounding box for each piece also bounds all of its children, so the bounding box of the root piece bounds the whole model, is that intentional? What difference is there then to just having a single bounding box?
It's a good start and shows that you're working hard, but it's really obvious that it's a bunch of primitives that have been stretched... even if that isn't what you did, it's what it looks like. Too many pieces are just simple bricks, making it look like it was built out of Lego Technic.oksnoop2 wrote:What do you think of this?
*img snipped*
More Views
http://img20.imageshack.us/gal.php?g=agrof.png