For information and discussion about Oolite.
https://bb.oolite.space/
Diziet Sma wrote:Most Ooliters do, as a matter of fact..dertien wrote:Don't tell me you're all playing oolite on dinosaurs
.23:05:58.480 [plist.parse.failed]: Failed to parse /Applications/oolite-trunk/AddOns/ZZ_GrOovy_bbs_adder.oxp/Config/shipdata.plist as a property list.
Unexpected character { at line 1
Code: Select all
Opening log for Oolite development version 1.79-131225 (x86-64 test release) under Mac OS X Version 10.7.5 (Build 11G63b) at 2013-12-25 12:05:57 +0000.
Machine type: MacBook2,1, 2048 MiB memory, 2 x x86 (Core 2/Merom) @ 2000 MHz.
Build options: OpenAL, JavaScript console support, Debug plug-in support, OXP verifier, localization tools, debug GraphViz support, JavaScript profiling.
Note that the contents of the log file can be adjusted by editing logcontrol.plist.
23:05:57.890 [dataCache.rebuild.pathsChanged]: Cache is stale (search paths have changed). Rebuilding from scratch.
23:05:58.427 [rendering.opengl.version]: OpenGL renderer version: 1.4.0 ("1.4 APPLE-7.4.1"). Vendor: "Intel Inc.". Renderer: "Intel GMA 950 OpenGL Engine".
23:05:58.427 [rendering.opengl.extensions]: OpenGL extensions (91):
GL_ARB_texture_border_clamp, GL_ARB_shadow, GL_EXT_blend_equation_separate, GL_EXT_packed_depth_stencil, GL_EXT_texture_compression_dxt1, GL_APPLE_pixel_buffer, GL_APPLE_element_array, GL_EXT_framebuffer_object, GL_ARB_fragment_program, GL_EXT_framebuffer_sRGB, GL_APPLE_packed_pixels, GL_ARB_texture_env_crossbar, GL_ARB_shader_objects, GL_ARB_window_pos, GL_EXT_texture_compression_s3tc, GL_EXT_transform_feedback, GL_APPLE_ycbcr_422, GL_APPLE_object_purgeable, GL_ARB_shading_language_100, GL_EXT_separate_specular_color, GL_EXT_fog_coord, GL_EXT_texture_sRGB, GL_APPLE_client_storage, GL_APPLE_vertex_array_object, GL_ARB_provoking_vertex, GL_ARB_texture_cube_map, GL_APPLE_row_bytes, GL_EXT_texture_rectangle, GL_EXT_gpu_program_parameters, GL_IBM_rasterpos_clip, GL_ARB_draw_instanced, GL_ARB_point_sprite, GL_ARB_texture_env_combine, GL_ARB_vertex_buffer_object, GL_ARB_texture_mirrored_repeat, GL_ARB_point_parameters, GL_ARB_transpose_matrix, GL_NV_blend_square, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_ARB_draw_elements_base_vertex, GL_ARB_fragment_program_shadow, GL_EXT_abgr, GL_NV_texgen_reflection, GL_ARB_multitexture, GL_EXT_blend_color, GL_ARB_vertex_blend, GL_APPLE_aux_depth_stencil, GL_EXT_geometry_shader4, GL_SGIS_texture_lod, GL_ARB_pixel_buffer_object, GL_ARB_texture_rectangle, GL_EXT_blend_func_separate, GL_EXT_draw_range_elements, GL_EXT_provoking_vertex, GL_ATI_separate_stencil, GL_EXT_shadow_funcs, GL_SGIS_texture_edge_clamp, GL_ATI_texture_env_combine3, GL_APPLE_texture_range, GL_EXT_bgra, GL_EXT_blend_subtract, GL_APPLE_flush_render, GL_APPLE_rgb_422, GL_NV_light_max_exponent, GL_APPLE_flush_buffer_range, GL_EXT_multi_draw_arrays, GL_APPLE_vertex_point_size, GL_EXT_blend_minmax, GL_APPLE_vertex_program_evaluators, GL_EXT_texture_env_add, GL_EXT_stencil_two_side, GL_ARB_instanced_arrays, GL_ARB_texture_env_add, GL_ARB_fragment_shader, GL_ARB_texture_non_power_of_two, GL_ARB_texture_compression, GL_EXT_clip_volume_hint, GL_ARB_vertex_program, GL_ARB_sync, GL_EXT_rescale_normal, GL_APPLE_fence, GL_APPLE_vertex_array_range, GL_SGIS_generate_mipmap, GL_ARB_texture_env_dot3, GL_ARB_depth_texture, GL_EXT_stencil_wrap, GL_APPLE_specular_vector, GL_ARB_vertex_shader, GL_EXT_secondary_color, GL_APPLE_transform_hint
23:05:58.439 [rendering.opengl.gpuSpecific]: Matched GPU configuration "Intel GMA 900/950 family".
23:05:58.439 [rendering.opengl.shader.support]: Shaders are supported.
23:05:58.458 [dataCache.rebuild.pathsChanged]: Cache is stale (search paths have changed). Rebuilding from scratch.
23:05:58.459 [searchPaths.dumpAll]: Unrestricted mode - resource paths:
/Applications/oolite-trunk/Oolite-Trunk.app/Contents/Resources
/Applications/oolite-trunk/AddOns
/Applications/oolite-trunk/AddOns/Debug.oxp
/Applications/oolite-trunk/AddOns/ZZ_GrOovy_bbs_adder.oxp
/Applications/oolite-trunk/AddOns/ZZ_GUI_Vanisher_1.0.oxp
23:05:58.468 [shipData.load.begin]: Loading ship data.
23:05:58.480 [plist.parse.failed]: Failed to parse /Applications/oolite-trunk/AddOns/ZZ_GrOovy_bbs_adder.oxp/Config/shipdata.plist as a property list.
Unexpected character { at line 1
23:05:59.658 [script.load.world.listAll]: Loaded 15 world scripts:
HUD Vanisher - BBS-Hud 1.0
oolite-cloaking-device 1.79
oolite-constrictor-hunt 1.79
oolite-contracts-cargo 1.79
oolite-contracts-helpers 1.79
oolite-contracts-parcels 1.79
oolite-contracts-passengers 1.79
oolite-libPriorityAI 1.79
oolite-nova 1.79
oolite-populator 1.79
oolite-primable-equipment-register 1.79
oolite-registership 1.79
oolite-thargoid-plans 1.79
oolite-trumbles 1.79
oolite-tutorial 1.79
23:06:00.578 [debugSupport.load.success]: Debug Bundle loaded successfully.
23:06:06.418 [startup.complete]: ========== Loading complete in 8.35 seconds. ==========
23:06:13.728 [script.load.world.listAll]: Loaded 15 world scripts:
HUD Vanisher - BBS-Hud 1.0
oolite-cloaking-device 1.79
oolite-constrictor-hunt 1.79
oolite-contracts-cargo 1.79
oolite-contracts-helpers 1.79
oolite-contracts-parcels 1.79
oolite-contracts-passengers 1.79
oolite-libPriorityAI 1.79
oolite-nova 1.79
oolite-populator 1.79
oolite-primable-equipment-register 1.79
oolite-registership 1.79
oolite-thargoid-plans 1.79
oolite-trumbles 1.79
oolite-tutorial 1.79
23:06:39.969 [exit.context]: Exiting: Cocoa terminate event.
Closing log at 2013-12-25 12:06:40 +0000.Edit: All the above using Windows nightly 65f3e2e.Latest.log wrote:13:22:58.854 [script.javaScript.timeLimit]: ***** ERROR: Script "genericHUDswitch - MilHUD.js" ran for 3.29807 seconds and has been terminated.
13:22:58.854 [script.javaScript.stackTrace]: 0 (milhudscript.js:47) <anonymous function>
13:22:58.854 [script.javaScript.stackTrace]: this: [Script "genericHUDswitch - MilHUD.js" version 1.05, modified by Wyvern for MilHUD]
13:22:58.854 [script.javaScript.stackTrace]: oldCondition: 0
13:22:58.854 [script.javaScript.stackTrace]: newCondition: 2
13:25:43.371 [script.javaScript.timeLimit]: ***** ERROR: Script "genericHUDswitch - MilHUD.js" ran for 3.38308 seconds and has been terminated.
13:25:43.371 [script.javaScript.stackTrace]: 0 (milhudscript.js:47) <anonymous function>
13:25:43.371 [script.javaScript.stackTrace]: this: [Script "genericHUDswitch - MilHUD.js" version 1.05, modified by Wyvern for MilHUD]
13:25:43.371 [script.javaScript.stackTrace]: oldCondition: 2
13:25:43.371 [script.javaScript.stackTrace]: newCondition: 1
When I have finished with the shippack, I will plug the beamer on and see if it works well with an old xbox console.pagroove wrote:I really think its a Mac thingy. But only only one with a Mac can test that.
Next time I can post a latest.log to see if something is in there.
I have also a PC but nowadays I play on the MBP because it is so convenient on the couch playing Oolite
It's the way you save the images. With 6Gb main RAM and 2Gb on the graphics card, you're getting away with it, though.dertien wrote:I am remaking the mod so low spec machines can run it, and I will save the PNG's as 8 bit where I can not 24, dunno how to solve the mac problem yet. Can anyone test on Mac if the retro hud works that is included with the Deepspace oxp ? it also contains an image. It might be scripting or the way I save images.
Well, you're correct that you inherited the problem from Cmdr Wyvern's MilHUD.dertien wrote:I cannot replicate the error for the adder, and I have looked at the shipdata.plist file, not a bracket too much or too less there.
I used MilHud for months without difficulty on Linux - GNUstep (which is also used on Windows) seems to process them fine - so that's probably why the lack of reports. The Mac parser is definitely a lot pickier about them, though.Diziet Sma wrote:And I can show you the problem.. There's a spurious CR (carriage-return) character immediately after the opening curly bracket. Only Windows uses CRs, and in Mac & Linux (which only use LF or line-feed) they cause no end of trouble.
yes, you're right.. the Mac is far fussier about such things.. although sometimes Linux can be.. the xml2ns.py script used for converting .plists won't work in Linux unless the CRs are stripped out.. but GNUstep itself is more forgiving.Yes,cim wrote:It's the way you save the images. With 6Gb main RAM and 2Gb on the graphics card, you're getting away with it, though.
I kinda see now what you guys mean. It was part lazyness to not recut them to 16*16 px and position them appropriately, and also indeed ignoring what kind of machines you guys here are using. I am spoiled with my machine, since it can run 3 instances of Oolite, Gimp, with 5 images open, excel open and a browser with 150 tabs all at the same time without coughing.So let me rephrase that with an example so that we are both on the same channel here:cim wrote:Take "eqt/wormholescanner.png" as an example. This is a 1600x900 PNG, almost entirely transparent, except for an area about 24x24 which contains the icon.
As it's not a power of two in size, on loading into Oolite this will be rescaled to a 2048x1024 texture, which will consume 8Mb of graphics memory [1] (2Mb if you switch it to a greyscale PNG which loses transparency support - 8-bit indexed will not help, though). As there's a lot of these images - I count 40, not all of which get loaded at once - then except on high-end machines you're going to need to swap them back and forth between the graphics card, system RAM, and even the disk if there's much else requiring textures to be loaded (like the spaceships, or the planet, for instance).
Okay that makes sense of course, I just didn't realize that the 9k of every "big icon" had such a metamorphosis kilobytewise when it gets rendered through Oolite.cim wrote:The correct approach is to have wormholescanner.png (and friends!) only contain the 32x32 pixels needed to contain the icon itself (in-memory size: 4k plus a few extra bytes for the container, which even on low-end machines is basically "who cares").
I am doing it by trial and error, and if you use grids and place a few, its easy to calculate for the others, thats no biggie.cim wrote:Then, in the HUD plists, adjust the 'width' and 'height' parameters to get it to the right size, and the 'x' and 'y' parameters to put it in the right place. The HUD is drawn on to a grid running from (-256,-256) to (256,256) centred to the screen. If you're expecting a widescreen monitor, you can probably assume that the X-axis will run considerably further out than +/-256; otherwise, best to keep within those coordinates. You can use the x_origin and y_origin parameters to move the grid origin from the centre of the screen to the centre of an edge, or a corner, if that makes it easier to position a particular item.
Well, I'll be damned, learned a lot today. Thanks for that info Diziet Sma, that was very helpful. I didn't realize even Notepad ++ (that I use of course) put so much rubbish into files, when not applying the correct format. So every plist file I ever opened should be resaved using that option. Well amen to that, without wanting to resort to blasphemyDiziet Sma wrote:And I can show you the problem.. There's a spurious CR (carriage-return) character immediately after the opening curly bracket. Only Windows uses CRs, and in Mac & Linux (which only use LF or line-feed) they cause no end of trouble.
In fact, the entire .plist is full of CR characters (you can several just in this screenshot), every one of which will cause Mac and Linux machines to have hissy-fits. I guess this means there aren't many, if any, Mac & Linux users using the MilHUD, or we'd have heard about it before now.
The solution is simple, fortunately.. open the .plist in Notepad++, go to Edit / "EOL conversion" and select Unix format. (There's a Mac option too, but ever since OSX switched to being based on BSD Unix, they use the same format for files, and Linux has always used Unix format.)
Now you just save the file again, and you're good to go. You might want to do the same with any other files you borrow or copy/paste from, too.
It will probably pay you to set this as your default in Notepad++, by the way.
Well, it's not really Notepad++'s fault.. it was just doing what Windows told it.dertien wrote:I didn't realize even Notepad ++ (that I use of course) put so much rubbish into files, when not applying the correct format
A quick check shows pretty much all the HUD .plists are liberally sprinkled with 'em.. so very probably, yes.dertien wrote:So you're saying that if I resave the Hud.plist the same way, there's a big chance that I might make Pagroove happy so he can finally see the new hud on his Mac ?
Thanks again.
Any texture file loaded by Oolite which is not a power of 2 in size will first be rescaled so it is a power of two in size. So you may as well make them that big to start with, or you get a (smallish) delay when first loading the texture as Oolite stretches or compresses it to fit, and it might not interpolate it at the quality you get out of a proper graphics program.dertien wrote:Let's say I have that yellow-green-red dashboard that is recut to 1600 px wide and 302 px high (instead of the original now which is 1600 * 900, with a minimum of transparency), and I have that same dashboard, but with a bigger canvas area and thus more transparency as a size of powers of two (lets say 2048 px by 512 px,) will the latter be less resource consuming or more, since it is bigger, but it's length and width are a power of two ?