Split: Re-scaling experiment

[Cody]

... and, at least I, cannot put the time it needs in order to do it.

Time is also a factor for testers such as myself. My daily game-time is increasingly limited lately, and it's already split between trunk, this, and Ship Config (not to mention Song of the Labyrinth). Trunk tends to get chosen more often as I can simply play my normal game (when the RNG lets me, that is).

[Redspear]

...we've had feedback that it seemed to be all good so far, then we've found out that the attack AI in the test builds was not functioning as it should, yet nobody had noticed.

While I've got my 'thinking cap' on, what are the distance parameters that typically affect AI?

IIRC, there were a lot of actions dependant on beam laser range (the typical non-player combat armament)...
Scanner range would be important of course, considerations for mining and cargo scooping, sun-skimming.

Can't remember if I slowed cargo pod tumble or not but I did adjust mining and sun-skimming.
So, I suppose I need to better understand combat AI behaviour like sniping. Can it really be as simple as tuning the AI to match the new laser ranges???

[another_commander]

It's been a while since I last looked at the rescaling code but from what I can recall, the problems were basically related to decisions being made by the AI based on hard-coded range values. So an AI might decide to break their attack and do something else under certain conditions or switch to a different combat tactic if and when the distance to target is, for example, less than 5000m. Of course, with the laser ranges revised under the scope of the rescaling experiment, such decisions would have to be revised too. The tricky part is to skim through the source, find all such areas where decisions are made and swap the hard-coded value with a constant that would be defined at compile time.

[Redspear]

...from what I can recall, the problems were basically related to decisions being made by the AI based on hard-coded range values.

Thanks a_c.

Well, that's kind of good news in that the 'fix' is likely to be tedious to implement rather than difficult.
Using a search function in shipentity should be a big help to tracking them down. Probably not today but that's something I should be able to progress with.

[Redspear]

On a completely different note, after some casual browsing through the source, it appears that we have many cases in ShipEntity.m behaviour implementation methods, where range values are hard-coded and we have not changed them at all so far. This means that certain AI behaviours, including attacks to target, may not be working as intended in the two test builds posted so far. Those range values should be all adjusted accordingly, most likely to 1/3 of their original values and should probably be not hard-coded as magic numbers, but as interrelated constants instead (if possible). An example of this is in the behaviour_attack_sniper method, where we see code like

Code: Select all

if (range < 15000)
{
	behaviour = BEHAVIOUR_ATTACK_TARGET;
}

I finally got a chance to look into this and (as suspected at the time) these issues had been at least partially addressed in the earlier Dizzy builds, but had somehow slipped the net for the latest one.

The very line that a_c uses as an example above was one of the ones I caught in 2014 here under 'Part III: Ship Rescaling', line 4734 as it was back then. It seems I forgot to add them to the last version.

The good news re ShipEntity.m is that whilst there are 548 instances of the word 'range' and 126 instances of 'distance', they nearly all reference things that are already set, namely weapon range and scanner range.

There are some exceptions of course and I'll list (hopefully) the main ones here:

• 5042 standard attack range - as per a_c's listing above, addressed in the Dizzy builds
  4703 minimum sniping range - was also 'fixed' in the Dizzy builds
  5279 mining distance - another one that was caught in 2014
  13906 search for nearest station - again, identified two years ago

There are others but it gets a little more complicated here. For example, some ships are the same size as before and some are only a third of the size so we might expect slightly more variable behaviour depending on the circumstance.

There's some stuff to do with turret lasers around line 5200 that might need reviewing and a_c has already caught some of the plasma turret tweaks.

So it looks like a simple case of my not fully updating the old 2014 version, sorry folks

Good news is that the above lines, when adjusted to the values give in the post I linked to above, should provide at least a serviceable 'fix'

[Redspear]

Hmm...

Looking at my patch provided in March earlier this year, the above tweaks to shipEntity.m all seem to be present.

That would appear to explain why I hadn't observed any abnormalities as I'd aleady made the relevant code changes.
Did they however somehow get lost for anyone else testing this?

Were strange AI behaviours actually observed by anyone? ...besides the one's I explained on account of oxp compatibility up thread.
I appreciate I may be straining the memory banks with it being some 7+ months ago

[Redspear]

Did some more testing on laser ranges and tried something a little more extreme:

Range = standard / (2 * 3)
Or in other words, a sixth of their ranges in the standard game.

As a reminder, ranges need to be shrunk by a minimum of 2 in order to work as expected with regards to the scanner, while a factor or 3.3 is the minimum in order that no ships appear smaller during combat than they do in the default version of oolite.

So I combined the two factors that I've used throughout this experiment

• 2 for lane length, station orbit and scanner size... plus some ships
• 3.3 (or 3 when it makes the maths easier ) for planet size, sun size and the extreme value of shrinkage e.g. cargo pods and some ships

Results

Good: Beam laser range was such that you could expect to recognse the ship you were firing at.

Not so Good: In a cobra mk III you could often simply outrun an aggressor before it could even get in range to fire.
Those that did get in range were using injectors.
The resulting masslocks were extremely tedious as they were both very safe and very, very slow.

So, if 6 is too much and 3.3 is preferable over 2 then perhaps something like 4.5 is worth a try for my next test.

Meanwhile, I have also been using 6 as the sun distance modifier and am very happy with that value so far - more testing required however.

[Disembodied]

(shifting discussion from Screenshots thread)

This, though, makes me wonder if a rescaled game would need to have a different approach to asteroid mining … you might have done this already, Redspear, but if not, it seems a bit crazy to me that shooting this asteroid a few times would cause it to break up (or to vaporise altogether). Maybe, for rescaled asteroids, shooting them with ordinary lasers should do nothing except to produce a small explosion on the asteroid's surface every now and then, for visual effect only.

That's a good point and one I was reminded of upon shooting the very asteroid you see on the previous page.

A few considerations / clarifications:

• Relative to the cobra, the asteroid is actually only twice as big as before
• Asteroids needn't be solid masses of course and 'destroying' them might not be as impressive as it sounds
• Boulders are at half size and splinters at 1/3 (so that even the smallest ships can scoop them)

Boulders though make a nice 'stepping stone' between asteroids and splinters. It might be nice it any 'destroyed' asteroids simply broke up into boulders (unless hit by a missile perhaps) wheras boulders would be destroyed unless using a mining laser.

I do like your suggestion of non-mining lasers being ineffective however and it might make sense given the very high intensity, short duration damage that the mining laser can inflict. Given that asteroids are fairly big anyway there's a case for such a change to the core game. More realistic and impressive but sadly restricting a new pilot from the easiest bounties and target practice out there.

Part of rescaling should involve a change to how certain rescaled objects behave … a massive rock should behave differently from a small one. I take your point though about restricting new pilots from easy (if tiny) bounties and target practice, though. Maybe what's required is to differentiate between something big enough to hollow out and live inside which would require serious ordnance to destroy and which, if blown up, would create large amounts of hazardous debris - and smaller pieces of rocky debris which could believably be destroyed by players.

So maybe the game needs a new class of object, above the asteroid: the planetoid. These could be rarer, and used for rock hermits (although there should also be uninhabited ones as well). Shooting one of these with a pulse, beam or military laser does nothing: they're simply too massive. There would be a flash, and maybe once in a very rare while a splinter, but that's it. Shooting one with a mining laser would break off boulders and splinters. Doing this to an inhabited planetoid would definitely be an aggressive act, though. Finding and tagging uninhabited planetoids, and selling their locations, could be a new source of income: nothing huge, but still: it could provide a useful bonus for beginners. It would allow players to physically change the game world in a purely cosmetic but still quite satisfying way: being able to discover a new rock and to come back again some time later to find a new hermitage set up in it, mining away, would be quite satisfying. Some sort of claim-stake device might be necessary: a pylon-mounted something, launched into the rock, to verify exploitation rights. (If we could also make it possible for the discovery process to include naming rights, that would be a bonus.)

Normal asteroids, at maybe half the size they currently are, would still be part of the game, too, as feedstock for miners and target practice/bounty fodder for new players.

[Redspear]

Part of rescaling should involve a change to how certain rescaled objects behave … a massive rock should behave differently from a small one. I take your point though about restricting new pilots from easy (if tiny) bounties and target practice, though. Maybe what's required is to differentiate between something big enough to hollow out and live inside which would require serious ordnance to destroy and which, if blown up, would create large amounts of hazardous debris - and smaller pieces of rocky debris which could believably be destroyed by players.

Well, there are certainly some options here.

With a space lane proportionally twice as long as before and planets 3.3 time bigger there is effectively 6.6 times as much space to travel through. I could make asteroids 3.3 times bigger than the one in the screenshots thread and they still wouldn't be any bigger relative to the planet than in the standard game.

Simple idea for 'tough' asteroids:

• Very high regeneration rate - rendering pulse and beam damage inconsequential
• Relatively low energy - so that a hit from a mining laser or a missile would still break it up

A military laser on the other hand might be able to break it up with sustained fire (the regeneration rate would need to be just so).

Perhaps I can create a 'big' class of asteroid that breaks up into 'big' bolders in turn breaking up into regular boulders. Or even big asteroids breaking up into regular asteroids. I'd need to find where such 'death actions' were set but that would seem to be easy enough.

The planetoid idea is quite nice but I'm reluctant to include anything that's visible from long range (besides planets, moons etc.) as it tends spoil the illusion of my having created even more space than I actually have. Planetoids would absolutely fit into the class of entity I've parenthesised in the previous sentence but then if they're visible from long range then getting there first would seem unlikely from a player point of view.

Thanks for your thoughts.

[Disembodied]

Perhaps I can create a 'big' class of asteroid that breaks up into 'big' bolders in turn breaking up into regular boulders. Or even big asteroids breaking up into regular asteroids. I'd need to find where such 'death actions' were set but that would seem to be easy enough.

Hmm … that's an option, but it does make it somewhat like the old Atari Asteroids (which it is, a bit, already, I admit!). I like the idea of some objects being just too big to be destroyed by the player (barring the use of mega-weapons, or prolonged bombardment), while still being small enough to be flown around and treated as a piece of local architecture (rather than, say, a planet or a moon). A good-sized asteroid that you can imagine being used as a small space station, that ships and habitats can credibly fit inside. I think one of these large rocks should have station-like levels of invulnerability - although they might generate splinters from time to time when hit by mining lasers.

The planetoid idea is quite nice but I'm reluctant to include anything that's visible from long range (besides planets, moons etc.) as it tends spoil the illusion of my having created even more space than I actually have. Planetoids would absolutely fit into the class of entity I've parenthesised in the previous sentence but then if they're visible from long range then getting there first would seem unlikely from a player point of view.

Yes, good point!

[Redspear]

Hmm … that's an option, but it does make it somewhat like the old Atari Asteroids (which it is, a bit, already, I admit!)

True

I like the idea of some objects being just too big to be destroyed by the player (barring the use of mega-weapons, or prolonged bombardment), while still being small enough to be flown around and treated as a piece of local architecture (rather than, say, a planet or a moon)

OK, so how about 3 sizes of asteroids:

• Small - as per standard game, anyone can mine even by 'getting lucky' with a pulse laser
• Medium - as per recent screenshot, mining lasers only
• Large - 3 times larger than screenshot, maybe a missile (or a few missiles) can do it but non-destructable by standard lasers

Is your boat floating yet?

[Redspear]

I'd need to find where such 'death actions' were set but that would seem to be easy enough.

Shipdata.plist

I like it when things are where you'd hope to find them

[Disembodied]

OK, so how about 3 sizes of asteroids:

• Small - as per standard game, anyone can mine even by 'getting lucky' with a pulse laser
• Medium - as per recent screenshot, mining lasers only
• Large - 3 times larger than screenshot, maybe a missile (or a few missiles) can do it but non-destructable by standard lasers

Is your boat floating yet?

That seems sensible! Of course, if hermits are to be found in large rocks, then this will make them easier to spot from a distance … that's maybe not a huge problem, though: it's often quite easy to find a hermit from a distance anyway if you can spot the laser flashes of mining activity. And it's not as if visiting a hermit is any kind of huge advantage: allowing and even encouraging a bit of small-profit, in-system local trade has potential for helping beginning players.

[Redspear]

Of course, if hermits are to be found in large rocks, then this will make them easier to spot from a distance …

A major motivation for the rescaling was to stop things being visible from very far away. Torus stations that you can see from the witchpoint, Black Monk Monasteries visible from almost anywhere and even main stations that look like small moons (optional star wars quote here).

The good news is that with planets 3.3 times bigger and a spaceline twice as long (approximately), I could make an entity up to 6.6 times bigger and it would be no more visible on the spacelane than before; up to 3.3 times bigger and it would look no bigger next to a planet.

Combine that with the fact that the cobra mk III has been shrunk by half and it means that an asteroid could appear 12 times bigger relative to the player ship without being any more obvious on the spacelane. I think 6.6 times bigger might strike a good balance however.

I'll see if I can post some pics soon.

[Disembodied]

Oh, excellent!