Oolite Bulletins

Posted: **Tue Dec 15, 2009 4:01 pm**

A few pics
Aronar hunting lodge

Accept the challenge? Well it would be rude not to...

The victor (lasers only too...)

Confirmation & bet paid out - bonus

Looking good Ramirez
I'm off to play some more...

oops- After launching from the Hunting lodge I get this conflict message (I guess a conflict with UPSoxp)

T

Posted: **Tue Dec 15, 2009 6:15 pm**

Tivva wrote:
oops- After launching from the Hunting lodge I get this conflict message (I guess a conflict with UPSoxp)

This is a general problem of a lot of oxp makers. They only look if their oxp works as a stand alone thing but don't look at other oxp's running simultaneously. I already noticed that this oxp never clears the choices when ready.
This means other oxp's never know if the choice is already read out or not. This is because the oxp that starts first after a missionscreen is finished, is not always the one that generated the screen. If it sets up a screen of its own, the choices in memory are reset and the script that originally created the screen won't find the choices anymore.

For Oolite 1.74 things will get much easier in writing. Than we have a new way of setting up a missionscreen that only returns the choices to the script that generated the screen.

Posted: **Tue Dec 15, 2009 7:09 pm**

Thanks for the quick reply Eric
I know UPSoxp is your's too. (I didn't mean to sound as if the problem was directed at you)
Is there a quick fix us plebs can cut'n'paste into either oxp to stop the conflict, while we wait for 1.74?????
Thanks

Posted: **Tue Dec 15, 2009 7:32 pm**

Edmund wrote:
It's one of these things that doesn't show up on a mac.
Might have known it was Bill Gates fault

Although the Mac GLSL parser is in general a good one, in this particular case it’s the one that’s wrong.

Incidentally, this problem would go away if people adapted the approach to lighting used in the default ship shader. I guess I should put together some simpler examples.

Posted: **Tue Dec 15, 2009 7:36 pm**

Eric Walch wrote:
Tivva wrote:
oops- After launching from the Hunting lodge I get this conflict message (I guess a conflict with UPSoxp)
This is a general problem of a lot of oxp makers. They only look if their oxp works as a stand alone thing but don't look at other oxp's running simultaneously. I already noticed that this oxp never clears the choices when ready.
This means other oxp's never know if the choice is already read out or not. This is because the oxp that starts first after a missionscreen is finished, is not always the one that generated the screen. If it sets up a screen of its own, the choices in memory are reset and the script that originally created the screen won't find the choices anymore.

Eric, could you out together a stand-alone version of your error checking script so we can integrate it into Debug.oxp? This would increase the chances of people fixing the problem when updating/cloning existing mission scripts.

Posted: **Tue Dec 15, 2009 9:08 pm**

Tivva wrote:
Thanks for the quick reply Eric
I know UPSoxp is your's too. (I didn't mean to sound as if the problem was directed at you)
Is there a quick fix us plebs can cut'n'paste into either oxp to stop the conflict, while we wait for 1.74?????
Thanks

It is not a conflict itself. It is just a diagnostic message that there could be a conflict. I added it as hint to other oxp-writers that they should check their code. And as warning to the player that there is a small chance of trouble.

Ahruman wrote:
Eric, could you out together a stand-alone version of your error checking script so we can integrate it into Debug.oxp? This would increase the chances of people fixing the problem when updating/cloning existing mission scripts.

Yes, I can do it. With the future changes in 1.74 I removed these messages from ups itself as ups don't needs them anymore, but I still think it helps tracing flaws in other scripts, so inside debug.oxp might be a good idea.

Posted: **Tue Dec 15, 2009 10:33 pm**

Apologies, I didn't realise there was a problem with clashing choices as well as mission screens. I had assumed that as choices are called as part of the runMissionScreen function they somehow stay with the the screen rather than being a standalone thing.

Would I be right in thinking this can be fixed by adding mission.choice = null after each of the choice evaluation screens? If so I'll get onto it a.s.a.p.

Looks like a v1.1 won't be far off!

Posted: **Tue Dec 15, 2009 10:35 pm**

With a saved game starting in Aronar, the saved game loads, but when I launch from the station (F1) I crash immediately. I'm on Ubuntu Linux (not the new one, the one just before it Jaunty something), I'll download the new Feudal States and try it again tonight.

Posted: **Tue Dec 15, 2009 11:38 pm**

Chrisfs wrote:
With a saved game starting in Aronar, the saved game loads, but when I launch from the station (F1) I crash immediately. I'm on Ubuntu Linux (not the new one, the one just before it Jaunty something), I'll download the new Feudal States and try it again tonight.

You'll be an Intrepid Ibex man then?

Posted: **Wed Dec 16, 2009 2:50 am**

No I'm a Jaunty Jackalope, I meant as opposed to a Karmic Koala.

DaddyHoggy wrote:
Chrisfs wrote:
With a saved game starting in Aronar, the saved game loads, but when I launch from the station (F1) I crash immediately. I'm on Ubuntu Linux (not the new one, the one just before it Jaunty something), I'll download the new Feudal States and try it again tonight.
You'll be an Intrepid Ibex man then?

Posted: **Wed Dec 16, 2009 9:28 am**

Ramirez wrote:
Would I be right in thinking this can be fixed by adding mission.choice = null after each of the choice evaluation screens? If so I'll get onto it a.s.a.p.

Looks like a v1.1 won't be far off!

Not for all. For multi screen offers you only need it for the last choice.

Not clearing the choice does not affect your oxp but just makes it a bit more difficult for others when they want to make an offer at the same time.

With future 1.74 we will have a call-back function that deals with the choices. That way only the creator of the mission-screen receives the choices back. Translation for 1.74 will not be that difficult as you can just use your existing "this.choiceEvaluation" as the call-back function in most cases.

Posted: **Wed Dec 16, 2009 11:08 am**

Chrisfs wrote:
No I'm a Jaunty Jackalope, I meant as opposed to a Karmic Koala.

DaddyHoggy wrote:
Chrisfs wrote:
With a saved game starting in Aronar, the saved game loads, but when I launch from the station (F1) I crash immediately. I'm on Ubuntu Linux (not the new one, the one just before it Jaunty something), I'll download the new Feudal States and try it again tonight.
You'll be an Intrepid Ibex man then?

D'oh! Misread your statement as being "the one before Jaunty" when in fact you meant no such thing - I've run Oolite (1.65-.69) on Fiesty, and 1.73.4 on Gutsy - I'm just about to install it on Karmic (I have Jaunty on this laptop but Oolite's not on it - it's on the Vista partition instead)

Posted: **Wed Dec 16, 2009 1:07 pm**

Edmund wrote:
I'll double check by uninstalling The Feudal States and checking Aronar is reachable. Then I'll re-download The Feudal States and if necessary correct the errors mentioned above as per Griff's advice. If I'm still having problems I'll uninstall All-Stars to remove unneccesary "error spew" (Hehehe that's funny) and then save a log.

I've tried all that, definitely no spaces after the \ in 'feudal-fragment-shader.fragment'. Still get a crash every time I begin Hyperspace to Aronar, but no [shader.compile.fragment.failure] error showing up. Using a fresh commander direct from Lave, and no other OXPs (just my BBC style keyboard remap) this is the log:

Code: Select all

[log.header]: Opening log for Oolite version 1.73.4 (x86-32 test release) under Windows at 2009-12-16 12:53:13 +0000.
4 processors detected.
Oolite Options: [Procedural Planets] [Docking Clearance] [Wormhole Scanner] [Target Incoming Missiles]

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

[joystickHandler.init]: Number of joysticks detected: 0
[display.mode.list.native]: Windows native resolution detected: 1280 x 1024
[rendering.opengl.version]: OpenGL renderer version: 2.1.2 ("2.1.2")
Vendor: NVIDIA Corporation
Renderer: GeForce 6150SE nForce 430/PCI/SSE2/3DNOW!
[rendering.opengl.extensions]: OpenGL extensions (140):
GL_ARB_color_buffer_float GL_ARB_copy_buffer GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_barrier GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control 
[searchPaths.dumpAll]: ---> OXP search paths:
(Resources, ../AddOns, "../AddOns/The Feudal States v1.0.oxp")
[dataCache.upToDate]: Data cache is up to date.
[script.load.world.listAll]: Loaded 11 world scripts: "feudal-challenge.js" 1.0, "feudal-escape-pod.js" 1.0, "feudal-mission.js" 1.0, "feudal-planetfall.js" 1.0, "feudal-promotion.js" 1.0, "feudal-tournament.js" 1.0, "oolite-cloaking-device" 1.73.4, "oolite-constrictor-hunt" 1.73.4, "oolite-nova" 1.73.4, "oolite-thargoid-plans" 1.73.4, "oolite-trumbles" 1.73.4
[dataCache.willWrite]: About to write data cache.
[dataCache.write.success]: Wrote data cache.
[script.addShips.failed]: ***** SCRIPT ERROR: in <anonymous actions>, addShipsAtPrecisely: could not add 4 ships with role '-knight'
[dataCache.willWrite]: About to write data cache.
[dataCache.write.success]: Wrote data cache.

Othertimes even that SCRIPT ERROR hasn't showed up.
Any help greatly appreciated.

Posted: **Wed Dec 16, 2009 2:26 pm**

Edmund wrote:
Oolite version 1.73.4 (x86-32 test release)

Have you ever tried with one of the latest trunk builds? If not, have you DEP (Data Execution Prevention) turned on or off?

I just wonder whether this might be a timer related problem...however the newer trunk builds seem to be proof against trouble with DEP.

Screet

Posted: **Wed Dec 16, 2009 3:49 pm**

Screet wrote:
Have you ever tried with one of the latest trunk builds? If not, have you DEP (Data Execution Prevention) turned on or off?

Screet

DEP is excluded for Oolite.

Just tried with latest Trunk 1.74.0.2885 (excluded DEP for that too), same result, crash as begin hyperspace to Aronar, with vanilla Jameson direct from Lave and no other OXPs installed.

Incidentally, My main commanders Griff Cobra MkIII has lost it's custom paint job and decal in the trunk version. The shipdata.plist edits and save game edits are the same as 1.73.4 and it works there.