|
2005-10-15 07:46
|
screen0014.jpg (110,462 bytes) |
|
|
Is there a mission that doesn't use mods to demonstrate this. I don't want to be downloading something very large that I won't using all that much. |
|
|
How about the Fenris/Leviathan attempting to fire their Fusion Mortar? That missile turret turns slow and they fire way too early to ever hit something right away. |
|
|
All this is about multi-part turrets: Well i have found a sort of a 'hackfix' or 'override' that produces the result i want to get with standard primaries & non-homing secondaries. The use of '$Swarm: 1' forces multi-part turrets to fire along their barrel lines. It doesn't function with flaks or beams though. I can try to make a simple demonstrative mission to show what i mean, but simply either using Fenris/Leviathan as Axem said or by increasing the rotation time of turrets can be used to get the effect visible. This happens even with 'fast' turrets but the effect can not be as easily seen. What i was hoping (i really do not know if it is possible) was that turrets would only fire at the target when the angle between the respective vectors (line of the barrel and the line from the turret/firepoint to the target) would be small enough. Just to bring the effect of the slow turret rotation (and to make multipart turrets to be just a little more than visual decoration) into to the game as currently turret rotation has no real function without the $Swarm option. I have already a partial solution to the problem so for now this problem can be left as it is. edited on: 11-30-05 04:55 |
|
|
* BUMP * If someone can get me a quick test mission for this I'll have a look. The "hackfix" using swarms would likely no longer work since I fixed the swarming bug for turrets. While this particular problem won't be the default behavior, it could be either an ai_profiles setting or a ship flag (ai_profiles would work better for the code though, as a global option). I know exactly where/how to fix this, since I un-fixed it for the swam bug on single part turrets, so I just need to know if the ai_profiles route is good enough, and to get a test mission to try it out before commit. If I can get a test mission at some point this weekend then I'll go ahead and code up the fix and make sure it gets into 3.6.9. |
|
2006-10-19 16:19
|
|
|
|
I just uploaded a mission with a Levi attacking a Ma'at with the player close to the missile turret. For the first 2 or 3 shots, the missiles won't fire correctly. I hope that's good enough for what you need. |
|
|
Taylor, if you're gonna find a way to selectively enable/disable the turret-normal-only targetting for swarming (or perhaps, even for non-swarming), it might be useful to have it as part of the subsystem data, because things like multi-parts aren't realy a problem for such behaviour, but single parts do the straight fire only. That way, no matter what kind of weapon is placed on a turret, it would always use the same targetting method selected by the tables. Have all weapons do standard target by default, but a subsystem flag like "+aim_by_normals" (or perhaps the bracket style subsystem flags that WMC has been proposing or introducing) would be added perhaps to multi-part turrets, so any weapon mounted on that subsystem would stick to just firing down the normals, so all shots would appear parallel to the barrels. |
|
|
@Axem: Thanks, that worked out pretty well. I don't suppose I could trouble you for something a bit more complex though? Something with multiple multi-part turrents with various weapons: beams, flak, missiles, lasers, and swarming and non-swarming laser/missile variants. I don't think that there is one ship which can do all of that at once, so perhaps two/three ships attacking each other in the various configs. But no weapons on single-part turrets please (easier for me to keep track of in the code that way). @TP: I'm not against the per-turret thing, but the way I have it setup now it will only apply to multi-part turrets regardless of the weapon config. I guess this is what needs to be decided: Would this be better to have on a per-turret basis, only affecting some of the multi-part turrets and with this, the ability to do it for single-parts as well? Or, would you want this as a global option which would turn it on for all multi-part turrets without having to modify each ships tbl entry? Both are actually possible without making the code all messy. But obviously, having the global option enabled would invalidate any per-turret settings from the tbl for multi-parts. The tbl setting could still be used for single-parts though, regardless of the global option. I just can't see the per-turret tbl setting all that useful though, since you are likely to either want this or not, and there are other ways to deal with this in the single-part turret case. But then I'm not the best judge of such things either. |
|
|
The problem is, I can foresee situations where you might want to enable non-normal tracking on multi-part, such as situations when the arms are too far apart on a turret when its trying to target a small fighter craft. Perhaps a global non-normal tracking for single-part turrets, unless a turret is given a proper flag, and and global down-the-barrel targetting for multi-parts, unless a turret is given the proper flag to enable otherwise. The only problem I see with this is that it would affect retail behaviour. FS2 is balanced so that single-shot weapons would travel independant of the barrel on multi-parters. Although we may not like this behaviour, the fact is that its prescedent. That's why I suggest a global all-fire-independant-of-barrel-direction, for both swarming and non-swarming weapons, unless a subsystem flag is added to the turret. |
|
|
Hmm, how about I just go with the disabled-by-default, enable-with-ship-tbl-entry-per-turret approach for now. A global ai_profiles flag can always be added later for single and/or multi part turrets down the road. This would solve the immediate problem in the most flexible way, leave the default behavior for all turrets, and allow a pretty easy global-option upgrade in the future. I'll try and get a test build out for this before the weekend is over with. |
|
2006-10-21 18:49
|
|
|
2006-10-21 18:50
|
|
|
|
Hope this one works better. Both "versions" should have what you need, but I forgot to put in swarming missiles in the first one, so I added that to the slightly newer version. |
|
|
That was perfect. Thanks. I didn't see any problems either, so I'm assuming that the code is sound. I'll get a test build out as soon as I get some more, unrelated, code fixes ready to go (there will be a LOT to test in the new build). Then you can let me know if this is actually working the way you needed/expected. |
|
|
The code is now in CVS (* the 3_6_9 branch only for now *). I'll wait to resolve this until someone actually tests it though. The new ships.tbl flag is "+fire-down-normals" and applies to each turret individually. A test build will be released before the weekend is over. |
|
|
Ok, somebody grab http://icculus.org/~taylor/fso/testing/rc7dot9.rar, and see if this is fixed when using the new tbl entry (it goes just before the $animation entry btw). |
|
2006-10-29 05:34
|
screen0045.jpg (19,184 bytes) |
|
|
screenshot0045.jpg demonstrates what happens with the option.. So the turrets fire more closely to their normals (a huge improvement to the earlier) but still it allows for this. Though that isn't actually a problem but there are some others. Now all missiles fired from turrets fly directly towards their targets and the earlier 'fly some distance straight and then turn to face the target' (aka vertical launch system) doesn't function any more. Also if used with single parts the turret fires only when the target is reasonably close to the turrets normal, and when it fires it shoots directly towards the target ( = not on the turret normal). |
|
|
I've observed that turrets appear to "lurch". It will be in one position, and when it fires, it will instantaneously rotate to another position, which is usually between where it was and the firing vector. Would it be possible to implement something along the lines of getAimVector -> rotateTurret(AimVector) -> fireTurret ? |
|
|
"Now all missiles fired from turrets fly directly towards their targets and the earlier 'fly some distance straight and then turn to face the target' (aka vertical launch system) doesn't function any more." Is this with multi or single part turrets. A multi-part will be forced to actually face the target before it can fire, when the flag is used. I'll probably need a test mission/model/tbm in order to work this one out. "Also if used with single parts the turret fires only when the target is reasonably close to the turrets normal, and when it fires it shoots directly towards the target ( = not on the turret normal)." For swarm or non-swarm turrets? The code is different for the two so that is something I need to know. Also, I need to know if the problem effects both, or just one of the types. "I've observed that turrets appear to "lurch". It will be in one position, and when it fires, it will instantaneously rotate to another position, which is usually between where it was and the firing vector." I think that is something that Bobboau was/is working on. That isn't for this bug though, and not for 3.6.9 either. |
|
|
I have noticed that even with the "+fire-down-normals", the turrets are not firing like the should be. http://img.photobucket.com/albums/v109/NarfPics/wrongway.jpg In this pic, the ship has all its turrets with +fire-down-normals and the subobject animation speeds are cranked up high so those shots shouldn't even be hitting me. The weapons being fired all have a +swarm field. |
|
|
My test results using the linked build: Multiparts without new flag * Primaries - Swarm: Shoots directly at the target regardless of barrel line. - Non-Swarm: Shoots directly at the target regardless of barrel line. * Secondaries - Swarm: Shoots indirectly at the target redardless of barrel line - Non-Swarm: Shoots directly at the target regardless of barrel line. Singleparts without new flag * Primaries - Swarm: Shoots directly at the target regardless of barrel line. - Non-Swarm: Shoots directly at the target regardless of barrel line. * Secondaries - Swarm: Shoots indirectly at the target redardless of barrel line - Non-Swarm: Shoots directly at the target regardless of barrel line. Multiparts with new flag * Primaries - Swarm: Shoots when target is close to the barrel line - Non-Swarm: Shoots when target is close to the barrel line * Secondaries - Swarm: Shoots indirectly when target is close to the barrel line - Non-Swarm: Shoots indirectly when target is close to the barrel line Singleparts with new flag * Primaries - Swarm: Shoots when target is close to the barrel line - Non-Swarm: Shoots when target is close to the barrel line * Secondaries - Swarm: Shoots indirectly when target is close to the barrel line - Non-Swarm: Shoots indirectly when target is close to the barrel line EDIT: Tested also Type 4 beams, behaviour is similar in both single and multipart turrets. Without the flag beams fire when target is in fov, shoot directly on the barrel line. With the flag beams fire only when the barrel angle is relatively close to the target. Still only on the barrel line. |
|
|
Ok, found the problem. It was a stupid little thing I did without thinking about it, trying to optimize the submodel animation code. The problem was that the turrets didn't process fully for movement each frame which led to the positioning issue. Reverting that part of the change fixed the problem. |
|
|
Try: http://icculus.org/~taylor/fso/testing/rc7dot9x.rar |
|
|
Apart from much smoother turret movements no change from the earlier test. Post 0007132. Axem tested it too and saw no change from the status that was reported earlier. |
|
|
Ok, I'll take another look. |
|
|
Not going to work on this. |
|
|
I have this as a feature in my branch. A new turret/subsystem flag that prevents the turret from firing unless desired and current barrel angles match. But as how well it works.. in my tests i saw no problems but i have had very few people testing my builds. EDIT: Just to make sure, the fix/feature is not in trunk. |
|
|
Fixed - but not rigorously tested - in wanderer branch. |
- Anonymous
