Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Flipside on September 25, 2003, 05:05:47 pm
-
Just one little question, which I am certain has been asked before, is there any way the SCP can get turrets to draw a Line of Sight to targets so they don't shoot through the hull of the ship they are mounted on? Originally I thought it might be a good idea to be able to define fov more accurately (values for multiple axis to allow 'shaped' fovs) but I just realised that this would mean changing the POF file, as this is where these details are stored.
Flipside :D
-
I'll support this - turrets shooting through their own hull just looks very silly! :D
-
I think it's just some creative work on the part of the modeler, to ensure he specifies a correct normal and FOV. Blame them, not the coders.
-
Originally posted by GalacticEmperor
I think it's just some creative work on the part of the modeler, to ensure he specifies a correct normal and FOV. Blame them, not the coders.
Obviously the modder is to blame if a turret shoots through the side of the ship. However it would be nice if the modder could just specify 180 as the field of view and the game would take care of deciding what can be hit.
The problem is that suppose I have a ship with something directly above and below the turret but nothing to the sides. At the moment I'm forced to limit the field of view so the ship doesn't shoot through itself but that also means that the turret sometimes can't hit things that are at the side that it should be able too.
That said we can't get rid of fov completely or weapons like the mjolnir would cease to work properly.
-
not to mention the total conversions, where you are forced to put turretts in specific points where they will have fov partially occluded by the hull. Fov occluded by the hull could have also a sense in other situations, for example if you want to create a blind spot in a capship defenses (thought you can do it working with the fov)
-
Hmm, I might look into this. We're having a holiday thingy today and tomorrow, but I will prolly have time on Sunday. I don't think it should be too hard, actually.
-
Sounds like a frame rate massacre to me.
-
Originally posted by Fry_Day
Hmm, I might look into this. We're having a holiday thingy today and tomorrow, but I will prolly have time on Sunday. I don't think it should be too hard, actually.
Shana Tovah, achi! ;)
-
Originally posted by GalacticEmperor
I think it's just some creative work on the part of the modeler, to ensure he specifies a correct normal and FOV. Blame them, not the coders.
No it's ****ing well not our fault. You seen my carrier? Probably not, no-one gives a flying giraffe's testicle about my TC, but the bridge superstructre has a two-part turret behind it. Unless I give it a FOV of about 10 degrees around the vertical normal, it can and will shoot right through the superstructure hull. And this is just one example.
Sorry for shouting, but you touched a nerve on that one.
-
for now, I don't care much if a turret shoots through the hull, for now, I care about the fact that, what, 5 years after FS1 has been released? we still can't put barelled turrets on the sides of a ship? when WC3 could? yeah, great, that's some serious design limt, if you ask me.
-
Well that may be the other end of the same problem - if could have multi-part turrets with a normal off the vertical without any screw-ups we could go at least part way to avoiding the situation I described in my previous post.
-
Also, not all ships provide exactly equal clearance in every direction. It's not really fair ro blame the modders, since if they made it so every single turret had the same clearance on every plane, it would very severaly limit the available shapes for ships.
Flipside :D
And as far as I can tell, it won't touch the frame rate, since it has to plot a straight line as an equation to draw the laser anyway, and has to do collision detection olong the way, so I think it would any be a variation of this?
-
heres my turret wishlist:
1. the ability to specify the field of fire on both the x and y axes seporately.
2. the ability to select a default turret position.
3. make the turrets scan the sky when there is nothing to shoot at.
4. make them less jumpy.
5. mouse control mode! as well as turret control for observers in multiplayer.
6. single object pivoting turrets.
7. two part turrets that may be placed on any plane (not just on the xz plane), possibly on angled planes.
8. revolving barrel turrets (gatling guns!) and recoiling turrets (flak and other high caliber ballistic guns)
9. more gunpoints!
10. cycle and swarm launch modes (specified in weapons.tbl).
i can only think of 10 right now. i might think of more later.
-
allright I'll get right on it, just give me 3 years to learn C, another year to become familiar with FS2 SCP, then 6 months to get the coding done. If anyone think's they can do it faster be my guest :)
but i'm not going to bother with mouse controled turrets, will you settle for improved fighter turret AI. like having it auto target the weakest attacker, weakest near ship, strongest attacker, bombs.
-
Question: how does the engine check for weapons impacts? Couldn't the engine be made to check for a projected weapon impact against the firing ship using existing impact check code? That wouldn't butcher framerates, would it?
-
every frame it might, the ***** is figuring out were to put it
-
how bout check whenever it'd otherwise fire?
-
yes - only check when it wants to fire - that should not kill framerate too much because we're just checking line-intersection
there is one problem though - the firepoint is almost never physically outside of the ship, and even then almost never outside the polygon BBoxes - so you'd probably end up making it so turrets _never_ _fire_ - a possible solution to this is not counting it's parent sobj as something it can collide with - it can still collide with the rest of the ship though - but it requires a small modification of the collision detection code
-
Originally posted by Kazan
yes - only check when it wants to fire - that should not kill framerate too much because we're just checking line-intersection
there is one problem though - the firepoint is almost never physically outside of the ship, and even then almost never outside the polygon BBoxes - so you'd probably end up making it so turrets _never_ _fire_ - a possible solution to this is not counting it's parent sobj as something it can collide with - it can still collide with the rest of the ship though - but it requires a small modification of the collision detection code
But couldn't you work around that limitation by only checking for colision with polygons/BBoxes who have normals facing the turret?
-
BBoxes don't have normals.. if you checked polycollision you could have that - but if the fire point is physically inside the main hull almost all of the ship will have polygons/BBoxes facing away
-
Well, how much more processing time would it take to check polygons instead of bounding boxes?
-
If it could cause too high performance loss, wouldn't be possible then, as other proposed, to have different FOVs for the different axis, and leave to the modders to don't make turrets firing to the hull of its own ship?
-
It would only need to do it for the polygons of the ship that is actually firing, and would only need to be checked once per shot, so it wouldn't matter what way round the normals are then. Maybe of you only checked for collisions more than 10m away from the firepoint or the like?
Flipside :D
-
I say go with altering the pof data regardless. Making it so the turret can't shoot through the ship is nice and all but it sounds like it's going to involve a fair overhead for very little gain compared with just getting the modders to do it when the ship is made.
Here's an idea. Instead of putting all this extra code into FS2 we (or more specifically the SCP) implement the 3 axis fov settings. Then we figure out how to get the turrets to figure out what is part of the ship and what isn't but don't put it into FS2. Instead we put it into Aurora and PCS who have the processor cycles to spare.
Why calculate the acceptable firing angles every time a turret fires when you can calculate them once when building the pof and be done with it? Both PCS and Aurora could probably figure out the firing arcs at least as well as FS2 could.
*apologises in advance to Kazan and Bob for increasing their workload* :)
-
Obviously I'd be quite happy to rejig my ship's firing points if that was what was required to fix the shoot-through-your-own-hull bug. And eventually someone will get bored and take the time to retrofit the old V ships.
-
I find myself agreeing with karjorama, I don't think there is much excuse for creating a turret that cannot fire under the three axis system. Also, this give the wonderful option of narrow plane strip weapons ;)
Flipside :D
-
What if we had the engine calculate the invalid firing angles (not each individual angle, just the angle intervals for each of the three axis) in mission load for every ship used in the mission? You'd only have to check if the turret is aimed within one of those intervals then.
-
You mean as part of the POF data parsing? Sounds like it could work, but if the firepoint moves (rotational turrets) I'm not sure how accurate it would be.
-
It's like I said in DG's thread, make it so you can put n degrees on the x, y, and/or z axis around the normal in the pof data, and this wouldn't be such a problem.
If the normal was -1x, and the fov for x was 90, and for y was 180, it's make a thin rectangular arc around the turret that would be allowed to fire in, so you could make it not hit it's own hull.
Am I wrong?
-
It's a good idea, and, the area of non-firing would be the same, regardless of what the turret does, but it would still require a matrice of some kind to hold 'obstruction' info for every turret on a ship. Things could get complex at times, besides this still would not solve the firing point inside the hull problem alas :(
Actually I think it WOULD work with only normals that face towards it, after all, any obstruction etc has got to have polygons facing the fire point, it's impossible not to if I remember rightly. If anyone can design a ship where you can have a point moving out from the centre and hitting two polygons in a row which have their normals facing away from the direction of travel, then I will admit I am wrong, but as far as I can imagine it, this is true.
-
mmm I was thinking.. yes, the multiple fov sounds good, but actually we non coders have absolutely no idea about how the thing work
I mean: how does the game decide if a ship is in turrett's range(=you are inside its FOV) and therefore you are a valid target?
I have no idea, but imagine it calculate the firing area as a cone (i mean, mathematically) to decide if a point (target's position) is inside this area or not.
Now imagine what will happen with 2 FOVs for the two axis....
This is something coders knows better than us btw.
I have another possible solution if both multiple FOVs and occluded sight check can't work: we may call it "special turrett"
Even in the more complex ships the turretts that could have this kind of problems are really few, so, what about using a predefined targettable area? It would be pure pain in the ass if we have to do this for each turrett, but since it would be necessary very rarely, it wouldn't be much a problem. I'm talking about making a model of the firing area wich will be stored in the pofdata and used by the game to define where a turrett can fire or not. Since it will be a mesh, it could probably cause some performance hit too, but considering that it wouldn't be required very often, it may work, the point is if it would be useful or possible to have the firing range defined by a mesh
-
Originally posted by Flipside
Actually I think it WOULD work with only normals that face towards it, after all, any obstruction etc has got to have polygons facing the fire point, it's impossible not to if I remember rightly. If anyone can design a ship where you can have a point moving out from the centre and hitting two polygons in a row which have their normals facing away from the direction of travel, then I will admit I am wrong, but as far as I can imagine it, this is true.
I still think this is the best idea, as it would allow a theoretical turret positioned below an arch to shoot to either side, but not to shoot at the arch.
Would it be easier to render a single frame from the POV of the turret about to fire at a low(er) resolution (300x300 or something) with no textures or lighting, and limited to the current ship? that way it would be a white-on-black render - essentially a "mask" where the black areas would be valid angles to shoot at.
-
Originally posted by KARMA
I'm talking about making a model of the firing area wich will be stored in the pofdata and used by the game to define where a turrett can fire or not. Since it will be a mesh, it could probably cause some performance hit too, but considering that it wouldn't be required very often, it may work, the point is if it would be useful or possible to have the firing range defined by a mesh
about predefining the firing area of some occluded turretts with a specific mesh, wich I don't know if it could be practicable/efficent/useful or not, it would probably be possible to detect in a easy way if a ship is in the FOV or not by using some kind of collision detection: if a ship pass through the bounding box once, it means she is inside the firing area; if a ship pass two times, it means she was inside the firing area but now exited. Note that the mesh don't need to be very complex, a deformed octagonal pyramid (14 triangles) for example should be enough
-
Why not just have a long, long cube object placed on the turret barrel. it would move with the barrel.
If that object intersects any face of the capship the turret can't fire. I don't know if it could be done like this, nor just how resource demanding it would be - it's just a tought!