OOS combat - how SHOULD it work?

[wyvern11]

lets see if I understand correctly:

round : 30 sec

example :
M2
- heavy artillery -> primary attack, no CF ever,
- med artillery -> 20 sec CF - leaves 10 sec (1/3) for primary attack
- light lasers -> 30 sec CF - nothing left

- h. art. sum of all guns damage say 600k , hit prob say 20 % on a capship ---> expectancy 600k * 0,20 = 120k per round (half of this actually due to turret obstruction)
- m. art. sum of all damage 100k , hit prob say 50% on a capship, rest analog
- l.las analog

where does the randomization come in?

saw my structuring efforts above?

[Gazz]

A ship with 24 PPC (at 17 %) would have 190.000 DPS (shield damage)
Half that = 95.000

So 30 sec of fire are 2.8 GJ.

Hmm. Feels a bit on the high side (because it's one turn) but it's actually low for an in sector fight...
Very little can stand up to an angry M2 for even 30 seconds.

A one on one fight between M7 and M2 would practically always result in a win for the M2. And frankly - why not?

Randomisation would come in when the ship actually fires.
The setup phase only determines the base damage vs the generic target.
Since damage is already corrected for skill, the randomisation can always work the same way.

[wyvern11]

aahh just the declaration phase - 2,8M is OK, this means combat is not much slower than regular oos but not so completely arbitrary

frigate size weapon : like 16 CIG , rate 33% (guessed) --> 16*9,8k*0,33/2 = 26k
makes 790k in a round

of course it would at least take a salvo before closing in

three to four frigates to a destroyer would stand a chance - looks like a good balance to me
just from the numbers.

EDIT: corvette size craft like 7-10 med lasers - roughly 400k - so bring 8-10 M6 if you are able to control and be prepared to lose 2-3

still a good balance


having a generic randomizer sounds good to me - no hassles that it disadvantages a given shiptype

[semiliterate]

can you sell this to Hasbro?

[wyvern11]

@ gazz

what are you up to?
everything discussed?

i'd like to lend a hand !!

[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.