Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: pink_supervisor on January 30, 2016, 06:13:09 pm
-
I gave the fury rocket an acceleration time of 50s with a target velocity of 9999m/s but it wouldn't work. the rockets inherit the ship's velocity and just kind of drift around. I gave the hornet and interceptor missiles acceleration and they do work as expected .
the weapon.tbl wiki says it's supposed to work for both homing and dumbfire secondaries so I suspect this is a bug
-
Hard to say, not knowing what the table differences between those weapons are (no idea what "fury rocket" is).
-
Presumably the Fury dumbfire fom FS1?
-
both the interceptor and fury are secondary weapons from freespace/fsport
the interceptor has homing, the fury does not
; ----------------------------------------------------------------------------------
$Name: Interceptor
+Title: XSTR("GTM-9 Interceptor", 560)
+Description:
XSTR("Standard Issue
Fast Target Lock", 561)
$end_multi_text
+Tech Title: XSTR("GTM-9 Interceptor", 560)
+Tech Anim: cb_interceptor
+Tech Description:
XSTR("All-aspect seeking - laser tracking senses energy reflected off a target from the primary weapon systems of the target, increasing single-pass kill probability - medium payload (18.5 Kt) - missile is designed to pierce reinforced hull, thus securing itself to the target, prior to detonating (15 ms delay).
This is the standard issue fighter killer in the GTA. Designed to take out fighters with minimum hassle, a simple lock is all that is needed to grab the enemy's attention. Short lock time, good speed, and decent payload makes this the best missile to use against all but the strongest ships. Its effectiveness against large targets, however, is less than a typical laser run, making this primarily a ship-to-ship missile.", 562)
$end_multi_text
$Model File: Interceptor.pof
$Mass: 15.0
$Velocity: 9999
$Fire Wait: 2.0
$Damage: 150
$Blast Force: 60.0
$Inner Radius: 0.0
$Outer Radius: 0.0
$Shockwave Speed: 0
$Armor Factor: 1.0
$Shield Factor: 0.8
$Subsystem Factor: 0.5
$Lifetime: 5.0
$Energy Consumed: 0.0
$Cargo Size: 4.0
$Homing: YES
+Type: ASPECT
+Turn Time: 1.0
+Min Lock Time: 2.0
+Lock Pixels/Sec: 70
+Catch-up Pixels/Sec: 100
+Catch-up Penalty: 30
$Acceleration Time: 50.0
$LaunchSnd: 91
$ImpactSnd: 88
$FlyBySnd: -1
$Rearm Rate: 2.0
$Flags: ( "player allowed" )
$Trail:
+Start Width: 0.25
+End Width: 0.5
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 0.7
+Bitmap: MissileTrail02
$Icon: icon_interceptor
$Anim: interceptor
$Impact Explosion: ExpMissileHit1
$Impact Explosion Radius: 7.0
^ this will approach 9999m/s when fired
$Name: Fury
+Title: XSTR("GTM-3 Fury Missile", 554)
+Description:
XSTR("Standard Issue
Maximum Compatibility", 555)
$end_multi_text
+Tech Title: XSTR("GTM-3 Fury Missile", 554)
+Tech Anim: cb_fury
+Tech Description:
XSTR("Small, fast dumbfire missiles - fired in swarms - GTA fighters can carry more Fury missiles than conventional missiles, due to their small size - used for distraction and other tactical measures - very small payload (3 Kt).
Use is recommended in close combat situations and against larger targets where tracking is a non-issue.", 556)
$end_multi_text
$Model File: Fury.pof
$Mass: 0.1
$Velocity: 9999.0
$Fire Wait: 0.30
$Damage: 30
$Blast Force: 0.2
$Inner Radius: 0.0
$Outer Radius: 0.0
$Shockwave Speed: 0
$Armor Factor: 1.0
$Shield Factor: 0.5
$Subsystem Factor: 0.6
$Lifetime: 3.0
$Energy Consumed: 0.0
$Cargo Size: 0.5
$Homing: NO
$LaunchSnd: 90
$ImpactSnd: 88
$FlyBySnd: -1
$Rearm Rate: 12.0
$Flags: ( "in tech database" "player allowed" )
$Trail:
+Start Width: 0.1
+End Width: 0.2
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 0.3
+Bitmap: MissileTrail01
$Acceleration Time: 50.0
$Icon: icon_fury
$Anim: fury
$Impact Explosion: ExpMissileHit1
$Impact Explosion Radius: 3.0
^ this will just float around where you fired it
-
Sounds like a bug to me! Submit it to Mantis so a coder can someday get around to fixing it.
-
Well, we've got a problem in the collision code:
//SUSHI: Fix bug where additive weapon velocity screws up collisions
//Assumes that weapons which don't home don't change speed, which is currently the case.
Other than that, though, the code for handling acceleration time for non-homing weapons is in weapon_process_post() and looks like it should be working:
// a single player or multiplayer server function -- it affects actual weapon movement.
if (wip->wi_flags & WIF_HOMING && !(wp->weapon_flags & WF_NO_HOMING)) {
[snip]
} else if (wip->acceleration_time > 0.0f) {
if (Missiontime - wp->creation_time < fl2f(wip->acceleration_time)) {
float t;
t = f2fl(Missiontime - wp->creation_time) / wip->acceleration_time;
obj->phys_info.speed = wp->launch_speed + MAX(0.0f, wp->weapon_max_vel - wp->launch_speed) * t;
} else {
obj->phys_info.speed = wip->max_speed;;
}
vm_vec_copy_scale( &obj->phys_info.desired_vel, &obj->orient.vec.fvec, obj->phys_info.speed);
}
Please post your fs2_open.log file. Instructions on how to do this can be found in this post.
-
I can confirm he speaks truth.
(http://ibin.co/2VJiJ7aKyGbJ)
Silly rockets, that's not accelerating. That's zero speed.
The particlespew seems to think it's going the proper speed though.
-
Zero speed makes even less sense; its speed gets set to 0 on launch, but the same is true of homing weapons with an acceleration time as well. The fact that it works with homing weapons (and the logic for acceleration_time in weapon_home() is basically identical to the logic used in the code I quoted earlier) means it should also work with dumbfire weapons.
-
For some reason when acceleration is used on dumbfires, the rockets only inherit some of the ship's speed (as pink_supervisor already pointed out). And if there is nothing to inherit, you get above pic. I also checked if there was a difference with $use additive weapon velocity: set to Yes or No, but there was none.
Clearly something mysterious is going on~
-
I can probably fix whatever the underlying problem is (it's my code after all), but it'd be a whole lot more smoother if someone could patch together a minimal FS2-based test case to reproduce with (even if it's just a simple -wep.tbm).
-
Well this took a whole minute to setup, not sure why you needed help with this, but here you go!
(http://ibin.co/2VNEB3tvzuXs)
[attachment DELETED!! by Strong Bad]
-
Thanks! I think I more or less figured out what's happening. The code is supposed to handle dumbfires, but apparently that part isn't working somehow. I'll see what I can do!
-
Y'know, if used intentionally, you could do some really fun stuff with zero-acceleration missiles. :drevil:
-
;7
-
This should fix it. (https://github.com/scp-fs2open/fs2open.github.com/pull/528)
The problem was that all primaries and non-homing secondaries got a flag which made them use more simple physics calculations because the assumption was that they would always just travel at the same static speed. I never noticed that because apparently I only tested by dumbfiring homing secondaries, not firing actual non-homing secondaries. So, I just had to add an extra condition to make non-homing secondaries using $Acceleration Time not receive that flag.
-
Huzzah :yes:
-
Is that why we can't have homing primaries as well? They can turn towards the target, but they'll always travel in straight line. Would that be possible to enable homing on primaries? I can see some interesting stuff that could be done with that.
-
Is that why we can't have homing primaries as well? They can turn towards the target, but they'll always travel in straight line. Would that be possible to enable homing on primaries? I can see some interesting stuff that could be done with that.
...Homing primaries don't work?
-
Last time I tested they didn't. Granted, this was a while ago. If this was changed, it must have been done recently.
-
Yeah as Dragon said, unless someone changed that recently, homing primaries have never ever worked.
-
Yeah as Dragon said, unless someone changed that recently, homing primaries have never ever worked.
Ironically, it looks like the biggest thing stopping this from working is the same PF_CONST_VEL flag that was stopping acceleration time from working with dumbfire secondaries... but there are too many places in the code that check WP_LASER as shorthand for "shot that travels in a straight line" to make changing that by itself worthwhile.
-
As usual, something that should be simple is made not so simple by lousy coding in the FS2 engine. :) Of course, it's not like :v: ever needed homing primaries, and I bet that particular thing isn't something FSO added.
Mods like WoD would greatly benefit from homing primaries, that's for sure. Also, acceleration time on primaries could be an interesting feature (for Gyrojet-like guns, for example). I can see it messing with many things, though, starting from lead indicator and ending in collision detection code.
-
As usual, something that should be simple is made not so simple by lousy coding in the FS2 engine. :) Of course, it's not like :v: ever needed homing primaries, and I bet that particular thing isn't something FSO added.
That's not lousy coding, FYI.
-
Well, I suppose it's not all that bad of a practice, now that I think of it. It's certainly a reasonable assumption given nobody tries to tamper with WP_LASER. Still, shouldn't the check that tests whether a shot something is only moving in straight line look for PF_CONST_VEL flag instead? Unless it's a matter of performance, this seems like a more bulletproof way of doing such checks.
-
I think acceleration time should be varied according to weapon type.
-
http://www.hard-light.net/wiki/index.php/Weapons.tbl#.24Acceleration_Time::
-
Well, I suppose it's not all that bad of a practice, now that I think of it. It's certainly a reasonable assumption given nobody tries to tamper with WP_LASER. Still, shouldn't the check that tests whether a shot something is only moving in straight line look for PF_CONST_VEL flag instead? Unless it's a matter of performance, this seems like a more bulletproof way of doing such checks.
No. There are numerous places where "travels in only a straight line" has different implications for different modules. For physics, it's "use this calculation to predict future positions". For graphics, it's "check whether something is on the screen". For the AI, it's "avoid flying into this path". Etc.
The physics code makes extensive use of PF_ flags, as it should. But (for example) the AI code has no business looking at the gory details of the physics code. Separation of concerns (physics doesn't care about AI, AI doesn't care about physics) is good programming practice.