Turret/unit mental retardation
Moderator: Moderators
No, no I just want them to stop blowing each other up. I have a main problem with the units working like this... I'll try to better explain.IMSabbel wrote:smoth, missile turrets may be meant to be used in clusters, against air targets and area denial. And no against ground targets in neat lines.
Their primary target is air, and if you gut about 2 towers space between them in all direction, a band of those will hurt any airforce quite well.
The collision spheres arent optimal, true. But most problems come from the expectation of "they can ignore friendly units" (and yes, i have seen people put tripple rows of missile towers into the gates at castles... they dont deserve better)
If I have a row of towers and an aircraft flies over. several of the towers will hurt one another but we have no option to build every other or every 3 towers. Infantry also move in a large cluster so when they start firing they will hurt one another. That is my problem. I don't want the units shooting themselves and their allies. If they do then the pathing need to acount for that not just move them in a cluster.
I have no problem with say a 3 story building blocking fire for a 20 foot missile tower right behind it.
If you are not going to contribute to the discussion shut up and leave. Again ALL OTHER RTS games do that not just OTA.Min3mat wrote:"the game only has OTA content"
ROFLMAO
and the rest of this entire thread is BS as well! gameplay=realism in this case i hated the fact that in OTA u could fire THROUGH units/buildings X,X
Change default spacing for turrets etc. to be non-zero
I can't help wondering if 90% of the buliding spacing problem would go away if only there was some simple rule like "if the building has a weapon, use a spacing of x, otherwise use a spacing of zero", where x can either be the buliding size, or some fixed spacing applied to all buildings with weapons.
The real solution to this problem is to use spherical (or cylindrical) collision detection as a coarse filter, and then do the actual collision detection on the 3D model of the unit. This would mean e.g. that you could get a laser beam shooting under a units' armpit without hitting it. The problem is that it's much more computationally intensive to do this level of checking - OK for FPS where you have small numbers of units to handle at a time, but not in an RTS where you have hundreds or thousands of units to cope with. Hopefully though, using the spheres (or cylinders) as a course filter will mean that this doesn't increase the load too much, but I can understand the SY's not wanting to implement this in full and then find out that it kills the game speed.
Personally, I think a half way house approach would be acceptable, and hopefully easy to implement - use multiple spheres/cylinders for each unit. This would get rid of a lot of the empty space around units and wrecks, which is currently considered "on target". It would also allow you to record hits to different parts of a unit, so that you then open up the future possibility of handling different parts of a unit being destroyed. For example you might want to make a con-unit's nanolathe very easily damaged, or you could have a k-bot with one leg blown off and imobile, but still able to crawl and fire. Hope this whet's your appetite - and doesn't scare the SY's too much ;-)
As a final point I'd like to add that this aspect of Spring (logical collision detection), flawed though it is, is utterly excellent. If you micro your troops you can often find cover from enemy defensive turrets and make your attacks on an enemy base much more effective: you can sneak round, avoiding the worst of the fire power, whilst you take out the e-storage or windgen farm or whatever.
Just my tuppence.
Munch
Sounds like a really nice and easy-to-make improvement (provided the bounding cylinder is easy to calculate). Gets my vote! most of the friendly fire problem is caused by the fact that spheres spread out side ways from where the unit really is - cylinders would get around this (e.g. try dragging out a line of guardians). Even so, I'd still want to have turrets (all buildings with weapons) spaced apart by default - it's just not very effecient to have them right next to each other - either from a ground coverage point of view, or from a viable firing angles point of view.FireCrack wrote:Cylender colision would work good enough for MT's. We just need to wait...
The real solution to this problem is to use spherical (or cylindrical) collision detection as a coarse filter, and then do the actual collision detection on the 3D model of the unit. This would mean e.g. that you could get a laser beam shooting under a units' armpit without hitting it. The problem is that it's much more computationally intensive to do this level of checking - OK for FPS where you have small numbers of units to handle at a time, but not in an RTS where you have hundreds or thousands of units to cope with. Hopefully though, using the spheres (or cylinders) as a course filter will mean that this doesn't increase the load too much, but I can understand the SY's not wanting to implement this in full and then find out that it kills the game speed.
Personally, I think a half way house approach would be acceptable, and hopefully easy to implement - use multiple spheres/cylinders for each unit. This would get rid of a lot of the empty space around units and wrecks, which is currently considered "on target". It would also allow you to record hits to different parts of a unit, so that you then open up the future possibility of handling different parts of a unit being destroyed. For example you might want to make a con-unit's nanolathe very easily damaged, or you could have a k-bot with one leg blown off and imobile, but still able to crawl and fire. Hope this whet's your appetite - and doesn't scare the SY's too much ;-)
As a final point I'd like to add that this aspect of Spring (logical collision detection), flawed though it is, is utterly excellent. If you micro your troops you can often find cover from enemy defensive turrets and make your attacks on an enemy base much more effective: you can sneak round, avoiding the worst of the fire power, whilst you take out the e-storage or windgen farm or whatever.
Just my tuppence.
Munch
Well, i dont think cylindrical would be that great, because it really only fits to 2 or 3 towers.
If there is an improved collision model, than it would be wise to just go to bounding box(es).
Even a single box will be much better for most units (for eample, look at a big bertha and its _huge_ bounding sphere. A single box could be rotated with the turret and be half the volume of the sphere).
Also this would be much better for everything allready in box-format (like tanks :) ).
Those algorithms are very well researched and shouldnt be too slow...
If there is an improved collision model, than it would be wise to just go to bounding box(es).
Even a single box will be much better for most units (for eample, look at a big bertha and its _huge_ bounding sphere. A single box could be rotated with the turret and be half the volume of the sphere).
Also this would be much better for everything allready in box-format (like tanks :) ).
Those algorithms are very well researched and shouldnt be too slow...
Well, i can agree on your case about missile towers that hit their neibors BESIDE them, eveing if they are aming foward.No, no I just want them to stop blowing each other up. I have a main problem with the units working like this... I'll try to better explain.
If I have a row of towers and an aircraft flies over. several of the towers will hurt one another but we have no option to build every other or every 3 towers. Infantry also move in a large cluster so when they start firing they will hurt one another. That is my problem. I don't want the units shooting themselves and their allies. If they do then the pathing need to acount for that not just move them in a cluster.
I have no problem with say a 3 story building blocking fire for a 20 foot missile tower right behind it.
And i've seen rare cases of units aculy hitting each other, never thougt that it's that big an issue.
The best would be if the units checked if they where gonna hit their ally better. Maybe the unit must aim THIS much distance from an ally unit. But the problem with that is that most of the time, balistic units won't fire since their ally is in the way!
I don't agree that units should be babysitted to walk better. If you want em to walk spaced out, you can use the Ctrl or the Alt command.
Cool it.Min3mat wrote:
"the game only has OTA content"
ROFLMAO
and the rest of this entire thread is BS as well! gameplay=realism in this case i hated the fact that in OTA u could fire THROUGH units/buildings X,X
If you are not going to contribute to the discussion shut up and leave. Again ALL OTHER RTS games do that not just OTA.
Who decides what contibuating? The only thing that's really not contiuating to the discusion is a blank post. that post contribud with another one who dosen't like the ''ota way'' of collsion detection.
Oh, and just becuase of every other rts did it, dosent mean that the way is right, yes? Just meant that they did'nt have a good enought phycis model to implent good balaistic values and so on. Look at starcraft. It's fun, but it defys about 10 laws of nature. That dosen't make it into a bad game, nor does it make it's way of colision detection right.
And rts's are suposed to be diffrent. Why else would play em?
Spheres, cylinders and bounding boxes.
Actually I think that both cylinders and bounding boxes give a comparable level of improvement over spheres. They both get rid of the silly bulges at the side, which no unit has, and they both allow for height to be altered independent of width, so that you can have tall thin units like freakers, MTs and LLTs and also short fat units like tanks, wrecks, metal storage, solars.IMSabbel wrote:Well, i dont think cylindrical would be that great, because it really only fits to 2 or 3 towers.
If there is an improved collision model, than it would be wise to just go to bounding box(es).
Even a single box will be much better for most units (for eample, look at a big bertha and its _huge_ bounding sphere. A single box could be rotated with the turret and be half the volume of the sphere).
Also this would be much better for everything allready in box-format (like tanks :) ).
Those algorithms are very well researched and shouldnt be too slow...
Agreed that a box would be better than a cylinder, which would be better than a sphere. It's just about adding more degrees of freedom to the collision detection. The point is that going to a bounding box is not a trivial code change, but going to a bounding cylinder is and it should give a big improvement over a plain old sphere.
Contrary to the belief expressed by Weaver about "made on the fly" spheres, the whole point about doing spherical collision is that you don't have to make anything - the sphere just drops out of the maths for free. The wire frame sphere's you see in debug mode are drawn artificially - they're not actuall game elements.
The way you do spherical collision detection is simply by asking "how close is projectile P from the position of unit U"? Each unit has a fixed size R. If the projectile is closer than R then it has hit that unit, if it is further than R then it hasn't. That's it. No need to go calculating the sphere - it just happens that if you use this "how close is it" algorithm you end up with a sphere. Finding out the distance between any two positions is therefore a single line of code. Here's the psuedo-code:
Code: Select all
distance = sqrt((x1 - x2)^2 + (y1 -y2)^2 + (z1 - z2)^2)
Code: Select all
2Ddistance = sqrt((x1 - x2)^2 + (y1 -y2)^2);
verticalDistance = abs(z1 - z2);
Code: Select all
collision_detected = (sqrt((x1 - x2)^2 + (y1 - y2)^2) < unit_width)
AND (abs(z1 - z2) < unit_height);
The main point about both spheres and cylinders is that they are approximations which work independent of the unit's orientation. All you have to know is the unit's position, and its size (expressed as either one or two parameters). The problem with anything more complex is that you need to keep track of which way the unit is facing and even which way it's weapons are pointing, in order to get the bounding box right. Not only that but you're no longer talking about a line or two to calculate if the shot is within the bounding box.
I hope this explains why cylinders are a great idea given the level of improvement we would get for relatively little effort.
Cheers
Munch
Well no thats not a bad idea Torrasque. Use the sphere/cylinder as basic collision detection, with the more complex bounding box, per polygon or whatever detection if it collides with the sphere/cylinder. Of course, this will add some extra load to the CPU, having to (occasionally) do collision detection twice, so this might not be very desirable, but its worth a shot.
Bounding boxes for buildings only - cool =)
Actually it's an utterly brilliant idea. It should in fact reduce CPU load. Here's why: TA has this quirk - you can't rotate buildings, they're always built alligned to the "game grid" and they're always built bolt upright, even if you build them on a slope. That means you can skip the pythagoras you need to do the bounding sphere, and just go straight to checking the bounding box, like this:Torrasque wrote:Hum, for building collision, would it be possible, once we know we are in collision with the sphere, to check if we are over the footprint?
It must be easy to detect..
Like that, we have go a sort of rectangle.
Code: Select all
collision_detected = (abs(x1 - x2) < building_width)
AND (abs(y1 - y2) < building_length)
AND (abs(z1 - z2) < building_height);
Cheers
Munch
First of all, those missile towers were designed as cheap spamming towers, if they arn't that in XTA, fine, but we'll need to find a solution for propper OTA mods... maybe another weapon type that can shoot through friendlies or maybe balistic style missiles.
EDIT:
EDIT:
Well... Apparently MTs ARE supposed to be spam buildings in XTA too, more so even then in OTAhttp://www.clan-sy.com/frame.html wrote:MTs are nearly unchanged, except they are smaller so that you can fit more of them into the same space.