Regarding the stutter I'm experiencing (visible in my videos)

[zx_cb]

Should be noted here, I experienced frequent crashes with multiple "script out of memory" errors in a log, and an average FPS around 20. That is on a 6-core 7800X, 64GB RAM and slime-cooled GTX1080. 300-some OXPs installed and one NOT installed is Useful MFDs. Increasing script memory allocation to 256 sorted both issues.

Dear Mr. Wiki Master, maybe that is the kind of info that should not be hidden in the bellows of unpretending "Hidden Settings" article, with "out of memory" search returning fruitless.

Or, maybe that setting should be increased on developer level, provided most modern machines rarely run less then 8 or even 16GB memory, and sparing new player of digging into the board and the script. Just saying.

[Cholmondely]

...maybe that is the kind of info that should not be hidden in the bellows of unpretending "Hidden Settings" article, with "out of memory" search returning fruitless.

I've added to the wiki page. I'm unsure that will be enough for people like myself who are not computer nerds, though. If I'm a new player with little computer awareness and 300 OXP's loaded, how will I ever work out where to look?

[zx_cb]

I've added to the wiki page. I'm unsure that will be enough for people like myself who are not computer nerds, though. If I'm a new player with little computer awareness and 300 OXP's loaded, how will I ever work out where to look?

That is exactly my point - one doesn`t have to go grail-digging to find a tweak to the core software that is very required for its stable and smooth operation under multiple OXP burden (which is an advertised part of its functionality - hey, we do have a thousand mods, try them out!)

For completeness sake, I`ve added Useful MFDs to my main install, and no decrease of performance was felt to be noticed by naked eye after the script memory increase, my guess it isn`t a clue here at all when JS is choking on a default 32MB.

[RobsterLeal]

one more suffering the stuttering bug, and narrowed it down to usefulMFDs...

[Nite Owl]

usefulMFDs can create problems as it is in a constant state of updating itself. The JavaScript coding which allows it to do this may not be optimal but that is just speculation on my part. It is Useful though (especially if you TWEAK it to show just what you want it to show) so here is the trick to getting it to run properly.

Go to Oolite\oolite.app\GNUstep and open the .GNUstepDefaults file in something other than notepad (notepad++ works well). Look for the following.

Code: Select all

"jsruntime-size-mib" = [number]; <--> if this line does not exist type it in 

Change the variable [number] to a multiple of 64 (128 - 256 - 1024 - 2048) without the brackets. Have mine set at 2048 which is admittedly much higher then is probably needed. Since making this change there have been no stuttering problems when using usefulMFDs. Remember to backup your files before you make any changes to them.

[MrFlibble]

Go to Oolite\oolite.app\GNUstep and open the .GNUstepDefaults file

Hmm. backslashes... So, that's how to pre-set RAM for js on Windows. Is this relevant on other platforms?

On Linux we have ~/GNUstep/Defaults/.GNUstepDefaults which is in xml plist format. Mine only seems to contain joystick adjustment stanzas for two specific save-games.

A snippet from the top to illustrate.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//GNUstep//DTD plist 0.9//EN" "http://www.gnustep.org/plist-0_9.xml">
<plist version="0.9">
<dict>
    <key>NSGlobalDomain</key>
    <dict>
    </dict>
    <key>oolite</key>
    <dict>
        <key>Jameson-humbletrash</key>
        <integer>-29624</integer>
        <key>JoystickAxes</key>
        <dict>
            <key>0</key>
            <dict>
                <key>isAxis</key>
                <integer>1</integer>
                <key>stickAxBt</key>
                <integer>2</integer>

[another_commander]

This should work:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//GNUstep//DTD plist 0.9//EN" "http://www.gnustep.org/plist-0_9.xml">
<plist version="0.9">
<dict>
    <key>NSGlobalDomain</key>
    <dict>
    </dict>
    <key>oolite</key>
    <dict>
        <key>Jameson-humbletrash</key>
        <integer>-29624</integer>
        <key>jsruntime-size-mib</key>
        <integer>2048</integer>
        <key>JoystickAxes</key>
        <dict>
            <key>0</key>
            <dict>
                <key>isAxis</key>
                <integer>1</integer>
                <key>stickAxBt</key>
                <integer>2</integer>

[MrFlibble]

Thanks a_c. Not sure it made any difference, but it didn't create any log noise.

I was hoping to improve the jump to witchspace, which always seems to stutter and fumble mid-way. Too many OXPs for my little laptop I guess

On my first attempt after applying this, there was about a ten second freeze before going into witchspace for the jittery tunnel experience, though I expect the delay was due to what was on the other side needing a bit of calculating time.

[Cholmondely]

I've been seeing a lot of these screens recently. When I arrive in a wealthy high-tech system (Zaonce, Tionisla, Ensoreus - not Qutiri).

Around 70 or so ships, stretched out diagonally across my scanner, but seemingly extending no further and making their way towards the main orbital station.

It does not seem very realistic, since it just fills the screen and does not seem to extend beyond it. No new ships arrive to supplement those departing.


Does anybody have any idea which OXP might be generating them?

[MrFlibble]

Does anybody have any idea which OXP might be generating them?

It's Nuit stations, or at least that's how it looks to me.

Gal 4, Jump from Laanat -> Xetiis (TL 12)
With Nuit stations, heap o' traders.
Without Nuit stations, normal.
Replace Nuit and the glitch returns.