Split: Re-scaling experiment

[Redspear]

More on both lasers and masslock this time:

After some more testing, the 'saving' of 5 minutes average masslock time might be a bit generous. 2-3 minutes seems a little more likely (still quite significant) but the standard game can throw up some epic masslocks which can also overlap. In testing there was one masslock of 12 and a half minutes from just a single ship

This is rather tedious to test of course. I think I've done enough to satisfy myself that a smaller scanner is a good idea, at least with regards to masslocks.

Meanwhile, I've solved the laser range 'issue'. It was behaving exactly as in the default game - it's just a feature of oolite

Quite nice that the player can often run but not so nice that ships of equal or even slightly faster speed just follow you indefinitely being too cautious and/or inaccurate to really trouble you. In a safe system you might run into police but the game is running at snails pace until you do.

If that's the accepted ship behaviour then I'm inclined not to mess with it for now (I imagine it improves significantly once the player has a rear laser). Instead I think I'll return to one of my earlier tests of 1/6 laser range which appeals to me 'on paper':

Divided by 3 to match scanner and smallest ship sizes and divided by 2 again for more dogfighting type gameplay with improved visibilty of ships. All ships would need to come twice as close proportionally in order to be in range.

• Fighters approx twice as big on screen
• Fighter traders approx 3 times as big on screen
• Freighters approx 6 times as big on screen

Sounds good to me. Testing and screenshots to follow...

[another_commander]

Really appreciating the effort you put in, Redspear. I hope we will be able to merge your experiment at some point, once your one-man-test has confirmed that no negative gameplay side-effects exist.

[Redspear]

Thanks a_c, that would be great

More to do in the meantime but I'm hoping that I can move on from lasers soon.
Trouble is, I keep having ideas of other ways to do things that may or may not be better...

For example, if laser strength is the same regardless of ship then might it be interesting if larger, slower vessels could equip lasers with longer range? After rescaling they are (sometimes significantly) larger targets as well as often being slower ones so it need not be particularly unbalancing. A potentially interesting gameplay dynamic could develop as you'd have to weave into range of the larger ship, or flee with as much care and urgency as possible.

On a more immediate note, is there any reason why

Code: Select all

if (range < 15000)

couldn't be rewritten as

Code: Select all

if (range < weaponRange)

or even

Code: Select all

if (range < weaponRange/2)

[Redspear]

Bit of testing done at 1/6 laser range.

Early asessment: Brutal

At that range, with the current settings, the ships are very accurate once you turn to face them. I got some pics but it was hard to get really good ones and survive. That and photobucket slowing my system to a standstill anytime I want to upload anything (any low spec alternatives anyone can recommend?)

The ships did look bigger but it was only particularly appreciable with the larger vessels (which were effectively at x3 to x6 size). I took on a solitary python, running at it and then attempting a quick turn. That first jousting run was short and punishing, with only a pulse laser against the python's beam it was not a good strategy. Fancying a quick turn to attack from behind I discovered that the now much larger python could turn almost as fast as the cobra.

Injectors could make it intersting of course but can also mean that when a vessel decides to close on you from behind it can deliver devastating damage as I discovered with a Krait that resulted in a PSC* moment.

Early conclusion: Too close

Whilst accuracy could be reduced at that sort of range the question presents itself how often should they miss?
The answer is probably not that often and when in packs they can be lethal, even when I did have a beam laser.
Larger vessels are tougher at very short range where their large size seems to be very well compensated for by their larger energy reserves. Without injectors many more shots are finding their mark, even it seems on the snmaller targets.

Combat was more exciting however so the prospects for a compromise at this stage are good

* Press Space Commander

[Redspear]

There's been some talk about the military laser lately and whether or not it might be a good idea to reduce its range or damage or both.

I think I'd like to reduce its rate of fire.

At present the lasers are only immediately distinguishable by their colours, if the military laser was to have it's rate of fire reduced slightly then that would make lasers distinguishable by fire rate:

• Very Slow - Mining
• Slow - Pulse
• Fast - Military
• Very Fast - Beam

It could also mean that most of them sound a little different too - the military laser could sound like it had a little stutter. No need to ditch the lore of the military laser being twice as powerful or long range as the beam laser, simply adjust the damge accordingly. If, on the other, one did wish to deviate from the lore then neither of the other options have been lost.

Should add a little more flavour to the laser selection and effect on balance could be negligable if one so wished.

If I remember I'll add it to my next test.

[another_commander]

I don't think that rate of laser fire is directly related to the rescaling experiment. It's fine if you want to experiment with it, but if it comes to merge the rescaling stuff, then we'd want to merge the rescaling only, not any other parallel experiments.

[Redspear]

Understood. I think the only relevance is that I'm testing combat at the moment and it can be added in with negligable effect (e.g. from 0.2 instead of 0.1 fire rate and 24 damage instead of 12 - total damage with each 'burst' will be either the same, +12 or -12 and on average the same). Besides, that's the sort of thing that can be played with purely in oxp.

Meanwhile, from what I'm understanding of ShipEntity.m there are two ranges that appear to be key and also would seem to have some assumptions attached to them.

The first is pulse/mining laser range. This is set specifically (i.e. as a number) and appears to have the assumption attached that it will be the shortest weapon range that an armed ship could have.

The second is beam laser range. Again it is set specifically and apparently with the assumption that it will be the range within which most combats will occur. This leads to a possible further assumption that beam laser range should not be less than pulse/mining laser range.

Given that the military laser has a range of twice that of the beam laser there also may be an assumption that the military laser will have a greater range than any of the others. (EDIT: and it may not be set by number due to the assumption that it has the reach of the entire scanner).

There's an awful lot to ShipEntity.m and I'm a long, long way from understanding it all but I appear to be playing with the most relevant parts... fingers crossed.

[Redspear]

Ok, so if 1/6 was too much then what about 1/4.5?

Well, I think it was better.



Not a great picture but you can see I was taking damage vs 2 mambas and a moray. In the end I paid for chasing down that mamba rather than letting it go and had my PSC just before the second mamba cracked.



It was quite nice that rather than just getting ripped apart (as seemed to happen at 1/6 range), although I was still beaten, I was left thinking of ways I could have played it better. That could be quite nice but might also be too tough on beginners. The overriding impression was still that at short range, beam lasers can be lethal.

Later, I took on a python and a moray which started going very well but then I either got a bit cocky or the moray suddenly got serious when I destroyed the python. Again, PSC.

I'm tempted to bring beam lasers down to pulse laser range (instead of the other way around) and then divide by 4 rather than 4.5 for a similar result. The main advantage to this would be simply to make it easier to juggle the various figures in my when imagining the 'big bicture' of rescaling.

Meanwhile, another nice feature of the rescaled scanner:



This picture shows the distance needed from the station in order to hyperspace.
Just before the station leaves the scanner - not bad.

On masslocks again, the shorter times (and distances) required to escape masslocks also make the fuel injectors a little more efficient when used for this purpose. Previously I'd always want to use them but think it highly risky and usually not; that might sound like strategy but where the victor is boredom I'd consider the outcome unsatisfactory. In this build however whilst I don't think they could be used indiscriminitely, in most systems using them to escape the slower masslocks shouldn't cost you too much fuel and therefore make more strategic sense.

[Redspear]

Found at least one instance in ShipEntityAI.m where combat range is specified numerically (line 383) with one or two other candidates in there that might need updating (e.g. line 1297).

Thinking some more, anyone who played the first version of this experiment (Dizzy's builds) will have been playing with reduced laser ranges but those who played the second one (a_c's / kanthoney's patch) would not.

Ship speeds are at 0.5 in both versions but laser ranges at 0.33 in the first and 0.5 in the second.

• First version had similar appearance to default game (fighters 0.33 size at 0.33 range) but was closer to a dogfighting experience (0.33 distance closed at 0.5 speed).
• The second was more faithful in experience (0.5 distance being closed at 0.5 speed) but fighters would appear smaller (0.33 size at 0.5 distance).

First version felt good: not too different from the standard game but the sniping to dogfighting ratio shifted slightly towards the latter. There's also a nice consistency now with the scanner also at 0.33.

What might be nice to try is ranges at 0.33 but with beam laser reduced to pulse laser range. Military lasers at double this range would then not quite reach the edge of the scanner but in such a scenario I'm also tempted to try them at what was the beam laser range.

That would mean mining/pulse/beam range of 4166 and a military range of 5000. Relative to the way most people experience oolite, that's roughly a military laser with only 1/3 range (10,000), a beam laser with just over half of its range (8332), with pulse and mining lasers at 2/3 range (8332).

Such changes would be quite significant and yet milder than the ones tested in the last few posts (at least for pulse and beam lasers). Sniping range wouldn't provide much of a window but then a military laser doesn't need much to take down most ships and giving it a little room keeps this element in the game in some form (which is fair enough I think when the player is often outnumbered).

I've always fancied a sort of cannon laser with low rate of fire but high range and damsge. The military laser doesn't really leave room for that in the standard game due to it's extreme range and fire rate. Could be a nice option for the bigger ships which are now easier targets.

Testing military lasers can come a little later; some more dogfighting to do first.

[Redspear]

I think we may have a winner.

3750 (or standard beam laser range /4) means all of the ships look bigger in combat (from slightly to much) and all close to dogfighting range much quicker. Despite this there is still a chance to take out one or two at longe range if you're very quick. So combat starts 'traditionally' but spices up much quicker.

As for difficulty, sometimes the range is not a major factor:



For a simple trader in Isinor? Really?

[pleiadian]

Okay so... I'm pretty excited about this little project going on here. I'd most certainly try this myself.

I'm not on Windows, but on Ubuntu... so for those using that kind of OS'es, these are the steps/things you need to have and/or do - in this order (if I got that right):

Install the GNUstep library for Objective-C compiler support
Ubuntu users do this with sudo apt-get install gnustep gnustep-devel. Test with a simple Objective-C program to see if you can compile Objective-C code.

Acquire the entire rescale-experiment branch from Oolite's Github
If you don't have git installed, do that now with sudo apt install git. Then create a directory inside which you want to place the rescale code in, and do a git clone https://github.com/OoliteProject/oolite.git ./. This downloads the entire current branch into that directory.

Set up the GNUstep environment so that compiling works
Last time I used GNUstep you can do this with . <GNUstep root>/System/Library/Makefiles/GNUstep.sh or source <GNUstep root>/System/Library/Makefiles/GNUstep.csh, depending on the shell you use.

Compile!
Enter the source code directory in your shell, and type make - this will probably take some time.

Move the finished Oolite.app to somewhere
Self-explanatory

Get the Rescale OXP
To be found here. Install like any other OXP.

See if it works
by playing it

-------------------

Is that basically correct?

[Redspear]

Hi pleiadian.

Thanks for your enthusiasm
Unfortunately, I just play with the numbers and have the crazy ideas, it's Dizzy or another commander who do the git stuff...

An important point in this regard however is that what's currently on github is version 2 of this experiment whilst what's been under discussion for the last few pages or so is a proposed version 3.

Something else I'd like to point out to the casual reader is that the experiment was designed to offer 3 types of rescaling that the prospective user could combine at their discretion.

• System Rescaling - bigger planets, suns and distances
• Cosmetic Adjustments - moving the main station, lengthening the space lane etc.
• Ship Rescaling - this is the gameplay changer with a smaller scanner, reduced speeds and smaller fighters etc.

Sorry I can't be more help.

EDIT: Forgot to credit Getafix re the git-work. Sorry!

[Redspear]

Related to a rescaled scanner, rather than in any way necessary for it, is the idea of altering station bound traffic to make the slower vessels more likely to appear (in an effort to reduce mass-lock frustration).

As I explained over in the Oolite 2.0/II thread, the change was an alteration to,

...their relative probabilities of appearing but not the total weighting (i.e. oxp trader ships would still appear with the same probabilities as before).
No ship has lost a role and no ship has gained one.

Results were quite good at the time:
https://bb.oolite.space/viewtopic.php?f= ... 80#p251016
but I didn't think they were good enough to justify what was in some areas a heavy-handed alteration of probabilities.

Well, I've tried out the ship weighting idea and although it did help, the effect wasn't as significant as I'd hoped. The main reason for this being that the sheer distance required to clear the scanner is considerable.

In the reduced scanner environment I'm currently testing however, a more subtle weighting adjustment may be both viable and unobtrusive. The previous test made, for example, Anaconda encounters much more likely; whilst there are some good reasons why this might be the case, a healthy dose of variety is more fun.

I'll give it some thought.

[Redspear]

Having made the traffic redistributed oxp it combines very nicely with the reduced scanner I've been testing recently. Furthermore, one of my early reservations concerning a reduced scanner has proved to be more of a boon than a curse (at least to me).

At 1/3 standard scanner size it is quite easy to overshoot the station when using the torus drive. At first I saw this as a problem and undesirable. Having played with it for a while now however it is starting to feel like gameplay.

Steering your torus propelled ship towards a station that is now very much dwarfed by the planet it orbits has become, dare I say it, fun. Thrilling, no, it is hardly the planetary landing sequence in 'Aliens' but once I stopped expecting the compass to remain perfectly aligned the entire time then it actually became quite fun; like a much more forgiving version of docking.

Another thing I like is that the larger vessels can sometimes be visually identifiable whilst on the edge of the scanner and at half distance are clearly so. Fighters and smaller vessels meanwhile remain barely detectable It also combines well with the new laser ranges which IMHO make combat a little more interesting.

So with laser ranges set (at least for the foreseeable) and mass-locking improved, remaining things for testing include sun-skimming (which took an age the first time around) and mining with the new asteroids.

If there's anything else someone thinks really needs testing (where my tinkerings are likely to have an effect) then please let me know. Thanks

[Astrobe]

Looks fun indeed. I wonder what happens when one combines my "shaky drives" with this.

Since I can compile from source now, I'd like to give it a try but it seems that the rescaling experiment branches in the oolite github are not up to date?