[SCRIPT][AP][TC] Advanced Fight Scripts - v. 3.1, 19.01.2014

[DrBullwinkle]

As for the fighters not hitting the ship:

I reported something similar in one of your early versions of this script.

The problem is that lasers are not fully effective at their maximum range.

Test Case: Approach a target at maximum range for your lasers. Shoot. Watch how much damage you do. Move closer. Repeat.

In my tests I did not see full damage until I reached approximately half of the maximum laser range.

[Cronos988]

As for the fighters not hitting the ship:

I reported something similar in one of your early versions of this script.

The problem is that lasers are not fully effective at their maximum range.

Test Case: Approach a target at maximum range for your lasers. Shoot. Watch how much damage you do. Move closer. Repeat.

In my tests I did not see full damage until I reached approximately half of the maximum laser range.

Are you sure this is not because the lasers have a randomized offset that puts them slightly off-target? Against a fighter sized target, about half the shots usually miss (my tests suggest that for AI ships, the offset is significantly larger).

[DrBullwinkle]

Just try the test.

I do not think it is related to missing the shot. I tested against a large, stationary, ship.

[Cronos988]

Just try the test.

I do not think it is related to missing the shot. I tested against a large, stationary, ship.

OK, I just did a small test, and I cannot confirm. While the results are certainly odd, damage values did not get higher at lower ranges. The damage values are, however, randomized, I did see a fluctuation of about 10% at all ranges.

What was really odd is that the Impulse ray emitter (modded version, 400 RPM, 55 hull damage) did around 110 hull damage. Nevertheless, the Damage per second shown in the weapon details is 366, which is rougly 55 * 400 / 60.

Is it possible that the engine can't handle the RPM? It just sets RPM to 200 and fires 2 bullets per shot?

[DrBullwinkle]

I don't know about high RPM, because I tune most of my lasers to fire less than 100 RPM (and increase their bullet damage to compensate). I do that for performance (like CMOD).

Although I have not tested extensively on all versions, my general observation is that lasers have always done more damage at half-max-range than at max range. TC and AP.

I mean that you do not have to do a fancy test... it is kind of obvious in most dogfights. Your guns just don't do much damage if you try to fire as soon as the in-range indicator lights up.

However, it *is* possible that the effects vary with different lasers. I favor ISR's, EBCG's, and PBE's for most jobs, so most of my observations are probably with those.

[Guest]

Is it possible that the engine can't handle the RPM?

... what i know is that you need a 2-script-system to fire more than 4...5 times per second
... that´s because the instruction:

Code: Select all

@ $Retcode = [THIS] -> turn turret $X to target $Y timeout = 500ms

... needs at least 150...250ms to perform its action (according to MSCI handbook)
... so if this instruction is performed after every single shot from that script that shots at the target (which is the case for vanilla-scripts), the ship won´t fire more than 4...5 times per second

... MARS uses 2 scripts, one to perform the "turn-turret"-instruction and another to fire at the target
--> that´s why MARS can fire more than 30 times per second (see "Pulsed Beam Emitter")


EDIT:

It just sets RPM to 200 and fires 2 bullets per shot?

... if there were more than 1 lasers in the specific turret, it wouldn´t be suprisingly
... but if there is only one laser installed that fires more frequently than RPM, then i guess it has to do with a weapon change
(you can fire 1000 times per second [even with Incendiary Bomb Launcher] if you un- & re-install the laser after every shot !!)

[Cronos988]

I don't know about high RPM, because I tune most of my lasers to fire less than 100 RPM (and increase their bullet damage to compensate). I do that for performance (like CMOD).

Although I have not tested extensively on all versions, my general observation is that lasers have always done more damage at half-max-range than at max range. TC and AP.

I mean that you do not have to do a fancy test... it is kind of obvious in most dogfights. Your guns just don't do much damage if you try to fire as soon as the in-range indicator lights up.

However, it *is* possible that the effects vary with different lasers. I favor ISR's, EBCG's, and PBE's for most jobs, so most of my observations are probably with those.

I know that this is true in dogfights, however, I also think I know why: because lasers don't shoot where you point them at. This is clearly visible when e.g. observing beam weapons: They swerve all over the place. When I fired a PRG shot from max range (about 4km in my game) at a centaur, of the 6 bullets only a single one hit. That is shooting the broad side of a barn with enabled targeting help.

In any event, this isn't a huge problem. In dogfights, my script already choosed distances much lower than max range. And for large targets, it's still generally better to sit at max range even if it meant you are doing less DPS.

Now, the original bug report concerned shots not actually reaching the target, and if that is the case with a non-moving target, then that's a bug.

@JonfersonSSD:
Thanks for the info! However, when I did the test I was sitting in a buster with only a single IRE installed and personally pulling the trigger. I saw only a single bullet fly, and I only saw a single bullet hit. Yet the damage of that bullet was between 100 and 110, when it should have been at most 55 (according to both the TBullets itself and the In-Game weapon info, which apparently gives DPS instead of raw damage).

[DrBullwinkle]

In dogfights, my script already choosed distances much lower than max range.

Choosing distances much lower than max range is the important part. Not just for dogfights. I am fairly certain that there is more to the issue than merely missing the target.

• (Your early version had a problem with that -- vanilla scripts were more effective, which is why I reported the issue. It sounds as though it is time to try it again. Thanks for continuing to refine your work! This is a rather interesting project.)

[Guest]

... i think that´s why MARS uses a "dummy target" to fire on big ships more precisely

In dogfights, my script already choosed distances much lower than max range.

... it would be better to make that (attack distance) dependend of laser speed / target speed

[Cronos988]

Choosing distances much lower than max range is the important part. Not just for dogfights. I am fairly certain that there is more to the issue than merely missing the target.

That's fine, but again I just cannot reproduce. Lasers do the same damage at any range, they just need to hit. Which is what my scripts attempt to secure as best as possible (there may still be issues). I am thankful for any feedback, but all my tests suggest that attacking big targets works really well and is significantly more effective than the vanilla fighter AI.

... it would be better to make that (attack distance) dependend of laser speed / target speed

Target speed is actually pretty irrelevant when it comes to hitting stuff, distance and size is what's important (and bullet flight time). Target range is calculated according to these factors, and the script then uses relative target speed to get into range exactly and not any closer (because evading is bad).

[Viliae]

Hello

This is me with missile thing again .
I have made new tests, this time I send Paranid Ares (20 missile tubes in four turrets) to Xenon sector (particularly Xenon sector 472) where you you can find a lot of BIG targets.
This time all tubes fires immediately. So I start tracking where the missiles are heading and find out that ship is attacking 3 targets simultaneously. When fighters come in visible range all turrets start tracking much more targets, what I mean - they shoots flails against fighters and torpedoes against capitals one by one, it looks like missile turrets completely ignore refire rate of missiles.

It looks like rain of fire .

[Nicoman35]

*Bug report*
A wierd behaviour of a wing I am controling with !wing.ship.moveformation occurs.
Whith following code, I order the wing to follow it's carrier:

Code: Select all

$wing.ships = get flight wing ship array: wing=$wing
for each $ship in array $wing.ships
$moving = $ship-> is script '!wing.ship.moveformation' on stack of task=0
$target2 = $ship-> get command target2
skip if $moving AND $target2 == $carrier
START $ship-> call script '!wing.ship.moveformation' : argument1=$leader argument2=$carrier argument3=null argument4=null
end

Inside of !wing.ship.moveformation, $move.type == 3 is choosen, calling your altered !move.follow.template.
the following code snipplet is from !move.follow.template beginning at row 178

Code: Select all

if $target.action != [ACTION_LAND_IN_STATION]
if $target-> is docking possible of [THIS]
do if $target-> has a free ship dock port: ship subtype = [THIS]
= [THIS]-> call script '!move.movetostation' : argument1=$target argument2='docking.comp'
end
end

the argument2='docking.comp' is causing the wing leader to dock at the carrier immediately, regardless of the distance between the wing leader and it's carrier.

This is because Gazz docking lockup fix !move.movetostation will dock ships ordered to move at an object they can dock at immediately with this argument....
Any suggestions?

[Cronos988]

The only thing I actually altered in !move.follow.template is the method it uses to scan for attackers (uses an array instead of the standard "get attacker") and the script it calls ("plugin.cro.advf.pick" instead of "!fight.attack.object").

The docking code is not by me, so it should be vanilla or Gazz' code. Is the problem that you don't want the ships to dock at all, or that they dock regardless of distance?

That said I did see some weird stuff sometimes, like a wing of ships docking at a destroyer that shouldn't have been able to house these ships. But technically my scripts have nothing to do with docking. Can you replace the original "!move.follow.template" and test the same scenario?

@Viliae:
Glad the missiles work out alright. Did you have that bug with shots not reaching their target again? I rewrote a large part of the speed setting part for the new version anyways, but it shouldn't have happened in the first place.

[Viliae]

Hello

Yes missiles work well but only if you have many targets. Strange: M7Ms added in XRM works fine (XRM removes "missile barrage command") attack all tubes on single target but Vanilla ones don't work that way (every turret scan for enemies - that's way only one attack single target on max range). In big battles it doesn't matter - then it looks like fire rain, every turret attack many targets (fire torpedoes switch to flail and again). So leave it as it is.

But with shots doesn't hit their targets it's different story and it is especially visible with insta hits weapons: PALC, Kyons. When ships with them attack very big target M6, M7 attacking M2 or M1.
Next time I will post a screenshot how it looks.

[Nicoman35]

Is the problem that you don't want the ships to dock at all, or that they dock regardless of distance?

That said I did see some weird stuff sometimes, like a wing of ships docking at a destroyer that shouldn't have been able to house these ships. But technically my scripts have nothing to do with docking. Can you replace the original "!move.follow.template" and test the same scenario?

Hey Cronos,
I tested a wing intercepting some enemies. After eliminating the threat, the wing was ordered back to the carrier. The lead ship was 25 Km away from the carrier as it * PLOP * disappeared. It was in the hangar of the carrier.
That should not happen.
In the vanilla scirpt, the relevant line looks like this

Code: Select all

= [THIS]-> call script '!move.movetostation' : targetstation=$target

while your version (in v2.2) is

Code: Select all

= [THIS]-> call script '!move.movetostation' : argument1=$target argument2='docking.comp'

You did not change this? Then where does it come from??
Do you know a script form Gazz containing !move.follow.template?

[RoverTX]

Hey just an fyi I still have the vanilla !move.movetostation installed in my game. It doesn't have a second argument, meaning that arument2='docking.comp' does nothing. Don't know if that helps anything.

[Cronos988]

You did not change this? Then where does it come from??
Do you know a script form Gazz containing !move.follow.template?

I did not. Gazz has rewritten !move.follow.template, apparently to optimize it. The modified file is in his missile safety scripts for AP, for example. It's possible that I already had a !move.follow.template modified from somewhere when I started writing the scripts but did not notice. Maybe it's the bonus pack?

[DrBullwinkle]

I looked through all of the !move.follow.template versions that I could find in my downloaded scripts folder (including the AP version of Missile Safety), and the only version I could find with the call to !move.movetostation and the "docking.comp" argument is Cronos's Advanced Fight Scripts.

So I searched again, this time for !move.movetostation and an argument that can be "docking.comp", and found it in Gazz's Docking Lockup fix.

Apparently, Cronos's !move.follow.template supports Docking Lockup Fix (which is good).

I think the true problem is in Safe Docking's !move.movetostation itself. That is where the check for range should take place.

Thinking about this from a bug-severity point of view, it would be a greater problem for Nicoman's fighters if they did not use docking computers at all. So it seems to me that the call in Cronos's !move.follow.template is the most "correct" thing that he could do.

If one were to tweak anything, it would be Docking Lockup Fix. (I would use a range of 10km because the vanilla 4km is too short for some stations, which leads to very poor docking behavior while IS. 10km is more reliable, in my experience).

[Nicoman35]

Apparently, Cronos's !move.follow.template supports Docking Lockup Fix (which is good).

I think the true problem is in Safe Docking's !move.movetostation itself. That is where the check for range should take place.

THIS, I second that.

I would change that in my folder, but then it works well on my pc, but not on someone elses. There should be a kind of 'pool', where you suggest your modded vanilla files, and all modders uses these files as a base. Or we end up having multiple versions of vanilla scripts, which will be overwritten by installing another mod....

[DrBullwinkle]

I would change that in my folder, but then it works well on my pc, but not on someone elses.

*Shrug*. Personally, it would not bother me at all. Go for it.

There should be a kind of 'pool', where you suggest your modded vanilla files, and all modders uses these files as a base. Or we end up having multiple versions of vanilla scripts, which will be overwritten by installing another mod....

Good idea. Every time I install something that modifies vanilla flight scripts, I have to check all of the other script mods that I use for compatibility. It is a pain in the neck.