Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: KeldorKatarn on July 01, 2009, 10:18:39 pm
-
I'm not sure whether this is WAD or a bug so I'm asking first here:
I have a ship that has a forward fixed, non moving 90° FOV torpedo launcher with firing normal 0,0,1 (forward).
I recently set $Free Flight Time: for that torpedo type to 1.5 seconds... my hope was that the missile would fly 1.5 seconds in the foward direction, then turn towards the target.
Instead it flew towards the target as usual, and just didn't start homing for 1.5 seconds. So I checked without $Free Flight Time: and same behavior, just started after the standard time to home.
Why is such a torpedo immediately oriented towards the target? The launcher 'turret' can't turn towards the target, it isn't animated and has turn speed set to 0.0 in ships.tbl
So how can the torp be pointed towards the target already? I can lock because of the 90° FOV, but it shouldn't be able to immediately fire it in that direction.
Any ideas, insights, explanation whether this is WAD or not and if so, why?
Thanks.
-
You need to turn on 'fire down normals', correct? Otherwise the turret normal will be ignored and the projectile's starting angle will just be aimed at the target.
Could be totally wrong, though.
-
How do I turn such a thing on. I didn't find anything like that. There is a feature that the turret doesn't fire before the barrels aren't pointing at the target. But that cannot be used here since this turret cannot move, so it would never fire.
-
Subsystem flags.
http://www.hard-light.net/wiki/index.php/Subsystems#.24Flags:
-
Yep, exactly.
-
Thanks. I somehow completely overlooked this. I'll try it out =)
-
Tried it. the flag has no effect at all in this case. It still immediately is fired in the target's direction.
-
Try combining it with the swarm flag.
I know weapons of the type you're looking for have been done.
-
I just looked at the code... from what I can see the "fire down normals" flag doesn't do anything at all. It sets an integer variable to 1 which is never used again anywhere in the code.
Is this feature even implemented? I see no code taking any effect from this whatsoever.
-
I could've sworn it'd been used in weapons that achieved this effect. However, you'd be able to tell better than I.
You may want to check out other modpacks that use missile weapons with a similar effect. I don't know of any off the top of my head, however...
-
I don't need to check out any modes if I look at the source code and see no indication that this flag has any effect at all.
Can someone from the SCP who has worked on this please check this out? I'm posting this on Mantis.
Edit: Correction. There is one single usage of the value. I'm going to check out what it doesn. In-game I see no result so there must be a bug in this somewhere.
-
Keldor, that's not what I mean. You may want to check out mods with weapons that work the way you want your weapon to work so that you can see how those weapons work and imitate it.
Does that make sense?
-
It might but I just confirmed there is a bug in the code, so no need to look at something else and imitate.
The code takes the argument, calculates the correct vector, then later uses a wrong vector instead. This might actually cause a lot more trouble than just this since the entire vector calculation is disregarded to a point.
I already posted a mantis report with a proposed patch.
-
I don't recall, but Wanderer might have written code that supercedes that flag, that or that is his code and it's his bug.
-
It might but I just confirmed there is a bug in the code, so no need to look at something else and imitate.
The code takes the argument, calculates the correct vector, then later uses a wrong vector instead. This might actually cause a lot more trouble than just this since the entire vector calculation is disregarded to a point.
I already posted a mantis report with a proposed patch.
All right, cool, but in the meantime, don't you want to get your weapon working?
-
It might but I just confirmed there is a bug in the code, so no need to look at something else and imitate.
The code takes the argument, calculates the correct vector, then later uses a wrong vector instead. This might actually cause a lot more trouble than just this since the entire vector calculation is disregarded to a point.
I already posted a mantis report with a proposed patch.
All right, cool, but in the meantime, don't you want to get your weapon working?
Wouldn't achieve anything - we are releasing neither today nor tomorrow. ;)
-
Eep! Tolwyn!
Sorry, didn't mean to step on any toes.
-
I don't recall, but Wanderer might have written code that supercedes that flag, that or that is his code and it's his bug.
Well whoever wrote it can assign the issue to himself. There is a Mantis entry now as mentioned and I already attached a patch to it (basically just one line needs to be changed for the code to make sense and work.)
http://scp.indiegames.us/mantis/view.php?id=1948
-
I just looked at this again. This doesn't seem to be a recent problem. This was in there at least since March 2008, and even then it was nonsense from what I can see.
-
Then it's not Wanderer's new code I don't think. He's committed some stuff to trunk recently that might help fix it, if I recall.
-
I checked that. Didn't really seem related to this.
The problem is basically that the code calculates the firing vector (the function doing that can decide how to do that, here the flag comes in effect)
That's all nice and fine.
later an additional vector from the turret to the predicted target position is calculated. That one is basically just used to determine target-in-field-of-view checks and the distance to the target,
But someone somehow missinterpreted this and used the helper vector to initialize the weapon instead of the really-calculated one, so the weapon is always fired exactly towards the predicted target position instead of towards the calculated one.
So the only real issue is, that the wrong vector is used. That's a one line fix. Where that originated I cannot tell, it was back in CVS days. It was already there when you guys moved to SVN.
I wrote a detailed description of the problem and the callings in Mantis. Check it out for details.
-
AFAIK weapon being fired from the turrets at the predicted position instead of the direction where the actual firing vector is a retail thing. That is :v: didn't seem to be able to get turrets work like they wanted to without it.
What you can try - presuming this is not massively used weapon - is to use swarm: 1 type weapon
-
Well.. we already fixed it and a patch was already committed.. check mantis for details.
-
Yes.. i checked the patch.. and from what i saw it does change the retail-like behavior. That is it needs to be bound via ai_profiles options or otherwise it will change balance in existing campaigns played after the patch.
-
Another "fix this bug" flag? Do you know how many "oh my.. we need to keep this bug or we'll break everything" flags we have already?
If you guys really want to maintain this policy.. fine... add another flag. But if I were in your shoes I'd really start re-evaluating this. Keeping retail behavior is one thing. Keeping retail bugs (like the afterburner usage of AI or the inability to link weapons correctly due to a bug in energy percentage calculation etc tec) is quite another. This is stuff the developers might have fixed back then with an official patch if they had noticed it and they wouldn#t have cared one bit about breaking the before buggy behavior.
So I'd really suggest a distinction between retail wanted behavior and retail bugs.
if you decide against it. go ahead and add the flag and we'll use it. But I'm not very fond of these solutions anymore.
-
None of us are fond of these solutions but the simple fact is that a little tweak here, a little tweak there, all of them having only a minor effect on the game and all of a sudden we'll find that FS2 is unplayable on FSO. Which defeats the point of backwards compatibility.
-
Also you have to remember it's not just retail compatibility anymore how many other things depend on that working the way it does now. I'm sure if 2 years down the road a problem was found and fixed that rendered Saga unplayable you wouldn't be too happy about it.
-
Also you have to remember it's not just retail compatibility anymore how many other things depend on that working the way it does now. I'm sure if 2 years down the road a problem was found and fixed that rendered Saga unplayable you wouldn't be too happy about it.
I'd burn you in hell. :nod:
-
Also you have to remember it's not just retail compatibility anymore how many other things depend on that working the way it does now. I'm sure if 2 years down the road a problem was found and fixed that rendered Saga unplayable you wouldn't be too happy about it.
Not that that has happened time and again with us having to adjust.
But thats not what I'm saying. I'm not talking about not keeping retail compatibility. I'm just saying that bugs shouldn't ge considered retail compatibility.
The original game certainly was never meant to be played with an AI that was unable to link primaries properly because there was a bug in the code and stuff like that.
This qualifies as a bug for me and so does this firing vector thing. There's even a comment in the code stating exactly:
// Fire in the direction the turret is facing, not right at the target regardless of turret dir.
right above the line where that "vector to target" is calculated to emphasize that it is NOT meant for usage as a firing direction. So the intention of the original developers is pretty
clear to me.
If it was at least one flag "fix-retail-bugs" or something...but a flag for each bugfix... that's pushing it in my opinion.
And don't get me wrong... this doesn't concern me from Saga's point of view. We pretty much don't care how it is implemented as long as it works. But I'm really concerned that such decisions
will at some point render FSO in a state where further development is given up because nobody can make heads or tails of the codebase because all of this unnecessary stuff.
Just my 2 cents. At the end of the day it is still your decision, just offering an opinion.
-
Granted that i have been far too busy lately and unable to test this but... If it is handled via the method proposed... then how are normal single part turrets supposed to hit anything as they essentially never point to the target?
-
I believe this is specifically supposed to be about missiles and only affect multipart turret code, but there's no guarantee it won't affect other things to. And that's the big debate.
-
Granted that i have been far too busy lately and unable to test this but... If it is handled via the method proposed... then how are normal single part turrets supposed to hit anything as they essentially never point to the target?
I'm pretty sure that this affects only multipart turrets, I remember reading something in the code. Also don't mistake this for now always firing along the normal. That is still only activated by the appropriate flag for the turret in ships.tbl.
The problem here was, that the game calculates a firing vector for the turret. And two possible vectors can result. Either the standard one, or the one along the normal if the flag is set.
I'm not exactly sure how the standard one works, I didn't look much at the code, but I think it goes from the firing point to the predicted enemy position.
So this wasn't the issue really.
The issue was that this vector, no matter which one of the two calculations was used, is never used later in the code. Instead a helper vector is used, which always points from the turret base position to target.
So if you want to keep that behavior you can just as well remove the entire calculation code before that because the results are never used anywhere anyway (except the turret location vector, the turret firing vector is totally ignored).
We can do some more testing on this, sure, but I'm very sure that this doesn't have a lot of negative implications. After all from the comments in the code this was the original intention of the developer anyway.
The code has been committed already, so you can just build it and test it with several differnt turrets. From what I could see multipart laser turrets work fine in Saga, so do single-part missile turrets. The rest must be determined I guess.
One thing is for sure.. a non-movable laser turret with "fire along normals" set will never hit a target. But I think that's only logical and fully correct. The flag simply makes no sense for turrets that cannot move. Without the flag they should work just fine. But as I said, we can test it to make sure.
Someone else has to do that though, since I don't have any model in Saga that has a non-movable laser turret, unless I can improvise something by switching a turrets weapon or something.
-
Well, just tested this:
single part turrets with fire along the normal can't hit anything.
multi part turrets still hurt.
flag must be set for the turret in question.
-
Yeah, that's obvious. fire-along-normal mustn't be set for such single-part turrets. Without the flag they should hit everything just fine.
Edit: Just tested this myself by hacking one of our single-part missile launchers to fire lasers and locking the multiparts in position by giving them 0.0 turning rate.
They all work fine. They fire right on target as long as "fire along normal" flag is not set. And that flag makes no sense for a single-part turret without homing weapons anyway.
It DOES make a lot of sense for a single parter WITH homing weapon though, and that finally works now.
I see no turret behavior broken so far.
-
I've been playing through the main campaign for FS2, can report Shivans and NTF as deadly as usual (with the path from Mantis 1948)
-
Yeah.. it seems like the change works as advertised (luckily i was wrong)
However there seems to be some accuracy issues related to the code change combined with the 'fire down normals' flag... For example triton multipart turret was unable to hit stationary uly from 250 m even after giving it 3 minutes time to try. Without either (or both) of the code change and the flag in use the turret was able to hit the same target almost immediately.
-
I just checked the code again to verify nothing changes for NON_fire-along-normal turrets:
This was the vector that was originally used (and should only have been used for field of view checks etc)
vm_vec_sub(&v2e, &predicted_enemy_pos, &gpos);
dist_to_enemy = vm_vec_normalize(&v2e);
So this gets a normalized vector from the turret position to the predicted enemy position.
Well... this is what is used now:
ship_get_global_turret_gun_info(&Objects[parent_objnum], ss, &gpos, &gvec, use_angles, &predicted_enemy_pos);
(ignore all parameters except gvec, the rest is just used to find out where the global position of the turret is.
This happens in that function:
if (use_angles)
model_find_world_dir(gvec, &tp->turret_norm, tp->model_num, tp->turret_gun_sobj, &objp->orient, &objp->pos );
else {
//vector gun_pos2;
//vm_vec_add(&gun_pos2, gpos, gun_pos);
vm_vec_normalized_dir(gvec, targetp, gpos);
}
As you can see... if use_angles is NOT set (this is what fire-along-normal sets to true)
then we use EXACTLY the same vector as before. a normalized vector from the turret to the predicted enemy position (that one was passed to the targetp parameter).
So from a code review point of view the behavior cannot have changed for turrets that don't use the fire-along-normals flag.
-
We're testing multiparts with the flag set - I'm getting a hit rate of approx 60%, and wanderer is getting 0%, just trying to reproduce
-
However there seems to be some accuracy issues related to the code change combined with the 'fire down normals' flag... For example triton multipart turret was unable to hit stationary uly from 250 m even after giving it 3 minutes time to try. Without either (or both) of the code change and the flag in use the turret was able to hit the same target almost immediately.
Well.. since the turret ALWAYS fires exactly along its firing normal if the flag is set, it relies on the turret being EXACTLY pointing towards the target.
And since the later weapon creation code also adds a certain inaccuracy with the $FOF: value, this can indeed get difficult.
I'd say fire along normals really only makes sense for missile launching turrets. I mean other turrets can't have relied on the flag until now since it had no effect anyway.
if one doesn't want a multipart turret to start shooting before it is roughly aligned with its target, well that's what the fire-on-target flag is for, which only checks what the turret is roughly
pointing to before firing, but it doesn't change the firing vector.
So I'd say we're fine here..
-
We're testing multiparts with the flag set - I'm getting a hit rate of approx 60%, and wanderer is getting 0%, just trying to reproduce
I know. I just wanted to make sure and emphasise again that we didn't break any old behavior with this change.
-
Turns out wanderer was testing with retail vps - mediavps don't have a problem
-
However there seems to be some accuracy issues related to the code change combined with the 'fire down normals' flag... For example triton multipart turret was unable to hit stationary uly from 250 m even after giving it 3 minutes time to try. Without either (or both) of the code change and the flag in use the turret was able to hit the same target almost immediately.
Well.. since the turret ALWAYS fires exactly along its firing normal if the flag is set, it depends on the turret being EXACTLY pointing towards the target.
And since the later weapon creation code also adds a certain inaccuracy with the $FOF: value, this can indeed get difficult.
I'd say fire along normals really only makes sense for missile launching turrets. I mean other turrets can't have relied on the flag until now since it had no effect anyway.
if one doesn't want a multipart turret to start shooting before it is roughly aligned with its target, well that's what the fire-on-target flag is for, which only checks what the turret is roughly
pointing to before firing, but it doesn't change the firing vector.
So I'd say we're fine here..
Yeah.
Just wanted to see what is wrong and it seems the problem with the accuracy of the turrets is related to the actual models or other game data. I was testing with retail while portej had mediavp version in use. With retail version turrets missed by couple of ship lengths (in uly) while mediavp model was dead accurate.
Also.. do you (keldornkatarn and others) think the firing angle of the weapons, when using the 'fire down normals' flag should be improved? Now it is kinda limited and probably prevents try 'vertical launch system' style launchers from working except when the turret is almost pointing at the target. Or if they work well enough already then that can be left alone
...
if ( !(wip->wi_flags & WIF_HOMING) )
{
if ((dist_to_enemy < 75.0f) || (dot > AICODE_TURRET_DUMBFIRE_ANGLE ))
..
else if ( wip->wi_flags & WIF_HOMING_HEAT )
{ // if heat seekers
if ((dist_to_enemy < 50.0f) || (dot > AICODE_TURRET_HEATSEEK_ANGLE ))
..
else if ( wip->wi_flags & WIF_HOMING_ASPECT )
{ // if aspect seeker
if ((dist_to_enemy < 50.0f) || (dot > AICODE_TURRET_DUMBFIRE_ANGLE ))
..
else if ( wip->wi_flags & WIF_HOMING_JAVELIN )
{ // if javelin heat seeker
if ((dist_to_enemy < 50.0f) || (dot > AICODE_TURRET_DUMBFIRE_ANGLE ))
..
-
I think it works just fine. I wanted this because we have a "single part forward torpedo launcher tube thing" ;)
That one launches, the missile uses 1 seconds free flight time as specified in weapons.tbl, then turns towards the target. Whether this works well or not really only depend on the turn rate of the missile and the distance from target. A very close target at 90° to the side will probably be missed, since a torpedo cannot turn fast enough. but otherwise this seems to work just fine, so I don't see why vertical missile launchers shouldn't work. The missile will launcher, then turn towards the target and start homing.
-
Ahhh, now I'm seeing what you mean.. No wanderer, the angle can stay exactly the same. Reason:
That 'dot' variable is calculated using the temporary vector to target, NOT the one used for the weapon later. So this angle is always the same, whether you activate the flag or not.
The tv2e vector was calculated exactly for this.. for angle and field of view checks. It is always the same.. pointing from the turret towards the target.
Without the flag this vector is identical to the one later used to launch the weapon. If you set the flag, the weapon will be launched along the turret normal but the vector used to calculate the dot-product will remain unchanged. So there is no need to improve any angles, since they don't change.
-
use the modify button .........;
-
I will if the original information was wrong. Since in this case it is still relevant, I'll post a new message. If any admin wants to merge the two posts.. whatever.
-
Yes... but what i was referring to is that with the current setup it does seem to be possible to make a sp missile launcher (like the one in Aegis cruisers front deck) that is capable of firing weapons at the true field of view (firing limits) of the turret.
As the dot is the angle between the vectors (of turrets normal - not facing - and the targets direction)
Basically at the moment weapon firing is allowed if target is first within the defined turret fov and then if the target is - depending from weapon type - within certain angle from the turrets normal (axis of the turrets base's rotation). For heat seekers this it atm fixed to 45 degrees and for the rest its 37 degrees. If the target is outside this code weapon firing is not allowed (with the code change and the flag in use).
-
I don't see where this code change changes ANYTHING in terms of when firing is allowed. As I said, the firing vector is not used for such calculation. it wasn't before and it isn't now.
-
Try following... make a single part missile launcher with the 'fire down normals' flag. Arm it with missiles that are fired at your ship and make sure the set fov of the turret is close to 180 degrees. Make sure you are flying at highest difficulty. Then approach the turret very slightly above and from the side of the turret (make a flyover). If the code mentioned above has nothing to do when firing is allowed then turret should start firing the moment (or shortly after) when you fly within the range of the weapon.. Which it doesn't do. However when you approach the turret you will probably go within the firing angle limitations i mentioned in previous post and turret starts firing missiles.
-
from what i can see this is not a problem of this flag but a symptom of the "turrets dont fire" bug, and it is very well demonstrated in the test mission I uploaded in that mantis report. For me certain tuurrets, including missile launchers, simply do not fire at all in certain situations, flag set or not.
and if you do not believe me that the flag makes no difference in fov calculation then stop testing missions but look at the code. in missions some other problematic behavior can interfere, in the code you see whats calculated and if that is consistent then the problem lies elsewhere
-
Missile turret weapon firing is limited according to difficulty level. I am fully aware of that setting and i was not referring to it at all. Only to issues related to 'fire down normals' flag and fixed firing cone limitations (aicode angle settings).
-
Missile turret firing is NOT limited. It is limited if they fire at the player and I'm not talking about turrets not firing at ME I'm talking about turrets not firing at all.
And again: The flag code change doesn't change ONE THING about how the angle is calculated. If you would at least take a look at the code I'm talking about we'd finally be able to talk about the same issue.
If you disagree then show me where it is used, and don't tell me what the game is doing. The game behavior can be caused by all sorts of things but so far I found no evidence in the code whatsoever that the fire-along-normals flag code change changes ANYTHING about when a turret is allowed to fire and I see no point in discussing that any further as long as nobody shows me the spot in the code that I missed.
I cannot comment behavior that I don't see in the code. If it is there, show it to me.
PS: TO clearify, here's the code:
// This line calculates both the global turret position (gpos) and the global turret firing vector(gvec)
ship_get_global_turret_gun_info(&Objects[parent_objnum], ss, &gpos, &gvec, use_angles, &predicted_enemy_pos);
// Here gpos is used to calculate a second direction vector, (v2e) vector to enemy, which may be identical with gvec, if the flag isn't set, or is different if the flag is set.
vm_vec_sub(&v2e, &predicted_enemy_pos, &gpos);
dist_to_enemy = vm_vec_normalize(&v2e);
dot = vm_vec_dot(&v2e, &gvec);
// As you can se, dot is calculated as the cosine of the angle between vector to enemy and the firing vector of the turret.
// Now if the flag was not set, these two vectors would be identical, hence dot would always equal 1 ( cos(0°) = 1 )
// If it is set, then this is used as always to calculate field of view stuff. So this is nothing new, it's just that before dot was ALWAYS 1.
// Now, dot is used in stuff like this:
if ((dist_to_enemy < 75.0f) || (dot > AICODE_TURRET_DUMBFIRE_ANGLE ))
// Now this doesn't change anything. it's just that without the flag, dot is always 1, meaning the dot is ALWAYS larger than the specified angle (unless that one is exactly 1 too. maybe this
// should be a >= instead here.
// WITH the flag, this will be used now. Which is perfectly logical. A turret that fires its missile always at the enemy can shoot always.
// A turret that fires along a normal first should only fire when firing makes sense.
// So I don't see anything new here, it's just that those angles now finally make sense.
If THIS is what you meant, then yes.. those angles migth need checking, but otherwise, the codechange didn't change a thing, since this was the same as before. the turret now only fires in the correct direction. THis checking code works exactly as before since the change doesn't affect this at all.
So the turret's "can I fire" behavior is exactly as before, only that with the flag they now fire along the normal, as originally planned.
Before the calculated vector was only used to check if firing was allowed, but the missile was always launched directly at the enemy.
Now the calculated vector is used to check if firing is allowed AND for the direction the missile will be launched at.
-
I just noticed... that dumbfire angle is used for aspect locking missiles as well as for non-homing weapons... for the latter ones it seems a bit large actually.. (or rather small, since the constant is the cosine of that angle)
0.8 is a 36.8° angle resulting in a 73.3° firing cone. That's a bit much for dumbfire :P It's ok for aspect seekers though.
-
Just try it out will you?
Replace the AICODE_TURRET_DUMBFIRE_ANGLE (or heatseeker) with both 0.0f and say 0.95f and you should be able to see that it severely affects the turrets
-
Have you even read what I just wrote?
-
Yes
-
Then where did I write that those Constants didn't have any meaning? I just said they work just like before the code change.
The change doesn't affect this at all so if you're not happy with those angles now then you were not happy with them before this change since nothing changed in that calculation.
The only thing that changes is in what direction the missile is launched when the flag is set. Nothing else has changed.