Split: Re-scaling experiment

[Redspear]

Fair point, so (again, just a suggestion)... reduce the beam laser range to equal that of the pulse laser. And whilst at it, reduce the military laser to be double this new range rather than double the old one.

It would appear to be no less consistent with canon; the exploit highlighted above would be tricky at best; the mil laser might not quite make it to the edge of thr scanner but should no longer overlap it.

Another way (more complicated but perhaps no more so than a condition script would allow) would be to grant less range to rear lasers. Why would they have less range is an obvious question but then so is much about the behaviour of lasers in this game. Possible handwave - it's not the lasers themselves that are less capable of firing to the rear, rather it is the typical laser housings that are mounted in such a position, often with consideration of nearby engines.

Re: plasma shot speed - I have no problem reducing that, I just didn't encounter it during testing.

[Disembodied]

Possible handwave - it's not the lasers themselves that are less capable of firing to the rear, rather it is the typical laser housings that are mounted in such a position, often with consideration of nearby engines.

Or, they're having to fire through the turbulent spacetime from the engine's wake, thus reducing their range and/or power.

[Cody]

Or, they're having to fire through the turbulent spacetime from the engine's wake, thus reducing their range and/or power.

<chuckles> Pretty good handwavium - though would that same turbulent spacetime weaken incoming fire a little?


Hmm... clear space turbulence, the cosmic equivalent of clear air turbulence.

[Redspear]

Or, they're having to fire through the turbulent spacetime from the engine's wake, thus reducing their range and/or power.

<chuckles> Pretty good handwavium - though would that same turbulent spacetime weaken incoming fire a little?

Or... maybe said turbulence interferes more with the stability of a rear mounted laser and so it's ability to target effectively is reduced slightly. Inbound lasers need not suffer the same penalty (the proportional disturbance is significant to the narrow laser firing but not to the much broader ship that fire is being returned to).

Or... maybe it's a terrible idea in the first place... I'm still pondering that one

[Disembodied]

That's the beauty of made-up physics ... first, pick how you want things to work, then make up the explanations!

[cim]

I'd be quite tempted to significantly reduce the laser range - to perhaps the equivalent of 5km or so in normal Oolite? - for pulse and beam, and then make military only marginally longer-ranged. For a game about first-person space battles combat does tend to boil down to pointing at distant lights rather a lot, and the military laser is good enough already without the excessive range too.

It's also, especially since kanthoney's position tracking update for the AI, much easier to survive a close-in dogfight than it is a mid-range artillery match - and it would give players a bit more time to react to pirate demands before they actually opened fire.

[Redspear]

I'd be quite tempted to significantly reduce the laser range - to perhaps the equivalent of 5km or so in normal Oolite? - for pulse and beam, and then make military only marginally longer-ranged.

Yesterday I had a quick play with combining some of the suggestions I made up-thread: 0.33 laser ranges with furthur reductions to beam lasers (and military so that it was still double that of the beam laser).

Double these ranges for their equivelants in the standard game:

• Mining - 2,475 (half the range of the pulse laser)
• Pulse - 4,950 (at that time I hadn't thought of the exploit a_c mentioned above)
• Beam -3,300
• Military - 6600 (double the range of the beam laser)

It was only a very quick play but it was certainly fun.
With the gap between military and beam laser being smaller, ships can (of course) close on you faster if they're able.
Big ships start to actually feel big during combat (some balance implications there but easilly adjusted if I was of a mind).
I expect it would take longer for ships to escape missiles because they were typically closer (and missiles can still reach to the edge of the scanner and beyond).

I was also left reimagining something like the bolt lasers from new_lasers.oxp - there would now be room for double the range of the military laser but with something like the mining laser's rate of fire and power.

That's the beauty of made-up physics ... first, pick how you want things to work, then make up the explanations!

There's a life-lesson in there somewhere

[another_commander]

Here is a proposal for laser range adjustments for the next test build:
Pulse: 4125 (original value 12500)
Beam: 4950 (original value 15000)
Military: 7500 (original value 30000)
Mining: 3000 (original value 12500)

Justification for the military range: The military laser is twice as strong and has twice the range already in the default game. In other words, the step from beam to military is quite a large one. The military laser could probably do with a bit less range and still be a formidable weapon, especially for the purposes of this experiment.

The same justification could be applied for the mining laser as well, although in this case I am just trying to keep it low range mainly for getting ships to have to approach asteroids more, creating an apparently larger scale impression.

Should we give these values a try? They are not too far from what Redspear has already attempted (apart from the swap of ranges between pulse and beam). Any ideas welcome.

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;
}

[Redspear]

One thing to bear in mind is that laser ranges are now oxp-able wheras they weren't when this thread started; so cooking up a few oxps for people to try out is something I could easily do.

With regards to ShipEntity.m... In the previous build I performed a search for instances of 'range' within that file (amongst others) and made adjustments as given here. I dont recall repeating the check when switching to 1.83, so it's quite possible that I've missed a few things.

[Redspear]

How long do you think it should take to get from the main station to the sun, assuming no encounters along the way?
How about four and a half minutes (until mass-lock)?

If that sounds a little long, then consider that's how long it just took me from Tionisle main station, in an Adder.
Consider also that the first two minutes were spent escaping the mass-lock of the station and that the sun_distance_modifier I was using was 25.

By way of comparison, main station to witchpoint (again, unobstructed due to a bit of sideways travel deducted from the clock at either end) took fractionally longer. That doesn't seem right to me, I'd expect station to sun to take significantly longer than station to WP. Now I'm not advocating a 'realistic' time, as this isn't a realistic rescale, but I do think it should feel longer (to the benefit of gameplay rather than to its detriment).

sun_distance_modifier doesn't affect the size of the star, so it's setting (as I see it) is really about three things:

• travel time
• encounter likelyhood/rate
• cosmetics/experience

If x25 isn't at any significant detriment to either of the first two then what of the third?

Zygo Ugo's Cinematic Sky & Nebulas (IIRC) uses a value of x55 which seems to have quite an effect on the lighting of the system (although there are other factors at play in that instance). However, having tried settings of x4, x6 ,x10 and x25 I can't say I recalled a massive distance in terms of overall lighting yet the smaller the value, the more the travel time seemed too short. At x55, the sun really does look distant whilst at x25, it does look significantly further than say x4, but it still looms quite large upon entering the system.

This is all minor stuff of course as it's an easy oxp tweak with no source code alterations required, however, food for thought.

Qualifier to the above: I do have some of my own tinkerings on the go but they shouldn't affect what's been written here (fingers crossed...)

[another_commander]

Is it 4.5 min on max cruise speed, torus or other?

I find that if you increase the planet size by x3, then an increase of the sun distance by a factor of 4 should be OK. In general, there should be more or less similar travel time involved as in the standard game. Increasing it too much creates a lot of dispersion in any traffic positioned in the planet-sun lane. Not necessarily bad, but needs testing.

A note about sun_distance_modifier. Its result is not fixed, but depends on planet radius. The sun distance is basically this factor multiplied by planet radius, so results could differ quite a bit, depending on which system you are testing. Also, a value of x4 is invalid for this modifier. Anything below 6 is invalid and will result in sun_distance and sun_distance_multiplier to be used instead.

Finally, there is one more detail that needs to be taken into account when playing with the sun distance: The Nova mission. Put the sun too far away, and you will find that you now have all the time in the world to leave the station, check your chart, make a cup of coffee, browse the net, read a newspaper and the nova is still growing without any effect on the temperature until much later. Either the sun distance must remain reasonable or the nova mission needs to be adjusted so that temperature rises in the same way it does in the standard game.

[Redspear]

Is it 4.5 min on max cruise speed, torus or other?

It was 2 mins max cruise speed to escape the station mass-lock, then 2.5 mins on torus to be mass-locked by the sun.

A note about sun_distance_modifier. Its result is not fixed, but depends on planet radius.

That much I knew and so mentioned the system but... is it set from the planet or from the witchpoint?

Finally, there is one more detail that needs to be taken into account when playing with the sun distance: The Nova mission. Put the sun too far away, and you will find that you now have all the time in the world to leave the station, check your chart, make a cup of coffee, browse the net, read a newspaper and the nova is still growing without any effect on the temperature until much later. Either the sun distance must remain reasonable or the nova mission needs to be adjusted so that temperature rises in the same way it does in the standard game.

That, I had not considered

[another_commander]

... is it set from the planet or from the witchpoint?

sun_distance is the planet-sun distance.

[Redspear]

Thanks a_c.

[Disembodied]

Is it possible to increase max torus speed on the fly? If so, there could be one speed for travel within WP range of the planet, and a faster Torus speed once the player reaches deep(er) space, allowing you to put the sun further away from the planet but not make it take much longer to get there.

Does that make sense? Basically, there would be normal torus speed if you're within 1.5x the WP-planet distance from the planet, in any direction. Once you get further away from the planet, the torus can accelerate further to turbo-torus speeds - perhaps slowing down to normal torus speeds again when you get to within a certain distance from the star, so the deceleration isn't too abrupt.