OOS combat - how SHOULD it work?

[orion84]

Hahaha i kinda took a step back since it got all nitty gritty.

Using the time to learn scripting.

I bet Gazz went to his tower to ponder and actually create some rough lines. He'll be back.

[wyvern11]

me bet too, but I wanna take part

gazz and create rough lines ?? - prepare to be flamed

[orion84]

prepare to be flamed

*Braces for impact*

I meant it like a rough draft.

[Gazz]

what are you up to?
everything discussed?
i'd like to lend a hand !!

There I was hoping someone else would do the actual work if kept quiet...
Awell.
I usually work 7 - 17:00 so most evenings I'm not good for much other than clowning around the forum.
I was planning for an alpha version sometime this weekend.

I guess I'll stay with the current system of simply rerouting the fire instruction to the logging script.
Except that now it has to do more than just log.

Technically it would be faster to stay in the main script but it's far easier to tie a library call into several scripts.
For instance, OWP may learn to actually use lasers OOS. What a novel concept!

Your armageddon experiment has proven that the additional script overhead won't instantly break the game and it is certainly a lot easier to write like that.


At least for now, I will also make this an add-on to MARS. All the extra laser data I need is already there, sorted, debugged, and ready to use.
It won't use any of the MARS scripts or logic - only the configuration data.

Hahaha i kinda took a step back since it got all nitty gritty.

Do not wield the math. Be the math!

I bet Gazz went to his tower to ponder and actually create some rough lines.

My code has been called unintelligible before. That was someone looking into the MARS laser evaluation, I think.
It's essentially one huge formula - not pages upon pages of if-thens that everyone can understand at a glance...
But one line of proper math can save a page full of if-thens and it's far harder to break a formula with an unusual object type or whatever.
And I have the occasional script that simultaneously runs three times on different tasks, doing different things, while keeping up a steady stream of communication with it's other incarnations.
Besides, it's easier to edit a script when all of it's incarnations are in the same physical file and can freely call each other's internal subroutines. Prevents needless redundancy which always creates more bugs and speeds up execution because it removes script-call overhead.

Every redundant parameter is naughty in my eyes.
It hurts to see a standard loop with While $Index > 0
where While $Index will suffice! =)

[wyvern11]

You started the thread - you run it - so shut up and eat

No, who might risk the insolence to superpose the ***mighty gazz of scripting*** in his own frontyard

You see, no one....

besides, you already own the tables (or part of) via MARS. my hint on a structure has not really been discussed yet (and it was more an attempt to channellize the discussion)

I guess I'll stay with the current system of simply rerouting the fire instruction to the logging script.
Except that now it has to do more than just log.

Technically it would be faster to stay in the main script but it's far easier to tie a library call into several scripts.
For instance, OWP may learn to actually use lasers OOS. What a novel concept!

I think this a sound and sensible decision. feel free to ask for any help you might or migh not need

I'll offer a check for distribution of N random(100) calls, N > 10E6.

anything else ?

If you care, I offer a shot on the proper randomization and the evade-values as well


While $Index > 0 ...
actually i like it better that way ...

[orion84]

I'm getting stumped from the resources, and like you Gazz i pull a 8-6 pm shift...

I'll do some work when i learn how to script. From the way you talk code seems easy enough. Then of course its different when you actually do it. PLUS the constant dilemma of testing your script to actually playing...

I haven't got my HQ yet! and the hub is killing me. So teehee.

On the bright side, if the script can be as streamlined as you say, ES might pick up on this, i gotta good feeling about it.

Although i might recommend making this indifferent to mars as people are indifferent to that as well. Kinda like the cure for cancer but you gotta give up your left arm. Mixed emotions about that lol.

I know, give wyvern an assignment. For now im just a cheerleader in the background!

[Gazz]

I think this a sound and sensible decision. feel free to ask for any help you might or migh not need

I'll offer a check for distribution of N random(100) calls, N > 10E6.

Don't worry, there will be lots of testing required. Many pretty numbers! =)

If you care, I offer a shot on the proper randomization and the evade-values as well

Sure thing.

So far I'm thinking of something terribly simple like
$Rand = random number from 75 to 125
$Damage = ( $Damage * $Rand ) / 100

This may be too timid compared to the current system or too much so it makes the skill system pointless...
It's also no normal distribution, no pretty bell curve... but I doubt anyone would actually notice the difference...
I haven't thought about it, yet.


For the evade system: I haven't thought about that, either.
It's some blurry idea like:
faster than average (what is average?) top speed, somewhat (how somewhat?) harder to hit.

Morale/Aggression stats exist for pilots but not for the player so it would be hard to use them at all. They are are something for IS fight scripts.

Getting ship size OOS is possible (calling one of my libraries) but getting top speed is only one script instruction and therefore much faster.
The get.size library always saves ship size on the object so it's never called twice.

[MutantDwarf]

Get size of... doesn't work Out of Sector? That's unfortunate. Of course, you could make it three function calls - spawn a copy of the ship in-sector, Get size of... it, then destroy it - but one function call is better for the most part. Or you could insert a ship's size as a local variable during initialization - I'd think reading that would take about the same amount of processing power as Get Max Speed, though that would require extra memory.

A random damage distribution between 75% and 125% of average shouldn't be too bad even if uniform. It's when you've got between 0% and 200% (or between no damage and full average damage, with no progression upwards) that it's a problem.

[Gazz]

Get size of... doesn't work Out of Sector? That's unfortunate.

I already have a library for that. Calling another script just means a lot more organisational overhead than one line.

It's when you've got between 0% and 200% (or between no damage and full average damage, with no progression upwards) that it's a problem.

Yah, that would be uhh... dumb?
Right now we have something like 3% - 400%.

Although i might recommend making this indifferent to mars as people are indifferent to that as well. Kinda like the cure for cancer but you gotta give up your left arm. Mixed emotions about that lol.

I said "for now".
Let's just assume that I can write a script that reads values from a text file if I want to.
For any scripting / testing this I'll use the ones I already have.

[wyvern11]

for the evade:

we know that victim skill should play some role (like attacker skill somewhat like 0-10%, maybe a bit better - "the force is stron in this one"-like)

target size does play a role, but do we need it full blown or is ist sufficient to know
- fighter size
- corvette/hauler size
- frigate size or larger

how does speed affect "evade"? does it help do be fast on the straights not to be grilled? what classifications do exist ? does one use sqrt(speed) like gazz said?

nimbleness seems easy to classify
the most nimble M6 turns 24 and almost every fighter turns faster than 26 - looks like two classes. this will maybe outbalance some M4s and most M5s, but they are not decisive anyway. maybe add a class for turn rates below 2 instead (M1, M2 and TL's)

[Gazz]

we know that victim skill should play some role (like attacker skill somewhat like 0-10%, maybe a bit better - "the force is stron in this one"-like)

Good point.
Evasion skill should matter more for smaller ships?

target size does play a role, but do we need it full blown or is ist sufficient to know
- fighter size
- corvette/hauler size
- frigate size or larger

There are more classes, of course, but these seem to be the most likely for being useful for our purposes:

• huge ship (M1, TL, M7...)
• Big ship (M6, M8)
• little ship
  • fighter
  • fighter drone (all 3)
  • freighter (TS + TP)

how does speed affect "evade"? does it help do be fast on the straights not to be grilled? what classifications do exist ? does one use sqrt(speed) like gazz said?

IS it means that ships strafe more. AI ships do strafe - just not intentionally like the player. They drift which basically has the same effect.
The faster a ship is, the longer it takes for the drift to decay or rather, the higher is the scale of the drift vector.

sqrt(speed) probably won't be useful here.
I was talking about bullet speed and when you have a range from 300 to 7000 m/s, any linear scale is pointless.

Ship speeds are far closer together so maybe something simpler will do.
Or something based on the average speed of it's object class.
That will be even closer together.

nimbleness seems easy to classify
the most nimble M6 turns 24 and almost every fighter turns faster than 26 - looks like two classes. this will maybe outbalance some M4s and most M5s, but they are not decisive anyway. maybe add a class for turn rates below 2 instead (M1, M2 and TL's)

Turn rates are unknown to scripts. Only top speed is usable.
(Object size at a small one-time cost of CPU time)

[MutantDwarf]

What's the highest turn right on a fighter? If it's low enough, we could probably just make turn rate the percentile chance the ship will evade - 2%-ish for huge ships (I don't know about you, but I've never had any trouble hitting capital ships, and I doubt the AI does, either), around 25% for corvettes, and more for fighters. Speed and turning rate generally go hand-in-hand too. Maybe average[sqrt(speed),turning.rate]?

I already have a library for that. Calling another script just means a lot more organisational overhead than one line.

My point was you don't need a library for it - you could use a single line at run-time (with size precalculated and stored as a local variable) or three lines to calculate it at runtime, though that's probably not a very efficient idea.



I still think amount of damage done should be based on chance to hit - since these are thirty second turns, the chance that no hits are scored should be nearly zero, so some damage would get done. This isn't really a problem in NPC-NPC combat - over the long run it'll still work out correctly - but for Player-involved combat I'd want it to be slightly more realistic, even if it costs some extra overhead.

[wyvern11]

nimbleness look and feel is like (seen fromt the front guns of a tiger)

- very easy to hit caps and big ships (estimated miss rate < 5%)
- still easy to hit M3 (estimated miss rate < 20%)
- more difficult to hit M4 and M5 (estimated miss rate about 70%)

should feel the same oos too

@ mutantdwarf - see no necessity either to get a scale model size calculation - just leads to discussions : my tiger always attacks heads on - slim silhouette. your phoenix is broadsided - broad silhouette

@gazz a colleague of mine is a sailor by hobby - he told, that sailing craft always have right of way on sea - now try to argue right of way with the "nimitz" - nearly no evade on a huge ship

concerning speed: compare 300-7000 to 30-600 (not counting starburst etc.) - same factor ?

[Gazz]

My point was you don't need a library for it - you could use a single line at run-time (with size precalculated and stored as a local variable) or three lines to calculate it at runtime, though that's probably not a very efficient idea.

It's what the library does (or prepares).
My whole point was: ship size in m is available but at a small cost during the setup phase of a ship. End of point.
It's far too early to tell me what variable to write where and when in the script... because there is no script, yet.

@ mutantdwarf - see no necessity either to get a scale model size calculation - just leads to discussions : my tiger always attacks heads on - slim silhouette. your phoenix is broadsided - broad silhouette

"size" as scripts use it tells nothing about a ship's target profile.
It's the radius of an object's bounding sphere.
See here.

The question is whether this actually makes any difference versus using the object class like fighter or huge ship.

@gazz a colleague of mine is a sailor by hobby - he told, that sailing craft always have right of way on sea - now try to argue right of way with the "nimitz" - nearly no evade on a huge ship

There are nautic laws and there is basic self preservation... =)

concerning speed: compare 300-7000 to 30-600 (not counting starburst etc.) - same factor ?

Basically, yes.
However, I was thinking about something like
huge ship = heavy lasers = 40 - 120 m/s
big ship = medium lasers = 92- 175 (Springblossom 360...wtf?)
small ship = light lasers = 100 - 600 (freighters can be slower but they are easy targets so who cares)
(some hit probabilities for fighters on page 5)


So every laser class has a corresponding target class.
The speeds in that class don't vary nearly as much.
I think an avoidance bonus could be based on that alone - maybe a different one for the 3 target classes?

A laser shooting at a bigger class would practically always hit and a laser shooting a smaller class practically always miss.
Something simple like hit % * 3 if shooting at a bigger target, 1/3 if shooting at a smaller.

PPC trying to hit an M5 would be 1/3 * 1/3 or 1/9.

[pelador]

Minor point.

May need to consider mines as seperate or ignore hidden objects? As in relation to the use of mines if pre-emptive strikes are made OOS at range it may simply remove them from the game OOS rather than them having any impact at all. But then again don't want to remove possibilities of counter-attacking mines either.

My point in short is: mines to remain usefull OOS.

[Gazz]

May need to consider mines as seperate or ignore hidden objects? As in relation to the use of mines if pre-emptive strikes are made OOS at range it may simply remove them from the game OOS rather than them having any impact at all. But then again don't want to remove possibilities of counter-attacking mines either.

My point in short is: mines to remain usefull OOS.

By Reunion rules, mines are allowed to be detected at 4000m. (not sure about TC)
Their maximum blast range is 1620m. (= 0 of 75000 damage)
They trigger at 700-800m.

Mines are a very special problem because against fighters they are either the most destructive weapon there is... or completely useless.

In vanilla X3 mines are no targets. Actually, a fighter can not possibly attack a mine. If it it is ordered to it stops dead because it's follow instruction (to get there) permanently freezes.
MARS drones are the only ships in TC that can directly attack mines. (not counting turrets - which can)


So even if fighters somehow detect mines - without massive changes to their fight scripts they can neither fly around them nor attack them from beyond the blast range.

I just don't know what mines have to do with preemptive counterfire.
Mines do not pick targets and flyto/attack ships.
They just blow up.

[pelador]

Sure.

My point was more an issue of ships attacking mines at distance with mines not having a valid counterattack until they get within the detection range.

But if fighters cant even recognise them anyhow and turrets etc simply dispose of them. Its pretty black and white I would think and can appreciate if your hands are tied in some areas.

The pre-emptive model means that weapons could treat the mine (a ship target) in advance of getting into proximity to the mine. Thus a danger of an OOS model simply rendering them obselete if not considered. So I was merely hoping that the model you are investigating could in some way cater for them?

[Gazz]

If you can tell me what script a mine uses to attack a fighter, it can be done.

Until you do that, it's not happening.

[wyvern11]

So far I'm thinking of something terribly simple like
$Rand = random number from 75 to 125
$Damage = ( $Damage * $Rand ) / 100

this means some kinda hit is always scored. let me just give an option analog to yours:

we might use the object-class-modifier value to scale $Rand:

say the modi for big gun hitting fighter is like 0,05 (I use a small value that it becomes more obvious)

$Rand = modi * $Rand = random number from 4 to 6

this gives fighters a chance to survive a salvo of artillery

@gazz concerning size it was clear to me that there would be no lenght/width/height
but it is still not better to approx a stick of given length by a sphere of same diameter than using object class - we should settle for ob-class

and laser classes corresponding to these, that is

[Gazz]

$Rand = random number from 75 to 125
$Damage = ( $Damage * $Rand ) / 100

this means some kinda hit is always scored. let me just give an option analog to yours:

Yes, there will always be some hit. There has to be.
50 fighter drones will not be able to keep an M2 busy forever.

I was basing this on the assumption, that Light.Laser.DPS of the attacker already was the average DPS that would hit the average fighter.

8 HEPT (75000 DPS in theory) on a high-skill ship might create a Light.Laser.DPS of 40000.
This is then modified (somehow) by the avoidance bonus of the defender.

Shooting these Light Lasers at a 500m/s M5 might result in a DPS of 5000 and for a slow Falcon it might be 40000.
If shooting Light Lasers at a Medium Target, you'd get a plain damage bonus again so the same Light.Laser.Battery might do 60000.

This way I'm working with one number only. The adjusted damage.
Just have to make sure the boni are capped somehow so IRE shooting at an M2 don't get a 300 % damage bonus or PRG/Flak get stronger than "real" medium lasers. =)

Especially Fighter vs Fighter combat would be pretty brutal resulting in near instant kills. 8 HEPT firing for 30 sec = 2.2 GJ on paper.
(Laser energy does not exist OOS...)

we might use the object-class-modifier value to scale $Rand:

say the modi for big gun hitting fighter is like 0,05 (I use a small value that it becomes more obvious)

$Rand = modi * $Rand = random number from 4 to 6

this gives fighters a chance to survive a salvo of artillery

We may be saying the same thing but I don't know what you're getting at. =)

I'm trying to get this down to one damage roll instead of separate to-hit and damage rolls.
Separate rolls are far easier to design, of course but the combined system would be half the workload at runtime.

@gazz concerning size it was clear to me that there would be no lenght/width/height
but it is still not better to approx a stick of given length by a sphere of same diameter than using object class - we should settle for ob-class

and laser classes corresponding to these, that is

I don't see any added value in using size, either.
Object class it is.