Oolite Bulletins

I know the general rule of thumb that says "The slower your CPU, the fewer OXPs you should install", but is there a better defined relationship than that? I mean, has anybody gone further and said "If your CPU runs at 'X' GHz, you should install no more than 'Y' OXPs"?

Are there any OXPs that impose no extra load on the CPU? For example, what about mission OXPs? Or 'theme' OXPs like 'Commies' and 'Dictatorships'?

From what I've experienced so far, it's not about what OXP you're running, but what kind of OXP it is.

I had pretty much every major OXP other than the Redux, and ran at very smooth rates. Suddenly, with the beautiful textures and detailed spacestations I nabbed later, however, docking became impossible from the joggy frames I moved at.

Ah, so perhaps OXPs could be ranked according to their effect on the game's frame rate...

So which ones should someone definitely avoid if they want the game to run smoothly?

[Forgive me. I probably should have posted this thread in the "Expansion Pack" forum.... ]

AFAIK, the most impact comes from textures - the more, and the bigger the textures, the slower it gets. I usually limit the ship OXPs, so that the game doesn't have to load so many textures; as a side effect the system also becomes less populated (further reducing the processor load).

@Stromboli: cool avatar!

Memory is probabley more important than Clock Speed. If you wanna play with every single OXP installed then probabley 2 Gs is necessary. I play on an elderly Dell with 0.75 G with all mission OXPs, all station OXPs and a selection of about 20 ship OXPs and get about 32 fps.

Cmdr. Maegil wrote:

@Stromboli: cool avatar!

Thanks, made it meself. Modified an old jolly roger.

So to summarise: I thought that the number of installed OXPs decided how much the game slowed down. Stromboli thinks its the kind of OXP. Cmdr. Maegil says that it's the textures that slow the game down. And LittleBear says that it's the amount of computer memory.

Hmmm.

...and a nuke is simultaneously a miracle of modern arcane and just a big explosive with a few side effects, depending on if you're looking at the physics or the effects.

In fact, all are correct in their own way: ship-type OXPs have textures, who eat memory; and the more OXPs, the heavier the load. There!

I think all four. I've experienced Lag with a mission oxp, Caused by the number of amazing things in the oxp. I'v experienced it with the textures, just try the what's it called mk 4 oxp. I've experienced it with the number of oxps. And the memory, for good reasons. And if you have other apps open whale playing oolite, well, that will slow things down.


Don't Panic: FSOneblin

JonnyBoy: The numbers of OXPs does not directly alter game performance (I guess there might be some theoretical difference due to file handles or something).

But clearly, many OXPs have similar content, and you can reasonably expect that if you are using "average" OXPs then the effect seems to grow in line with the number you have.

The truth is, as people have said not quite so simple. Scripts can have a huge effect on performance, and in fact I think it should be possible to write a single script that in a few lines makes the whole game crawl.

Alternatively textures consume significant resources, so very pretty OXPs are more likely to be a drain on the system.

The bottom line is that you need to add OXPs a few at a time, remove the ones you are not using (completed missions etc.) and just try to keep it balanced. When you find the game is too slow, maybe remove the most recent OXP.

Cmdr James wrote:

The bottom line is that you need to add OXPs a few at a time, remove the ones you are not using (completed missions etc.) and just try to keep it balanced. When you find the game is too slow, maybe remove the most recent OXP.

Thank you, Cmdr James. That sounds like wise advice that I can try for myself.

I run the game on a Dual Core with 2 GB memory and a GT7900 card. But when a ship leaves a Witchspace cloud then the game slows down. Otherwise it's running smooth.

Cmdr James wrote:

The bottom line is that you need to add OXPs a few at a time, remove the ones you are not using (completed missions etc.) and just try to keep it balanced. When you find the game is too slow, maybe remove the most recent OXP.

I agree with Cmdr James. Only problem is that the effect of a single oxp by itself is hardly noticeable.
Graphics are definitely noticeable. e.g. On my slow 700 mHz machine I notice speed difference between the old and the new GRS space station (from buoyRepair,oxp) when I am close by. Therefor the old version is still kept available for download. rotating and turning of more complex models just takes more time, and the used graphic card had probably a large influence on this.

With ship oxp's there are two types. One that add ships by a custom role and one that add ships with a special script. The first type has much less influence on speed. When the populator decides that the system needs 6 traders and 8 pirates, it just has a larger pool to choose from. However, ships added with a script of its own are added on top of the populator set and by this increase the number of ships in any given system and more ships means more calculations. For a normal user it is not difficult to distinguish between these two types of ship oxp's.

Mission oxp's often have a large script. But I am still impressed that even the largest scripts are hardly noticeable. And they only run every 10 seconds. In between the don't consume any time at all. And with the new JS, the consumed time is even less. The old scripts do a great amount of useless script evaluation. The new JS scripts installs handlers for when its code (and witch part of the code) needs to be executed instead of just evaluating all code every 10 seconds. That means the JS script is normally doing nothing during flight. Typically the code is only triggered during hyper-jumps or launches/dockings.
E.g. buoyRepair.oxp uses a 2 minute timer that makes that the code for missing buoy's is only evaluates once every two minutes. This in comparison with old style scripts that run every 10 seconds, even when it has nothing to do.
Or when I look at the JS version of UPS-courier.oxp, I see it has a large script attached. But this script is completely dormant during flight. It only triggers during docking or jumping.

Some oxp's just use as much time as a dozen others. Without looking inside the code you can't see the difference. Bottom line is that you just have to try.

Have to second the memory more important than clock speed thing. I have a 3.4 dual core wotsit but only half a meg of ram, so I have to be careful what I download.

You can help yourself out by not downloading stuff that you dont need right away, such as missions or ships only found in far away galaxies or oxps that mirror each other closely.

The fuel collector i´m writing is checking fairly often for special events.. for example it will check every 3 second if the player has a derelict ship as his target.

When player.changetarget is introduced, this will get even faster as i will not have to do a 3 second check for a derelict ship, but only test when the player aqquires a new target...(which just make me realise, i still have to check since it can get derelict, while targeted... :-/ ) oh well

But at the moment I barely notice it... but i did go through the trouble of adding speedups here and there to make sure, that you would hardly notice it..

I do plan to release a test version soon, when i get the time to rewrite the new fuel cloud handling.