Split: Re-scaling experiment

[Cody]

... oxp player ship without having speeds halved...

Yep, that'll be it! My Griff Cobra Mk III has default speed - which I need to halve for this build, yes?
As for the performance hit, the fps dropped to about 50 at times (normal is a steady 75).

[another_commander]

Yep, that'll be it! My Griff Cobra Mk III has default speed - which I need to halve for this build, yes?

You must ensure that the following are true in order to successfully test this build with OXP ships:
For each OXP ship make sure that either:
- It has a like_ship reference to the oolite_template_* core ships. This ensures that it will be scaled down by the required factor and that it will also have its thrust and max speed scaled down accordingly, or
- Its shipdata declaration contains the entries model_scale_factor = X, thrust = <half of the original thrust> and max_flight_speed = <half of the original speed>.

This is the main reason I suggested testing without OXPs first. Adding OXP ships that may or may not conform could potentially skew the test results.

[Cody]

This is the main reason I suggested testing without OXPs first.

<chortles> Oh, I started out that way, but I wanted to run it against heavy assassins, so I grabbed a save and its ship.
So not only do I have to halve Lord Effingham's Revenge's speed and thrust, I've gotta shrink/enlarge it too... ho-hum!

<wanders away, pondering Douglas Adams and errors of scale>

[Redspear]

As for the performance hit, the fps dropped to about 50 at times (normal is a steady 75).

OK, so significant rather than crippling.

So not only do I have to halve Lord Effingham's Revenge's speed and thrust, I've gotta shrink/enlarge it too...

The first of those changes is crucial for any oxp ship to operate as intended here. FWIW, no ships have been enlarged nor should they need to be. The ones that appear bigger in this build have simply remained the same size whilst others around them have been shrunk (I should probably set up a wiki page to try and make this stuff clearer and put it all in one place...).

Using Lord Effingham's chariot of choice as an example for anyone doing similar, adding the line...

Code: Select all

model_scale_factor = 0.5;

to it's shipdata.plist file should scale its model down nicely (including any subentities).

Adding OXP ships that may or may not conform could potentially skew the test results.

There's also a bunch of non-ship oxps that could be a 'bad fit' for this build in its current incarnation. So yes, I'm afraid that oxps, generally speaking, are probably best avoided for now.

[phkb]

Adding OXP ships that may or may not conform could potentially skew the test results.

Thinking about the future and the possibility of making this project an OXP, what's the possibility of making model_scale_factor a writable property after the game has loaded? I'm just thinking that, if there was a scale_factor put into script_info of the ship model, the Re-scaling OXP could pick up that number and apply it to all instances of that ship during systemWillRepopulate or other events, thereby allowing a single ship OXP that will work both with and without the Re-scaling OXP. thrust and max_flight_speed are already writable.

[Redspear]

Thinking about the future and the possibility of making this project an OXP...

I'm not really qualified to answer this of course but there are quite a few things that are currently writable only in the source, so for this to be an oxp option is currently quite some distance away, and may be likely to remain so.

In terms of oxps integrating with the experiment however, a mehod such as the one you have described could be useful. As you say, maybe something for the future.

Thanks.

[Redspear]

A rather embryonic wiki page has been created to try to sumarise the experiment. [wiki]Rescaling experiment[/wiki]
I'll tidy it up when I get a little more time.

Meanwhile if there are any glaring errors or breaches of wiki ettiquette then please point them out.

Thanks.

[Getafix]

Would it be possible to have a linux version?

(I understand it could need too much work at this stage.)

I am working on it. If not today the latest by Sunday I will share a link here.

[Redspear]

Thanks Getafix!

[Getafix]

The Linux setup files for rescalingExperiment2 branch are ready.

This is a normal Oolite installation and as such
it will UNINSTALL your existing Oolite installation
and will use and/or overwrite, where functionally possible, your existing AddOns, oolite-saves and Logs contents.

BACKUP YOUR EXISTING OOLITE INSTALLATION, ADDONS, OOLITE_SAVES AND LOGS BEFORE YOU PROCEED

Now that I got your attention... feel free to use the following link at your own risk.
Linux setup files for rescalingExperiment2

[kanthoney]

Probably should mention that if you don't want to uninstall your existing installation and are happy building from source, you can check out the rescalingExperiment2 branch from Github, then build and run that in the usual way. You should back up your savefiles first, just to be safe.

[another_commander]

Looks like we are going to have a Build 02 going on-air sometime tomorrow (hopefully), which will contain the following changes:
- The fix for the crash related to the Smugglers OXP.
- The weapon range changes discussed by Redspear in this post.
- An experimental change of all sun distances by a factor of 4. This seems to be pretty good and doesn't seem to do harm to gameplay. It can be adjusted in subsequent iterations if deemed not satisfactory enough as it stands.

[another_commander]

Build #02 of the Rescaling Experiment for Windows 32/64 bit is out:
Oolite Rescaling Experiment - Build 02 - x86/64
VirusTotal Report

Changes from Build #01:
- Some turret and weapon ranges adjustments to x0.50 rather than x0.33. The question whether weapon ranges should all return to x0.33, as per Redspear's suggestion here is still open for discussion.
- Fix for crash when trying to modify market goods on a nil station. It should now work with Smugglers OXP.
- Suns are now four times further away. It should make sun skimming look kind of more normal than before.

Thanks for your testing and feedback. Looking forward to your opinions on this one.

[Redspear]

Thanks guys!

The question whether weapon ranges should all return to x0.33, as per Redspear's suggestion here is still open for discussion.

I might try out some compromise values if I get the time and see how well they work...


Edit...

Looking at shipdata.plist:

• Only 2 entries have military lasers, the constrictor and the viper interceptor, both scaled at 0.4 (the thargoid warship's laser has a lesser range)
• 13 entries have beam lasers, 6 of which have been scaled below 0.5
• 11 entries have pulse lasers, 5 of which have been scaled below 0.5

Unless a serial offender in high tech, 'safe' systems, the player is most likely to be engaged by beam lasers, which are more likely to be posessed by pirates, hunters and police (as is the case with the standard viper). Pulse lasers are often posessed by traders and so players fond of their piracy might meet some of these a little more often than might otherwise be expected.

Current laser ranges in this build (half the values of standard oolite):

• Military - 15,000 (which, IIRC slightly exceeds the scanner range in both this and, proportionally, the standard version of the game)
• Beam - 7,500
• Pulse - 6,250

What if... the ranges of the beam laser and the pulse laser were swapped?
Would the beam laser still be the more desirable, effective and valuable weapon? I think so.

Might there then be some truth to the following?

Pulse Laser Specification: Ingram Model 1919A4 Pulse Laser is recommended for all positional laser mountings, but is especially effective for rear-shooting.

Beam Laser Specification: Ingram Model M1928A2 is highly recommended for front shooting.

I only found the following on laser ranges:

Military Laser Specification: Range and penetration twice as effective as the Ingram Model M1928A2 beam laser.

Of course, with the military laser at the same range, the player can still snipe away at great distance but bigger targets at such a range are still hard to appreciate with regards to model and texture detail. Smaller targets here would be harder to hit and so give them a greater opportunity to close on the player, to a new, shorter range.

The difference in the range of the pulse and beam lasers isn't that much at present but it could be made slightly bigger, e.g.

• Miltary laser - 15,000 (unchanged, still reaching to the edge of the scanner)
• Pulse Laser - 7,500 (significantly better than the beam laser below but still the inferior weapon)
• Beam Laser - 5,000 (range for a 0.33 scaled beam laser would be 15,000*0.33 = 4950 - an almost identical experience, with regards model sizes of the smaler ships, to the standard game)

Controversial perhaps, but no more so than my previous proposal of laser ranges at 0.33 - and probably less noticeable in terms of gameplay.

[another_commander]

Swapping pulse and beam laser range: It is a very interesting proposal indeed, but I can see a possible exploit. Although it may sound like a good idea giving a longer range laser to new players to compensate somewhat for the power of the most common lasers other ships have, I think that it may lead to every Jameson selling their front pulse laser, buying immediately a rear one and using sniping techniques to end battles from long distances while running away, usually before the opponents get any chance to close in and make use of their armaments. Not saying that this will always lead to newbie player victories, but it may become a generic easy way out and take away from the initial challenge of the game. Of course we can try it in a feature testing build and see how it works out, but I am not fully convinced of this change's usefulness yet.

One thing that I noticed during some testing is that, although we are halving all ship speeds, we seem to have forgotten the plasma shots speed. This should also be halved, I believe, otherwise turrets become super weapons firing shots that are extremely hard to dodge. I have applied this change on the branch and it will be in for the next testing build. I've also applied a few minor changes to the code so that for future iterations we will only need to change plasma shot speed and that will take care of adjusting turret ranges automatically to fit to the current weapon range logic.