Trunk nightly

[Cody]

... there is a second known crash bug being investigated...

Ah, not all of my CTDs were entering witchspace - most, but not all.

[Diziet Sma]

file_size has been added as an optional manifest property and applied to the index.

A question (two, in a sense) on the precise formatting of the manifest.plist..

The  wiki page puts quotation marks around most items, both keys and parameters, but I noticed in Norby's manifest (which I borrowed from when making my own) that many of the quotation marks do not appear around the keys themselves, only the actual parameters, and indeed my own works just fine when formatted this way. Could you please clarify just where quotes are, and are not, necessary?

Also, in the new entry for the file_size key, the key itself is in quotes, but the parameter is not.. this inconsistency is a little confusing..

[Norby]

in Norby's manifest (which I borrowed from when making my own) that many of the quotation marks do not appear around the keys

I borrowed mine from cim's Camera_Drones_1.3.oxz and I think the syntax is the same as in shipdata.plist, so quotation is required only around strings with special characters excluding underscore. My visual preference is to quotate all string parameters but not numbers nor keys. I like better if keys are from normal letters and underscore only to be able to leave quotation marks.

[cim]

Also, in the new entry for the file_size key, the key itself is in quotes, but the parameter is not.. this inconsistency is a little confusing..

My personal practice is to quote strings but not numbers. The openstep plist format however, as Norby says, does not require all strings to be quoted, but I can never remember which ones it's okay with and it does no harm to quote them.

[Cody]

I was jumping to and fro between two close systems (and collecting quite an entourage), but after about a dozen jumps, I had a CTD just after emergence from witchspace. I'd somehow enabled shader/entity logging (or something - don't ask, I don't know) which produced a rather large log, a few lines of which may be of interest:

Code: Select all

20:27:16.563 [shader.uniform.bind.failed]: Could not bind uniform "ovSettings" to -[OOVisualEffectEntity shaderVector1] (no uniform of that name could be found).
20:27:16.563 [shader.uniform.unSet]: Did not set uniform "ovSettings"
20:27:16.563 [shader.uniform.bind.failed]: Could not bind uniform "ovSlideC" to -[OOVisualEffectEntity shaderInt1] (no uniform of that name could be found).
20:27:16.563 [shader.uniform.unSet]: Did not set uniform "ovSlideC"
20:27:16.563 [shader.uniform.bind.failed]: Could not bind uniform "ovSlideI" to -[OOVisualEffectEntity shaderInt2] (no uniform of that name could be found).
20:27:16.563 [shader.uniform.unSet]: Did not set uniform "ovSlideI"

... and these are the final two lines in the log before the CTD:

Code: Select all

20:27:51.191 [shader.uniform.set]: Set up uniform <OOShaderUniform 0x15766d50>{0: int uDiffuseMap = 0;}
20:27:51.191 [shader.uniform.unSet]: Did not set uniform "uNormalMap"

[cim]

Code: Select all

20:27:16.563 [shader.uniform.bind.failed]: Could not bind uniform "ovSettings" to -[OOVisualEffectEntity shaderVector1] (no uniform of that name could be found).

It's something trying to be a Cabal Common Library overlay, by the looks of it, but I'm not sure what. The error message probably means that the material in shipdata.plist had a uniform "ovSettings" (etc) defined, but the shader program didn't have any use for that uniform. Should be harmless.

How long after witchspace exit was this? Had you got control back? Or sooner?

[Cody]

How long after witchspace exit was this? Had you got control back? Or sooner?

The BGS hyperspace effect had barely ended, and I had control back - briefly.

[cim]

How long after witchspace exit was this? Had you got control back? Or sooner?

The BGS hyperspace effect had barely ended, and I had control back - briefly.

Might be the other known bug, then - a crash in the docking management code: systems will sometimes be generated with a trade ship on approach to the main station. submersible seems to be able to replicate that reasonably reliably - I've not seen it here at all - so we'll keep working on it.

Or it could be something entirely new, but until we've definitely cleared the known two, that's very hard to say.

[kanthoney]

I've been bouncing between Leesti and Diso investigating the witchspace crash (after giving myself an instant refuel hack), and noticed that a couple of times the planet would be white. Here's Diso looking a bit pale:

https://drive.google.com/file/d/0B5m1zB ... sp=sharing

Also, the day/night separator is looking nicely blended, instead of the usual sharp stuff. I don't know if it's related to the crash problem.

[BlueSteel]

weird i posted 3 bug reports on github but i can't see them on there.

make clean
make -f GNUmakefile SNAPSHOT_BUILD=yes VERSION_STRING=1.79.0.5570-140128-530e1cf debug=no

1. players ship on the character status screen needs to be re positioned, at the moment its like it top/right aligned, it needs to be more down / left on the screen



2. on the start menu screen (normal start,tutorial,strict) the normal selection shows strict ship texture (I believe normal should show the modded ships texture, and strict to display as it is now with the default skin)

3.Compiler errors/warnings
...
make[4]: stat: obj.win.spk/oolite.obj/OOShaderMaterial.m.o: Bad file number
...
In file included from src/Core/OOALSoundDecoder.m:31:0:
E:/OoliteDevelopmentEnvironment_LE_20131030/Msys_x2/1.0/mingw/../devlibs/include/vorbis/vorbisfile.h:82:21: warning: 'OV_CALLBACKS_NOCLOSE'
defined but not used [-Wunused-variable]
E:/OoliteDevelopmentEnvironment_LE_20131030/Msys_x2/1.0/mingw/../devlibs/include/vorbis/vorbisfile.h:89:21: warning: 'OV_CALLBACKS_STREAMONL
Y' defined but not used [-Wunused-variable]
E:/OoliteDevelopmentEnvironment_LE_20131030/Msys_x2/1.0/mingw/../devlibs/include/vorbis/vorbisfile.h:96:21: warning: 'OV_CALLBACKS_STREAMONL
Y_NOCLOSE' defined but not used [-Wunused-variable]

[another_commander]

weird i posted 3 bug reports on github but i can't see them on there.

make clean
make -f GNUmakefile SNAPSHOT_BUILD=yes VERSION_STRING=1.79.0.5570-140128-530e1cf debug=no

1. players ship on the character status screen needs to be re positioned, at the moment its like it top/right aligned, it needs to be more down / left on the screen

Right, this is dependent on the screen resolution. Works fine for 800x600 but is indeed misaligned for 1920x1080. Will have to look at it at first opportunity.

2. on the start menu screen (normal start,tutorial,strict) the normal selection shows strict ship texture (I believe normal should show the modded ships texture, and strict to display as it is now with the default skin)

Not sure what exactly you mean, I see no strict mode textures here at all. While the start menu screen is displayed we are not in strict mode so it makes sense that the ships get displayed with their standard mode textures and changing it so that a no-OXPs texture gets displayed in the Strict Mode option only would probably be much more work than it's worth. Or have I misunderstood something?

3.Compiler errors/warnings
...
make[4]: stat: obj.win.spk/oolite.obj/OOShaderMaterial.m.o: Bad file number
...
In file included from src/Core/OOALSoundDecoder.m:31:0:
E:/OoliteDevelopmentEnvironment_LE_20131030/Msys_x2/1.0/mingw/../devlibs/include/vorbis/vorbisfile.h:82:21: warning: 'OV_CALLBACKS_NOCLOSE'
defined but not used [-Wunused-variable]
E:/OoliteDevelopmentEnvironment_LE_20131030/Msys_x2/1.0/mingw/../devlibs/include/vorbis/vorbisfile.h:89:21: warning: 'OV_CALLBACKS_STREAMONL
Y' defined but not used [-Wunused-variable]
E:/OoliteDevelopmentEnvironment_LE_20131030/Msys_x2/1.0/mingw/../devlibs/include/vorbis/vorbisfile.h:96:21: warning: 'OV_CALLBACKS_STREAMONL
Y_NOCLOSE' defined but not used [-Wunused-variable]

These are warnings from the vorbis library, they are harmless and we normally don't mess with third party library code unless absolutely required. As for the bad file number, it is a non-repeatable make error message. The build continues and succeeds anyway and next time you run make it probably won't show this. Seems to be related to the -j switch.

[BlueSteel]

updated first post with an image

what i'm saying is that the model of the spinning ship for normal is the same is the one for strict.
I believe it should show the oxp skin of the starter ship (if you have one) for normal and a non oxp model if you don't as should the strict mods model should show the non ocp model

i've made it several times and see them every time i compile (I think its because i use make clean first)
PS: sorry i see now what you mean about the -j option.. because of the threading when compiling

[Cody]

No CTDs, of any sort, to report. Has anything changed in Oolite's gfx settings recently, btw? I'm seeing what looks like slight tearing - not unlike if I disable V-sync, but not nearly as pronounced. It's only really noticeable with close-up peripheral objects, such as rock hermit tunnels, and to a lesser extent, station slots (it could be my rig, of course - but I've not changed any gfx settings in my Nvidia control panel for quite a while). It's not the same as the stutter, anyway.

Re parcel contracts and assassins: I've seen very few assassins with injectors - I was just jumped by nine of them, and not one of them pursued me on injectors.
Also, shouldn't they follow a courier through witchspace occasionly? They are re-acquiring me after I cloak/decloak nicely though.

[cim]

No CTDs, of any sort, to report.

Excellent. I'll leave it a couple more days just to be sure then close off that bug report if nothing else shows up.

Has anything changed in Oolite's gfx settings recently, btw? I'm seeing what looks like slight tearing - not unlike if I disable V-sync, but not nearly as pronounced. It's only really noticeable with close-up peripheral objects, such as rock hermit tunnels, and to a lesser extent, station slots (it could be my rig, of course - but I've not changed any gfx settings in my Nvidia control panel for quite a while). It's not the same as the stutter, anyway.

I don't think any of us have touched any of that. I don't see anything obvious in the last week, at least.

Re parcel contracts and assassins: I've seen very few assassins with injectors - I was just jumped by nine of them, and not one of them pursued me on injectors.
Also, shouldn't they follow a courier through witchspace occasionly? They are re-acquiring me after I cloak/decloak nicely though.

I was doing my repeated-witchspace-jump tests for the crash bug with a pilot who had a lot of courier rep. By the time they'd done a few jumps they'd accumulated quite a cloud of assassins following right behind them. Likewise definitely plenty with injectors here.

Oh... hang on. Could you try it without a shipset OXP for a little while and see what happens? I may have missed something rather crucial out of the ShipsetCompatibility OXP.

[another_commander]

Has anything changed in Oolite's gfx settings recently, btw? I'm seeing what looks like slight tearing - not unlike if I disable V-sync, but not nearly as pronounced. It's only really noticeable with close-up peripheral objects, such as rock hermit tunnels, and to a lesser extent, station slots (it could be my rig, of course - but I've not changed any gfx settings in my Nvidia control panel for quite a while). It's not the same as the stutter, anyway.

I don't think any of us have touched any of that. I don't see anything obvious in the last week, at least.

The animation timer maybe? FPS are maxing out at 200 in current trunk, instead of the 100 we had up to now.