Split: Re-scaling experiment

[gizmo]

Now that I have a working Linux build (thanks to Commander_X): I really like the way the game play / immersion changes.

However, I'd rather don't reduce the reported distance from STE as, for me, the distances seem to be too small.
What I would change is the reported unit from km to gm (galacitc mile) or something like that.

[Redspear]

Congrats on your first release!

Thanks

Now that I have a working Linux build (thanks to Commander_X): I really like the way the game play / immersion changes.

Thanks again and thanks for your thoughts!

However, I'd rather don't reduce the reported distance from STE as, for me, the distances seem to be too small.
What I would change is the reported unit from km to gm (galacitc mile) or something like that.

This is one of those apparently contrary things. Why would I go to all that trouble of making space seem bigger and then reduce the reported distances from the STE?

The original Oolite scale is based around a coriolis station being the canonical 1km across. However, this resulted in ships being approximately 3 times 'too big' (canonically at least) when their sizes in ft were converted to m in order for docking to remain moderatly challenging. I seem to remember a picture somewhere on these boards showing a cobra 3 in oolite being about the size of a football field...

In the rescale plus version of the experiment, stations are 3 times bigger and almost all ships are 1.5 times bigger.
3 (approx factor by which ships were too large) x 1.5 (factor by which I have made them larger again) = 4.5
4.5 / 5 (factor by which I have reduced the STE reported measurements) = 0.9 or 90% of their canonical sizes.
Note that isn't true for all ships, for example the anaconda was scaled in that version to x 3 and so it's size relative to canonical value is approx (3 x 3 / 5) 1.8 or 180%. Stations may be 3 times bigger but they were already 'correct' and so that would be (3 / 5) = 0.6 or 60% canonical size. So the canonical sizes don't match with the game and they never did, even in elite, which is why aegidian picked one (the station) and scaled the ships up to it.

Bear in mind that a single km is quite a long way. If you're supposed to be engaing with a fighter at close to 15km, what do you expect to see? Try walking that distance and look back at where you came from. If your reference is distances as normally reported by the STE then of course the new measurements will appear wrong. When you're approaching something in the standard game however (and actualy have time to note the reading) big numbers tend to make everything on scanner seem similarly enormous. If you try that I suspect you'll see what I mean. Just how big is that cargo pod?

So in standard oolite, issues of scale are made all the more apparent by the fact entities that show up on scanner are typically too big (ships at 300%) and entities that don't are too small (planets at 1%).

So why didn't I divide km by 4.5 rather than 5? Then I could have ships at their canonical sizes.
Dividing by 5 means that each line on the scanner now marks 1km instaed of 5. If they marked 4.5km then I think that would seem rather strange.

The other obvious concern is that of making space seem smaller when it's already too small. The STE only reports distances within scanner range and with that distance being proportionally minute compared to WP-planet it's negligable.

Quick bit of maths to prove point:
Old scanner @ 25.6km to new scanner @ 5km = 19.5%
Old WP - planet at 1 to new distance @ x10 then x1.5 (increased lane) = 15
15 / 100 x 19.5 = 2.925

Therefore even if STE ranges could somehow acurately measure an entire system they would still report nearly 3 times as high a value as they do in the current game.

I've tried to move away from a canonical model and towards a visual one. So rather than one thing being 'right' (the station) and everything else 'wrong', I've employed a bit of smoke and mirrors to hide the fact that now nothing is 'right' but most things are no longer obviously wrong.

If you (or anyone else) still thinks that my reduction to STE distances is too severe or even unnecessary then please try to convince me. There must be ways to improve upon my thinking in all things 'rescaling'. I've already changed my mind numerous times on some of the values, so I'd have thought there's a good chance someone else can change it too

[gizmo]

Thinking about it your point of view makes sense - especially when considering the maths.

I guess my preference for the older distance calculation is based on roughly 4 decades of Elite / Oolite but I'm sure I'll adapt.

[Redspear]

I seem to remember a picture somewhere on these boards showing a cobra 3 in oolite being about the size of a football field...

Here it is

So in standard oolite, issues of scale are made all the more apparent by the fact entities that show up on scanner are typically too big (ships at 300%) and entities that don't are too small (planets at 1%).

Stations are the worst offenders here (in the standard game) because they can be clearly visible both on and off scanner. i.e. it's not easy to directly compare a ship to a planet (too big a difference) but it is easy to do so indirectly when you can compare it to a station (and then the station to a planet). Given that the player is typically headed to a station of some sort (which will typically be large enough to dock at), the idea that the scaling might be 'off' presents itself rather quickly and repeatedly.

True realism however, presents other issues and so although I may have headed in that direction, I've gone just far enough to suggest that I might have travelled considerably further than I actually have... if that makes any sense

[another_commander]

Regarding the overall appearance and lighting, I would recommend switching to the latest fragment shaders for 1.89 (revision 104f9c0). There have been some corrections made to lighting, plus you get the chance to ramp up the sun radiance, which makes things look much better in my opinion.

[gizmo]

Bug report:

I used the latest revision from Github and the RescalePlus.oxp
When I replace the OOlite binary with the latest version from trunk it works (even with the RescalePlus.oxp still in place).

Random Hits does not work with the rescaled game.
According to the log it gets loaded but there is no beacon in the ASC and there's no Space Bar to be found.

Strangely there's no error in the log regarding Random Hits.

However there are errors regarding NSPropertyList.m:

Code: Select all

File NSPropertyList.m: 1011. In parsePlItem Missing semicolon in dictionary at line 71 char 1670

and

Code: Select all

File NSPropertyList.m: 1011. In parsePlItem Missing semicolon in dictionary at line 7 char 176

[Redspear]

Hi Gizmo, thanks for letting me know.

Firstly, I'm a bit confused by your message as you mention both github and trunk.

Few points here:

• I haven't put anything on github for a long time, so you might want to check whichever version you're downloading.
• NSPropertyList.m is not a file that I have changed directly in this version of the experiment.
• Oxp compatibility (esp. with regards to ships) will be limited. For rescale_plus compatible ships and stations both size and speed need to be adjusted. I believe random hits adds both and so even if it did add a station, I doubt you'd be able to dock at it without tweaking the oxp.
• Rescale_modest requires less adjustment from other oxps in order to achieve compatability (stations x2 would be enough for it to be functional).

I will look at the file you mention however and see if line 7 presents any clues...

[gizmo]

Firstly, I'm a bit confused by your message as you mention both github and trunk.

I downloaded the source from Github and modified it according to your post a few pages back.
Trunk refers to the unmodified source.

NSPropertyList.m is not a file that I have changed directly in this version of the experiment.

I know that this has nothing to do with your changes but assumed that it might help finding the issue.

I'll try again with the Rescale_Modest.oxp.

What puzzles me is that all objects from Random Hits are missing. I'd expect that I would have trouble docking at the Space Bar but completely missing seems strange.

[dybal]

[*]NSPropertyList.m is not a file that I have changed directly in this version of the experiment.

I've been seeing those messages since I switched to trunk, I don't think they have anything to do with Redspear's re-scaling mods.

[another_commander]

NSPropertyList.m is a file belonging to GNUstep. That messages connected with it occur now on Linux systems is probably because of a recent update to the library, that is being picked up by the various distros' package managers. Avoiding this kind of sudden errors out of nowhere is why we have locked both Windows and official Linux distributions of the game to GNUstep 1.20.1.

Edit: Actually, this is an OXP that is to blame. There has been a report about a similar thing in 2015: viewtopic.php?t=17681

[gizmo]

Okay, then I'll start digging around to find the one to "blame"

[dybal]

NSPropertyList.m is a file belonging to GNUstep. That messages connected with it occur now on Linux systems is probably because of a recent update to the library, that is being picked up by the various distros' package managers. Avoiding this kind of sudden errors out of nowhere is why we have locked both Windows and official Linux distributions of the game to GNUstep 1.20.1.

Edit: Actually, this is an OXP that is to blame. There has been a report about a similar thing in 2015: viewtopic.php?t=17681

Good, that I can help... I will do a binary search tonight and see if I can find the culprit!

Quick topic-hijack: the messages about shipdata.plist errors from trunk like those bellow (it's great to have them, by the way!) would be much more useful if they printed the full shipdata.plist filename, with path:

Code: Select all

16:19:12.617 [oxp-standards.error]: Error in shipdata.plist
16:19:14.124 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "navystat50" specifies non-existent model "
galNavy_station.dat".

It doesn't hinder me much (I have all oxzs unzipped in a sub-tree so I can do a quick `find <unzipped sub-tree> -name shipdata.plist -exec grep -H \{\} \;` to find it), but it would make it easier to find in correct the problems.

[Redspear]

Thanks all!

Regarding the overall appearance and lighting, I would recommend switching to the latest fragment shaders for 1.89 (revision 104f9c0). There have been some corrections made to lighting, plus you get the chance to ramp up the sun radiance, which makes things look much better in my opinion.

I did try them out (as you posted in the progress thread) but likely I need to update elsewhere as they displayed in monochrome. I think you said they needed the latest nightly at that time so I'll update and try again.

I am enthusiastic about the possible improvement here as it should address earlier concerns of mine re lighting.

[another_commander]

I did try them out (as you posted in the progress thread) but likely I need to update elsewhere as they displayed in monochrome.

If they (and by they I expect you mean the ships and that you are referring to the oolite-default-shader.fragment) displayed in monochrome, then there was an editing error that prevented the shader from compiling. Latest.log should have a message with the line that killed the shader.

[gizmo]

Okay, then I'll start digging around to find the one to "blame"

It seems the offender is the Griff MultiDecal Cobra3.
There's a semicolon missing in the shipyard.plist.