Oolite Bulletins

Thanks for the help.

Unfortunately, the link for Debug_OXP is broken. I've got the other 2 (OoDebugConsole1.5.zip & Oolite-1.84_x64-Deployment-to-Test-Release.exe)

Above, Cody said:

I know zilch about coding/audit stuff - I'm merely a dumb pilot.

Do I really need all this just to get line #'s in my Latest.log file?

cag wrote: ↑Sun Mar 19, 2017 2:01 am

When I first went thru the games oxz manager, I'd picked a few hundred - mistake!

Yep. IIRC there's a bad interaction between Random shipnames and random-ship names or something like that; two OXPs with almost the same name but one of them is destroying your FPS for no reason.

Also, I'm surprised you get so high FPS numbers. I think by default it is locked to 60FPS or something consistent with your monitor's refresh rate. Did you force it? I remember I had bad experiences with that. You don't need 120FPS anyway. I run at 60 and it's perfectly smooth. My rig is getting old so I have to make compromises between quality and FPS with recent AAA games. I usually aim at 30 FPS for fluid animation. I don't understand why people are so greedy about it and want to run at 200FPS. For one thing it's absolutely pointless to have more FPS than the refresh frequency of your monitor. And since some OXPs use the frame callback, increasing it is likely to be detrimental in the end.

@cag: You will need the OXP Developer Release of the game in order to see script error locations and exception backtraces. You have already downloaded the Deployment to Test Release converter and that is all you need. When run, it will ask you whether you want to install also the Debug OXP (you normally want to do this) and it will set up everything for you. The old Deployment executable will be backed up under the filename oolite,exe,dpl.

The console is not required if you only want to have error locations output, but if you intend to get involved with OXP editing and scripting, I would consider it a requirement, as it makes a scripter's life so much better.

OXPs are not normally audited. They are made by community members, most of whom are not programmers and it is expected that not all attempts will be of the same quality level. Any QA effort should take this into account. We do not want to discourage anyone from participating and the developers do not do QA on expansions. We just try to make sure that the base core is as robust and crash-proof as we can possibly make it, so that OXPs can't bring the game down.

@Astrobe: High FPS are important. Some people are OK with 30 and that is fine - console games are mostly locked on 30 after all. But most people can perceive very easily the difference between 30 and 60 FPS and feel something is wrong, even for slight fluctuations below 60. Some recent monitors have a 144Hz refresh rate and the difference between 60 and 144 is again observable. Finally, with the advance of VR headset technologies, we are now at a place where the Oculus Rift has a minimum 90 FPS requirement in order to avoid VR sickness. So we still should try to aim as high as we can. I would agree though that if you use just a 60Hz monitor, then as a user you would probably not need anything more than 60 FPS.

Hi cag, welcome in the Ooniverse!

Thank you for the improved reverse control code, I tested it, looks good so the new v1.5 contain it in the manager.

Auditors are the players who comment OXPs in this forum. If an author is not responding then it is possible to take over the OXP and continue the work. It is easy when there is a friendly License within, otherwise more complicated but not impossible.

If you found one which cause FPS drop and it is not already reported then please report in its own topic. Any performace advices are welcomed.
For tests the following lines raise the FPS limit to 999 in .Oolite/GNUstep/Defaults/.GNUstepDefaults within the oolite section:
OXPs which create many flashers can cause slowdown, for example Trails and Telescope. It is a trade-off between visuality and performance. In the case of Telescope for more FPS prime it with some Shift+N presses then use the mode button ("b") to cycle in the functions until "Lightballs", then press activate ("n") until "off".

Another bottleneck is the CPU. Oolite use a single thread only, some js sentence like accessing the list of worldScripts need much more time than others, which could be the problem if an OXP do something heavy in a frameCallBack or fast timer. Fortunately developers usually like to talk about optimizing codes so you have chances to earn improvements when you mention them specifically.

Js errors usually get line nubers, if not then the location is not known or just not displayed by the interpreter, what I do not know how to hack.

The test release is good to accelerate time, in debug console you can spawn ships or change writable properties like restore energy on the fly without restart the game. Debug OXP is shipped with the test release of Oolite, you need to download in addition the debug console only. I use the following shell script to start-stop the console around running Oolite in Linux:

No problem for me if you post your suggestions here and not in PM. I know that my codes are not perfect, I already got many critiques and I took them well. Imho worth to see the good intention within criticism.

Moderators: maybe PM is not allowed for new users for a while due to spam policy?

Norby wrote: ↑Sun Mar 19, 2017 1:14 pm

Moderators: maybe PM is not allowed for new users for a while due to spam policy?

<nods> A new user's first post has to be approved - once that's done, sending PMs should be fine.

Thanks for all the tips!

@Astrobe

I use the high fps as a rough benchmark for the oxp's performance hit. You're right in that any frame rate beyond your refresh rate does nothing but generate heat & shorten the life of your graphics card.

If you cannot get above 60, check your graphics profile. On my AMD Radeon, setting the 'Graphics Profile' to 'balanced' will limit my frame rate, so I had to set it to 'Optimize Performance' to get higher.

@another_commander

Thanks!!! The console is up and running and I've got line numbers - great!

I really don't want to discourage any oxp creators - I think community game dev is an awesome concept. I just thought pm's would be more tactful; nobody's ever accused me of being diplomatic! I expect you guys to put me in my place if I'm not.

@Norby

re: reverse control - glad I could help.

re: single thread only - it doesn't appear so on my rig (AMD Phenom II X4, Windows 10 x64). I ran Window's Resouce Monitor and all 4 cores rose the same as I started 3 simultaneous games. May be something Windows specific? Anyway, I play with a game pad and all 3 games were receiving input - it no fun trying to steer 3 different scenarios at once, let me tell you!

re: telescope - I had turned off both rings but not the light balls. Would a simple empty circle gain us much improvement? Not sized like mass lock ring but rather like a computer icon that says there's something here, same size for all, just diff. colours, maybe. Not my area of expertise. But I do plan to see what I can do w/ the code, as I really want to keep using it!

P.S. sorry for late reply. The 1st time I wrote this, I think hit Preview and not Submit - d'oh!

My latest crusade is to reduce the frequency of garbage collection. Those little stutters seem to occur at the worst possible time. Anyway, once I came up for air and started flying again, this is the 1st oxp I loaded. (I really think this should be part of the core, having the controls work the same in all views.)

This was generating garbage at a rate of about 10 MB/min in port/starboard view, less in the aft view. I was able to cut that in half by porting the rotation calculation from the core to JS. The speed that was lost doing this was mostly recovered by fewer property gets and other efficiencies. Execution time went up from 1/4 ms to 1/3 ms per frame (port/starboard views).

https://www.dropbox.com/s/onkhzpy5tud4w ... l.zip?dl=0

Thank you very much cag, uploaded in ReverseControl v1.6.

@cag
Respect!

cag wrote: ↑Thu Oct 05, 2017 5:02 am

(I really think this should be part of the core, having the controls work the same in all views.)

Well, there are historical/traditional reasons why they don't. Not saying I necessarily disagree with you, but you'll have to convince a lot of folks before you'll see that happen.

Getafix wrote:

@cag
Respect!

Seconded!

There is something about the reverse control thing that doesn't feel right..
(I play on keyboard. I guess this is not really an issue when using a joystick?)

When you dive/climb or rotate (diving/climbing is really also rotating) and then let go of the keys, you don't stop rotating immediately.
This is actually a good thing. It would be horrible if it would. It is really 'control damping' but it _feels_ like momentum.

If you switch view while the controls are still on their way back to neutral, you immediately and abruptly start rotating in the opposite direction.
Now I guess this is technically correct, since it is control damping and not momentum, but it feels unnatural. It feels like it is reverse physics instead of reverse control.

hoqllnq wrote: ↑Sun Oct 22, 2017 1:03 pm

There is something about the reverse control thing that doesn't feel right..
(I play on keyboard. I guess this is not really an issue when using a joystick?)

I use a joystick, but not this OXP, so I couldn't really say..

hoqllnq wrote: ↑Sun Oct 22, 2017 1:03 pm

(I play on keyboard. I guess this is not really an issue when using a joystick?)

I've played w/ a gamepad from the start (roll, throttle on one stick, pitch, yaw on other), so I never noticed. And w/ view on the 'hat' pad, motion has all but stopped by the time my thumb can change the view. But using a keyboard is quite different, esp. the roll - it takes almost 2 second to stop! This may have something to do with how fast the keyboard buffer empties, which can vary on different machines.

It does feel like momentum, which I miss from other games, esp. helicopters. I just put it down to some <hand waving> inertial dampening, to prevent pilots feeling nauseous. I can see how this oxp might feel wrong playing on a keyboard.

I just wanted consistency across views; having to pause to figure which way the stick operates in whatever view just wasn't on (I'd get it wrong more often than not, diving when I wanted to climb, rolling the wrong way, arrgh).

This oxp does not address the motion of the ship when the view is changed and it probably should. I could delay the changeover until movement in an axis bleeds off (so there's no abrupt change in motion) but if the player continues to steer using that axis, how can I tell? Is there a way to detect user input directly? If not, I'm going to have to get creative . . .

I just had a quick look at the script.

It inverts the angular motion of the ship, not the effect of the controls.
On each frame it calculates the difference in orientation and then double-undoes it, or undoes it and then applies it to a different axis. (Which is pretty creative.)

I don't think you can remap what controls do on the fly. When I look left or right, my roll controls make the ship pitch, but they still move the roll indicator in the same direction. That is what you would really want: Have the same key/control move the pitch/roll indicators in the opposite direction, or have the same control move the other indicator.

Now, if ship.pitch and ship.roll were writable, then you could flip the motion on view change (i.e. ps.roll = -ps.roll; for aft view, ps.roll = ps.pitch; for left, ps.roll = -ps.pitch; for right, etc.. ) so that the combined effect would be that the ship keeps rotating in the same direction, but they aren't, according to the wiki.

hoqllnq wrote: ↑Sun Oct 22, 2017 10:25 pm

Now, if ship.pitch and ship.roll were writable, then you could flip the motion on view change (i.e. ps.roll = -ps.roll; for aft view, ps.roll = ps.pitch; for left, ps.roll = -ps.pitch; for right, etc.. ) so that the combined effect would be that the ship keeps rotating in the same direction, but they aren't, according to the wiki.

You can always submit a request that they be made writable.. now that 1.86 is in feature freeze though, it will be a good while before it makes it into the game.