Page 9 of 14

Re: RFC: re-squared-dux ...

Posted: Tue Jun 07, 2011 11:08 am
by Simon B
Trying to test the carriers - having trouble getting one to spawn like before ...

system.legacy_addShipsWithinRadius("testship", 1, "wpm", [0,0,0], 10000);

will happily spawn, say, role "asteroid" but refuses for anything custom. Just assigning my test ship to role asteroid didn't work. Seeing that is "legacy" I've been having a go changing this to something like:

system.addShips("testship", 1, 10000);

(if no position given the wp is assumed - possibly if I want to spawn more than one I need to explicitly request a randomized position+radius?).
Too tired now - try again tomorrow. Not sure I'm reading the docs properly.

Re: RFC: re-squared-dux ...

Posted: Tue Jun 07, 2011 11:29 am
by ADCK
I always just typed:

Code: Select all

:spawn name
where name is the role.

never worried about specifics, like where it spawns, as will spawn within scanner range.

Re: RFC: re-squared-dux ...

Posted: Tue Jun 07, 2011 1:26 pm
by Eric Walch
Simon B wrote:
system.legacy_addShipsWithinRadius("testship", 1, "wpm", [0,0,0], 10000);

will happily spawn, say, role "asteroid" but refuses for anything custom.
When it does work for asteroids, it should work for your custom roles also. I suspect the plist is not loaded or otherwise ignored because of a syntax error.
ADCK wrote:
I always just typed:

Code: Select all

:spawn name
where name is the role.

never worried about specifics, like where it spawns, as will spawn within scanner range.
That is a console macro and is definitely the easiest way for getting ships near the player with the console. :wink:

It actually does a this.T = system.addShips(PARAM, 1, player.ship.position, 10000); if (this.T) this.T = this.T[0]; else consoleMessage('command-error', 'Could not spawn "' + PARAM + '".'); and on spawning you have a reference to the ship in this.T

Re: RFC: re-squared-dux ...

Posted: Tue Jun 07, 2011 10:22 pm
by Simon B
Eric Walch wrote:
Simon B wrote:
system.legacy_addShipsWithinRadius("testship", 1, "wpm", [0,0,0], 10000);

will happily spawn, say, role "asteroid" but refuses for anything custom.
When it does work for asteroids, it should work for your custom roles also. I suspect the plist is not loaded or otherwise ignored because of a syntax error.
Well, that's what I thought!

However - the oxp has loaded with no errors in the logs and I can see the ship in the preview pane - even launch one from a station if I am the pilot.
Possibly there's something in a script blocking this? Perhaps remove the script assignment?

However (again) I have tried this with another custom role in another oxp which I know works because I've seen the things in the game.
Oh well - I'm awake now I'll go double-check.

Code: Select all

simon@envoy:~/.Oolite/Logs$ cat Latest.log
[log.header]: Opening log for Oolite version 1.74.2 (x86-32 test release) under Linux at 2011-06-07 22:34:32 +0000.
4 processors detected.
Oolite options: procedural planet textures, docking clearance, wormhole scanner, target incoming missiles, spoken messages, JavaScript console support, OXP verifier, localization tools, debug GraphViz support.

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

[joystickHandler.init]: Number of joysticks detected: 1
[display.mode.list.native]: X11 native resolution detected: 1600 x 900
[dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.
[searchPaths.dumpAll]: Unrestricted Mode - Resources paths:
    /usr/lib/Oolite/oolite.app/Resources
    AddOns
    ~/.Oolite/AddOns
    ~/.Oolite/AddOns/wakapiko-redux.oxp
    ~/.Oolite/AddOns/sb-navy.oxp
    ~/.Oolite/AddOns/re2dux-vipers.oxp
    ~/.Oolite/AddOns/RandomHits1.4.5.oxp
    ~/.Oolite/AddOns/odds.oxp
    ~/.Oolite/AddOns/re2dux.oxp
    ~/.Oolite/AddOns/re2dux-navy.oxp
    ~/.Oolite/AddOns/constrictor-sb.oxp
    ~/.Oolite/AddOns/sb-faves.oxp
    ~/.Oolite/AddOns/ubertharg.oxp
[rendering.opengl.version]: OpenGL renderer version: 2.1.0 ("2.1 Mesa 7.7.1")
Vendor: Tungsten Graphics, Inc
Renderer: Mesa DRI Intel(R) IGDNG_M GEM 20091221 2009Q4 x86/MMX/SSE2
[rendering.opengl.extensions]: OpenGL extensions (117):
GL_EXT_abgr, GL_ARB_texture_env_crossbar, GL_EXT_texture, GL_ARB_shadow, GL_IBM_texture_mirrored_repeat, GL_EXT_texture_edge_clamp, GL_EXT_separate_specular_color, GL_EXT_blend_minmax, GL_EXT_texture_object, GL_ARB_texture_env_add, GL_INGR_blend_func_separate, GL_ARB_shading_language_120, GL_NV_texture_env_combine4, GL_EXT_texture_cube_map, GL_EXT_blend_logic_op, GL_ARB_draw_elements_base_vertex, GL_EXT_texture_env_dot3, GL_IBM_rasterpos_clip, GL_EXT_framebuffer_blit, GL_ARB_texture_env_dot3, GL_NV_light_max_exponent, GL_EXT_framebuffer_object, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_3DFX_texture_compression_FXT1, GL_MESA_window_pos, GL_ARB_vertex_array_bgra, GL_ARB_multitexture, GL_EXT_stencil_wrap, GL_ARB_texture_border_clamp, GL_NV_depth_clamp, GL_NV_vertex_program, GL_ARB_texture_env_combine, GL_SGIS_texture_edge_clamp, GL_EXT_packed_pixels, GL_EXT_texture_env_add, GL_ARB_depth_clamp, GL_SGIS_texture_lod, GL_ARB_depth_texture, GL_ARB_transpose_matrix, GL_ARB_occlusion_query, GL_NV_texgen_reflection, GL_NV_packed_depth_stencil, GL_EXT_stencil_two_side, GL_ARB_shading_language_100, GL_ARB_seamless_cube_map, GL_ARB_fragment_program_shadow, GL_EXT_rescale_normal, GL_EXT_gpu_program_parameters, GL_ARB_map_buffer_range, GL_ARB_provoking_vertex, GL_ARB_pixel_buffer_object, GL_EXT_secondary_color, GL_SUN_multi_draw_arrays, GL_OES_read_format, GL_ARB_texture_mirrored_repeat, GL_ARB_copy_buffer, GL_EXT_vertex_array_bgra, GL_EXT_polygon_offset, GL_EXT_draw_range_elements, GL_EXT_blend_equation_separate, GL_ARB_half_float_pixel, GL_EXT_texture_lod_bias, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_swizzle, GL_SGIS_texture_border_clamp, GL_SGIS_generate_mipmap, GL_NV_texture_rectangle, GL_ARB_texture_rectangle, GL_ARB_texture_non_power_of_two, GL_ARB_point_sprite, GL_EXT_packed_depth_stencil, GL_ARB_vertex_shader, GL_ARB_vertex_buffer_object, GL_ARB_sync, GL_ARB_shader_objects, GL_EXT_provoking_vertex, GL_IBM_multimode_draw_arrays, GL_MESA_ycbcr_texture, GL_ATI_separate_stencil, GL_ARB_framebuffer_object, GL_EXT_texture_rectangle, GL_ARB_fragment_shader, GL_EXT_texture3D, GL_EXT_fog_coord, GL_EXT_subtexture, GL_MESA_texture_signed_rgba, GL_ARB_window_pos, GL_EXT_point_parameters, GL_ARB_fragment_program, GL_EXT_texture_env_combine, GL_ARB_vertex_program, GL_EXT_bgra, GL_ARB_texture_cube_map, GL_ARB_point_parameters, GL_EXT_compiled_vertex_array, GL_EXT_vertex_array, GL_ARB_multisample, GL_APPLE_client_storage, GL_ARB_vertex_array_object, GL_ARB_draw_buffers, GL_EXT_multi_draw_arrays, GL_ARB_texture_compression, GL_APPLE_vertex_array_object, GL_EXT_cull_vertex, GL_ATI_texture_env_combine3, GL_APPLE_packed_pixels, GL_EXT_blend_func_separate, GL_MESA_pack_invert, GL_EXT_texture_sRGB, GL_EXT_shadow_funcs, GL_ATI_blend_equation_separate, GL_EXT_blend_color, GL_NV_vertex_program1_1, GL_NV_blend_square, GL_EXT_pixel_buffer_object, GL_ATI_envmap_bumpmap
[rendering.opengl.shader.support]: Shaders are supported.
[rendering.opengl.shader.mode]: Shader mode set to SHADERS_SIMPLE.
[shipData.load.begin]: Loading ship data.
[script.load.world.listAll]: Loaded 7 world scripts:
    oolite-cloaking-device 1.74.2
    oolite-constrictor-hunt 1.74.2
    oolite-nova 1.74.2
    oolite-thargoid-plans 1.74.2
    oolite-trumbles 1.74.2
    Random_Hits 1.4.5
    SB Navy 0.9
[loading.complete]: ========== Loading complete. ==========
[script.load.world.listAll]: Loaded 7 world scripts:
    oolite-cloaking-device 1.74.2
    oolite-constrictor-hunt 1.74.2
    oolite-nova 1.74.2
    oolite-thargoid-plans 1.74.2
    oolite-trumbles 1.74.2
    Random_Hits 1.4.5
    SB Navy 0.9
[gameController.exitApp]: .GNUstepDefaults synchronized.

Closing log at 2011-06-07 22:35:37 +0000.
BTW: never got the console going in linux - anyone?

Re: RFC: re-squared-dux ...

Posted: Tue Jun 07, 2011 10:41 pm
by JensAyton
Simon B wrote:
BTW: never got the console going in linux - anyone?
As I recall, the basic procedure is to cd into the debug console source directory and run ./DebugConsole.py – which will immediately crash because it can’t find dependencies. Read the exception spew to find out what’s missing (“twisted” and “tkinter” are likely candidates), install it with package manager, rinse and repeat. Once it works, you’ll get a rather ugly window, at which point you can run Oolite and it will connect to the console.

Not the world’s greatest user experience, but very Linuxy. ;-)

I guess now would be a good time to remind the universe that [EliteWiki] the protocol is very simple as long as you have an XML parser, and implementing something better would be the work of a couple of weekends.

Re: RFC: re-squared-dux ...

Posted: Tue Jun 07, 2011 11:08 pm
by Simon B
Well it's time I updated anyway ... 1.75.2 here I come. [edit] ah - it's not part of the main source tarball? Found it ...

Seems I can stand corrected - the js snippet does not spawn asteroids after all ... that seems to have been a coincedence.
I take it the code is supposed to work as advertised then?

Code: Select all

this.name   = "Ship_Spawn_Script";
this.author   = "Thargoid";
this.copyright = "Creative Commons: attribution, non-commercial, sharealike.";
this.description = "Spawns a ship near the witchpoint on arrival";
this.version = "1.0";

this.shipWillExitWitchspace = function()
{
system.legacy_addShipsWithinRadius("asteroid", 10, "wpm", [0,0,0], 15000);
}
put it in a script called "uniquename.js" saved to an OXP /Config directory - should add 10 asteroids well inside scanner range of the witchpoint?

note: technically I should be learning to script as well. I've got that artifact to script after all (since nobody else has volunteered <sniff>).

Re: RFC: re-squared-dux ...

Posted: Tue Jun 07, 2011 11:45 pm
by JensAyton
Simon B wrote:
put it in a script called "uniquename.js" saved to an OXP /Config directory
Ahh, there’s your problem. You need to do one of:
  • Call the file script.js.
  • Put it in Scripts/, and add a Config/world-scripts.plist containing ( "uniquename.js" ).

Re: RFC: re-squared-dux ...

Posted: Wed Jun 08, 2011 12:21 am
by Simon B
Cool - that did the trick.

I've practiced docking with it - I found that I don't get to fly into the dock to, um, dock ... even though the back of the docking bay is close to the models origin ... so what determines this? Its rather tricky - the thing uses the behemoth scripts but equesting docking clearance does not make it slow or stop.

I've tried shooting at it it shoots back... and launches defenders. I tried to get it to shoot me with turrets - which seemed intermittant so I decided to give it some thargoids to fight ... it used all it's weapons on the thargoids. The only thing I have not tested are the fwd lasers mounted inside the docking bay.

Oh yeah - when the fight is over, everybody just stops. According to the script comments, the defenders are supposed to appraoch the mothership and dock with it, the the lot of them just go back on patrol. Could it be interstellar space that is messing with this? I'll have to go look see if I need to write an extra action so if its in interstellar space, and there are no enemies to fight, it will jump out.

All I need now is to do the specular and the glows and I'll have something to show you.

Re: RFC: re-squared-dux ...

Posted: Wed Jun 08, 2011 7:04 am
by Commander McLane
Simon B wrote:
I've practiced docking with it - I found that I don't get to fly into the dock to, um, dock ... even though the back of the docking bay is close to the models origin ... so what determines this?
The position from where you see the docking rings animation is determined by the position of a subentity that has "dock" as part of its name. In other words, if you have a docking bay subentity, it is vital that you also name it so.
Simon B wrote:
Its rather tricky - the thing uses the behemoth scripts but equesting docking clearance does not make it slow or stop.
The handling of docking requests happens in AI. Which AI does it use?
Simon B wrote:
Oh yeah - when the fight is over, everybody just stops. According to the script comments, the defenders are supposed to appraoch the mothership and dock with it, the the lot of them just go back on patrol. Could it be interstellar space that is messing with this? I'll have to go look see if I need to write an extra action so if its in interstellar space, and there are no enemies to fight, it will jump out.
Again, the re-docking of defenders is governed by their AI, and the mother's AI. So it would be useful to know which AI they use.

Re: RFC: re-squared-dux ...

Posted: Wed Jun 08, 2011 7:32 am
by Eric Walch
Simon B wrote:
I've practiced docking with it - I found that I don't get to fly into the dock to, um, dock ... even though the back of the docking bay is close to the models origin ... so what determines this?
You are docked when 75% (could be eighty %, Im not fully sure) of your ship has passed the point of origin of the bay. Therefor is the origin of a bay not defined in the centre or back but always at its front.
Also make sure you defined the docking bay correct, or the system will generate a default bay in the ship centre. For to be recognised as dock with the old subentity definitions, the subentity name has to contain the word 'dock' somewhere in the name. Very user unfriendly, so better define it with the new method and add a is_dock key.

Re: RFC: re-squared-dux ...

Posted: Wed Jun 08, 2011 7:44 am
by Simon B
Commander McLane wrote:
The position from where you see the docking rings animation is determined by the position of a subentity that has "dock" as part of its name. In other words, if you have a docking bay subentity, it is vital that you also name it so.
Um - the ship is a single model. Hmmm... I could split it in two ... or just set "is_dock = yes;"? (thanks eric - that explains why the docking happens when it does (when most of the ship is between the two "horns" at the front).
The handling of docking requests happens in AI. Which AI does it use?
The ones in the behemoth OXP. I'm very uncreatively just making them all behemoth stuff ... I remember the same problem with the megaships using the same strategy - it looks like I'm using a more recent version than I did for the megaships though.

The ship continues it's patrol after eating a thargoid in system space.
Hmmm ... I didn't see it launch any though.

I'll have a closer look.

Re: RFC: re-squared-dux ...

Posted: Wed Jun 08, 2011 8:22 am
by Simon B
Argh: made the mistake of spawning 10 thargoids ... they won!
The uberthargs are quite effective.

OK now that's interesting - in system space, it does not want to attack thargoids - even when they attack it. Only it's escorts engage.

Re: RFC: re-squared-dux ...

Posted: Wed Jun 08, 2011 9:28 am
by Simon B
[typo]

Re: RFC: re-squared-dux ...

Posted: Wed Jun 08, 2011 9:34 am
by Commander McLane
Simon B wrote:
Argh: made the mistake of spawning 10 thargoids ... they won!
The uberthargs are quite effective.

OK now that's interesting - in system space, it does not want to attack thargoids - even when they attack it. Only it's escorts engage.
If you want to find out what a ship does and why (or why it doesn't do what you want it to do) AI-logging is what you need. I'm not sure how to enable it for one ship without using the JS-console, but I'm sure others will be able to help.

Re: RFC: re-squared-dux ...

Posted: Wed Jun 08, 2011 9:38 am
by Commander McLane
type = "standard";
doesn't make any sense in this old-style subentity array. I'm a little surprised that it doesn't make the whole plist void.