Rotate, stackable, footprint, collision
Moderator: Moderators
Rotate, stackable, footprint, collision
These are some requests that I have that are very important to me:
* Unit selections rotate with the unit, with ability to specify a unit to turn around (broadside attack etc.) (<<<LUA?)
* Units can be on top of each other, with dynamic space requirements (a long-legged bot could have small bots underneath it, able to pass underneath it
* Rotatable feature footprint, rotating footprint for units that is maybe not always square. This would fix the problems with long units and allow for longer units to work better.
*Custom collision shapes. Need I say more?
I would really appreciate any comments on how this applies to lua etc., and if it is already feasible and I dont know it.
Thanks for taking a look.
* Unit selections rotate with the unit, with ability to specify a unit to turn around (broadside attack etc.) (<<<LUA?)
* Units can be on top of each other, with dynamic space requirements (a long-legged bot could have small bots underneath it, able to pass underneath it
* Rotatable feature footprint, rotating footprint for units that is maybe not always square. This would fix the problems with long units and allow for longer units to work better.
*Custom collision shapes. Need I say more?
I would really appreciate any comments on how this applies to lua etc., and if it is already feasible and I dont know it.
Thanks for taking a look.
Re: Rotate, stackable, footprint, collision
* Unit selections rotate with the unit, with ability to specify a unit to turn around (broadside attack etc.) (<<<LUA?)
What are you talking about? Formations or something?
* Units can be on top of each other, with dynamic space requirements (a long-legged bot could have small bots underneath it, able to pass underneath it
You might be able to do that with a 0x0 footprint, if you give it a normal movetype. (is movetype the term? meh, too lazy to check)
* Rotatable feature footprint, rotating footprint for units that is maybe not always square. This would fix the problems with long units and allow for longer units to work better.
It basically requires massive changes to the pathing engine. *shudder*
*Custom collision shapes. Need I say more?
kloot is working on this. (I think it was kloot)
What are you talking about? Formations or something?
* Units can be on top of each other, with dynamic space requirements (a long-legged bot could have small bots underneath it, able to pass underneath it
You might be able to do that with a 0x0 footprint, if you give it a normal movetype. (is movetype the term? meh, too lazy to check)
* Rotatable feature footprint, rotating footprint for units that is maybe not always square. This would fix the problems with long units and allow for longer units to work better.
It basically requires massive changes to the pathing engine. *shudder*
*Custom collision shapes. Need I say more?
kloot is working on this. (I think it was kloot)
Re: Rotate, stackable, footprint, collision
The second is the answer to the first!! Otherwise Collision spheres would need to be added to that long-legged bots legs!lbctech wrote: * Units can be on top of each other, with dynamic space requirements (a long-legged bot could have small bots underneath it, able to pass underneath it
*Custom collision shapes. Need I say more?
Re: Rotate, stackable, footprint, collision
Nope, hitspheres and footprints are entirely separate.Pendrokar wrote:The second is the answer to the first!! Otherwise Collision spheres would need to be added to that long-legged bots legs!lbctech wrote: * Units can be on top of each other, with dynamic space requirements (a long-legged bot could have small bots underneath it, able to pass underneath it
*Custom collision shapes. Need I say more?
Basically, Im whining for a 3d dynamic collision map. Pretty much something that matches a unit's model exactly, including the animated and moving parts. However, even a 2d one that is dynamic would be useful. If such a thing would be possible, the current paths engine should be tested with it. I am not 100% what kind of algorithm is used, but from skimming the code, i would imagine that this would (almost) work smoothly. The reason for a dynamic collision map is that legs move. However, on this point, can a collision map have basically this shape (looking down):
where the #'s are where collisions can occur. Basically, there are two blocked areas, where the legs would be (think 6-legged insect or whatever comes to mind, monkeylord). Units could be underneath in the area between the legs. Is this 2d collision map that kdr speaks of the footprint? If so, then for pathing, just making footprints that have holes in them would treat the big units with holes in its footprint as a solid footprint, and other units would treat the footprint as two separate entities. In order for this to work, though, footprints would need to rotate with the unit. I dont care if footprints have to be rectangles (that much), they could be ellipses for all i care (is this a solution?). They have to rotate with the unit as the unit turns. This would fix the long ship problem.
Iirc I may have seen a post or a demo of those custom hitspheres. Is this a patch? If a unit had no footprint (does this work with the pathing?), and it could have multiple hitsperes, these could be scripted to follow the animation of a unit, and essentially achieve the dynamic 3d collision map of which I spoke earlier. Multiple hitspheres would also partly eliminate the need for custom hitsphere shapes, as you could just make a similar effect with lots of hit spheres. Multiple hitspheres does not sound like a hard solution. In fact, it is probably the easiest way to change the engine to do what I want.
Finally, a big thing that bothers me is that features that can be built need to have a rotatable footprint (when [ and ] are used). This eliminates the need for "ns walls" and "ew walls". A long wall could be just one unit that could be rotated to do what you want. My personal solution to this is to make square wall segments like in TA, but other people do not like this, and when I use mods that have long walls and I rotate them by accident, I have strange pathing issues (with the unrotated footprint with nothing there) and units going through walls.
Code: Select all
Front
### ###
### ###
### ###
### ###
### ###
Iirc I may have seen a post or a demo of those custom hitspheres. Is this a patch? If a unit had no footprint (does this work with the pathing?), and it could have multiple hitsperes, these could be scripted to follow the animation of a unit, and essentially achieve the dynamic 3d collision map of which I spoke earlier. Multiple hitspheres would also partly eliminate the need for custom hitsphere shapes, as you could just make a similar effect with lots of hit spheres. Multiple hitspheres does not sound like a hard solution. In fact, it is probably the easiest way to change the engine to do what I want.
Finally, a big thing that bothers me is that features that can be built need to have a rotatable footprint (when [ and ] are used). This eliminates the need for "ns walls" and "ew walls". A long wall could be just one unit that could be rotated to do what you want. My personal solution to this is to make square wall segments like in TA, but other people do not like this, and when I use mods that have long walls and I rotate them by accident, I have strange pathing issues (with the unrotated footprint with nothing there) and units going through walls.
Re: Rotate, stackable, footprint, collision
I had the exact same thoughts as you when I first saw the problem you describe. But the problem with proper collision boxes is, as I understand it, "what happens when a 1x10 unit enters a 1x500 tunnel". It can't turn around. There's no practical solution so I don't think it makes sense to worry about something like that right now.
I think nonsquare footprints would be nice in some kind of fantasy world, but real hitboxes are the holy grail right now. AFAIK no game of any genre has done a proper implementation of nonsquare footprints. You see it in FPSs all the time, your gun goes right through the wall... there's no practical solution besides not allowing you to turn when you're going to clip - which would suck - or making a 1x10 unit have a 10x10 footprint. There's no reason to do things differently or think that we can be heroes and invent a way to do this when the entire games industry for the last 10 years has been struggling with the problem and hasn't come up with a solution.
On the other hand, every game since Quake or something has had proper hitboxes, so now in 2008 I think it's not a stretch to say it's common technology that this engine should have had a long time ago.
Collision spheres are OK. I'm playing with them in GEM - where 1x10 ships are common - and it's not such a big deal. In the real world you wouldn't pack your tanks or ships or boats or whatever so close together than they couldn't turn in an emergency... it would be like how they would shoot the first and last tank in a column during WWII and then pick off the survivors at their leisure.
It doesn't make sense from a game or real-world standpoint, so there's no reason to waste time on a feature that if it was working perfectly would for a certainty harm gameplay. Can you imagine a bunch of Millennium battleships trying to maneuver around when there's a bunch of them in a group and they didn't have square/round collision? Bad idea, bad idea...
I think nonsquare footprints would be nice in some kind of fantasy world, but real hitboxes are the holy grail right now. AFAIK no game of any genre has done a proper implementation of nonsquare footprints. You see it in FPSs all the time, your gun goes right through the wall... there's no practical solution besides not allowing you to turn when you're going to clip - which would suck - or making a 1x10 unit have a 10x10 footprint. There's no reason to do things differently or think that we can be heroes and invent a way to do this when the entire games industry for the last 10 years has been struggling with the problem and hasn't come up with a solution.
On the other hand, every game since Quake or something has had proper hitboxes, so now in 2008 I think it's not a stretch to say it's common technology that this engine should have had a long time ago.
Collision spheres are OK. I'm playing with them in GEM - where 1x10 ships are common - and it's not such a big deal. In the real world you wouldn't pack your tanks or ships or boats or whatever so close together than they couldn't turn in an emergency... it would be like how they would shoot the first and last tank in a column during WWII and then pick off the survivors at their leisure.
It doesn't make sense from a game or real-world standpoint, so there's no reason to waste time on a feature that if it was working perfectly would for a certainty harm gameplay. Can you imagine a bunch of Millennium battleships trying to maneuver around when there's a bunch of them in a group and they didn't have square/round collision? Bad idea, bad idea...
Re: Rotate, stackable, footprint, collision
I'd like non-sphere hit primitives though, it's pretty important for accuracies from various directions.
Re: Rotate, stackable, footprint, collision
Probably you haven't played Blitzkrieg (first one, I'm not sure if this is still so in Blitzkrieg II). Units there had non-square footprints and could easily be unable to turn in a tight space (between trees or other units) so they had to move some distance in their current direction to reach a clear area. Of course, that caused countless 'traffic jams' some of which required player's attention to resolve (pathfinder was unable to sort them on its own). Pathing there was quite interesting though, units could backpedal a little if that would bring them to destination faster that turning around.Caydr wrote:AFAIK no game of any genre has done a proper implementation of nonsquare footprints.
Re: Rotate, stackable, footprint, collision
many games do not even use footprints.
Re: Rotate, stackable, footprint, collision
Something that would be nice is, if a unit hits an obstacle that is moving, it doesn't start twitching around like a retard, but instead just stops/deacellerates/getspushedaway a little bit. Currently when you have some units moving around they behave like children with extra chromosomes.
- Pressure Line
- Posts: 2283
- Joined: 21 May 2007, 02:09
Re: Rotate, stackable, footprint, collision
i laughed. a lot. does that make me a bad personZpock wrote:Currently when you have some units moving around they behave like children with extra chromosomes.
Re: Rotate, stackable, footprint, collision
no, it was just a subtle joke. Well, i see what u mean guys. However, I still like the idea of a square footprint with an open "tunnel" in it where units can pass under the bigger unit, as I said in my last post. Forget the non-square footprint stuff. btw, is this "yardmap"?
- DandyGnome
- Posts: 61
- Joined: 25 Jun 2007, 06:43
Re: Rotate, stackable, footprint, collision
Yes that is yardmap, but I believe that is only for stationary buildings. I have a nasty suspicion that putting yardmap in a mobile unit will make it not move or worse. Of course I could be wrong about that.
Re: Rotate, stackable, footprint, collision
err you haven't played crysis?Caydr wrote:You see it in FPSs all the time, your gun goes right through the wall... there's no practical solution besides not allowing you to turn when you're going to clip - which would suck - or making a 1x10 unit have a 10x10 footprint.
when running up to the wall, the character pulls the gun in and points it up instead of pushing it into the wall
Re: Rotate, stackable, footprint, collision
Crysis sales where disappointingly low apparently.
Re: Rotate, stackable, footprint, collision
NE1 experimented with yardmap on mobile units?