Syncing disruptor fire

posted on February 15th, 2011, 4:18 am

I was playing around with using multiple shot delays and a hardpoint shift to simulate simultaneously firing two phasers using one weapon, and realized it could be a solution to another problem.

Using a Bird of Prey for an example, it's always annoyed me that the two disruptors don't keep the same fire cycle.  I've played around a bit, and am really close to making it perfect.  In the below example, the Bird of Prey fires three volleys of paired shots, and it's the same every time.  The problem I have is that setting the shot delay lower than .03 causes the weapon to just rapid fire endlessly.  With the shot delay at .03, you can just see that one shot is slightly ahead of the other (barely).  I'd love to be able to set the negligible shot delays to 0 (or very close to it) to make the shots pair perfectly.  Is this a game limitation, or something that could be addressed?

Example:

In the "kli_brel.odf" file, I changed it to have only one disruptor using both hardpoints:

weapon1 = "kliW_brel1"
weaponhardpoints1 = "hp09" "hp10"
//weapon2 = "kliW_brel1"
//weaponhardpoints2 = "hp10"

Then, the shot cycle in "kli_W_brel1.odf"

shotcycleresettime = 2.4
shotdelay0 = 0.03 //if this could be 0, the shots would pair perfectly
shotdelay1 = 0.2
shotdelay2 = 0.03
shotdelay3 = 0.2
shotdelay4 = 0.03
shotdelay5 = 2.4
HardpointShift = 1

posted on February 15th, 2011, 4:33 am

So what you're saying is, you want a weapon that fires a volley of 2 shots with no delay, but the shots come from 2 different locations on the ship?

-which hardpoint does it use to test whether the target is in range?

-have you looked at E2 burstfire torpedoes?  They fire in volleys, although that might be the way you're doing it already, I'm not sure.

posted on February 15th, 2011, 11:14 pm

1) Yes - I want this (the appearance of two weapons always firing in concert):

-    -    -
-    -    -

Not this (what you typically get from two identical weapons firing from different hardpoints):

-  -    -
-    -    -

2) Isn't the closest hardpoint always the one that fires first?  I didn't know you could force the game to hold fire until a certain hardpoint is in range.  The hardpoint shift always uses the closest two hardpoints, so making the weapon work is reliable as long as there are only two hardpoints assigned to the weapon.  That part of the disruptor I posted parts of works fine - I just want to make it fire from both hardpoints simultaneously, every time.

3) No, I haven't seen the E2 torpedo - where do I find it?  I tried to post enough of the odf's to explain what I'm doing - let me know if there's something else you need to see.

[Tyler]

posted on February 15th, 2011, 11:21 pm

Last edited by Tyler on February 15th, 2011, 11:24 pm, edited 1 time in total.

I prefer them to be unique. Even with the weapons identical, interior circumstances can easily cause a delay of a second or two.

A dual-pulse SOD similar to the Critical shot would make them identical, if you know someone who could make one..

posted on February 15th, 2011, 11:26 pm

I don't believe there is a command to hold fire till a certain hardpoint is in range I'm afraid - I think you'll always get variability that way, unless you use a little magic and have the double disruptor be a single shot just with two animations.

The E2's firing sequence won't help you, but the ODF is fedw_excelsioriiy2

posted on February 15th, 2011, 11:44 pm

Tyler's right, a single weapon firing from a center point with a SOD rather than two sprites from individual points would be the only way to get it perfect and avoid the staggered effect. I could do the whole thing, but it would require reducing the firing arc and modifying the vessel's SOD. If Doca or Optec gives the OK to modify the BOP model, I can get started.

posted on February 15th, 2011, 11:48 pm

If Doca or Optec gives the OK to modify the BOP model, I can get started.

according to the modding guidelines you can get started on the work now, as long as you dont release it without their permission.

[dragonmalice]

posted on February 16th, 2011, 11:58 pm

Last edited by dragonmalice on February 17th, 2011, 12:14 am, edited 1 time in total.

Yep, in regular A2, it was easy enough to just modify the weapon texture to make one shot into two.  I guess I need to learn how to start modeling now that the weapons use SOD's.

Brings up another crazy question - we can resize ships and stations in the .odf files.  Can weapons be manipulated in the .odf at all, or is the size entirely determined by the .sod?  The scaleSOD command doesn't have any effect when placed in the weapon or ordinance files.

Ah, E2 = Excelsior II!  Yeah, that's how I have all my Fed torpedoes working (with varying number of shost and delays based on rank).  I'm always finding more uses for this -

Back to the original post, any idea why setting one of the shot delays lower than .03 breaks the fire cycle and causes the weapon to just ifre continuously?

posted on February 17th, 2011, 12:01 am

Might be due to your shotCycleResetTime.

[dragonmalice]

posted on February 17th, 2011, 12:26 am

Last edited by dragonmalice on February 17th, 2011, 12:30 am, edited 1 time in total.

I'm not sure if you meant to add the capitals into the reset time - if so, no effect (most of the reset times are all lower case in the original weapon files, so I guess that doesn't make a difference in this specific case).

If you meant to do away with it altogether, good call!  It works now:

shotdelay0 = 0
shotdelay1 = 0.2
shotdelay2 = 0
shotdelay3 = 0.2
shotdelay4 = 0
shotdelay5 = 2.4
HardpointShift = 1

There may not ever be a need to do the dual weapon SOD again 

posted on February 17th, 2011, 12:30 am

Yes, your shotCycleResetTime looked wrong for your shotdelays (as it should just keep repeating its shotdelay as it is reset).

Glad to hear you fixed it

posted on February 17th, 2011, 12:57 am

You're right, there's something in the interaction between the shot delays and the reset time.  I added the cycle reset back in with varying times and it works. 

Thanks for the quick replies - this has been bugging me all week.