Cascade mine Glitch?

[Pureskill123]

At the end of an Ooolite session, I thought I'd muck-around and decided to purchase and use several Quirium cascade mines on station with a viper patrolling around it, just for kicks. After deploying the mines and using my injectors to high-tail it out of there, I recieved a Right on Commander message, and when I checked my kill count it had rose from 597 to approx. 800!!!

I tried this again, this time coaxing more vipers out of the station by shooting it, then after several vipers appeared I repeated my above action. Kill count = over 1000. I've just reloaded Oolite hours later, found a solitary Boa and did the same. My kill count rose by 59...

So what is this? It seems ridiculous that I could spend 2500 on a CQM, go to a Corporate state, find a cluster of ships and deploy said CQM for 500 or so to my kill count, then use an escape pod (1000 credits) to clear my legal status. With time, I could easily spend 35000 of my 60k credits for 5000 kills, I doubt anyone else has done this so it must be a bug...right?

I hardly want to get an Elite ranking dishonestly, not to mention the mission access.

[uua90]

Remember that Q-bombs create a domino effect-- the sphere of destruction impacts ships in range, which in turn create their own spheres of destruction. It doesn't stop until there aren't any more ships.

So in practice, if you are in a corporate system with a high volume of traffic, you could rack up the kills in a hurry.

The Anarchies.oxp gets rid of the Escape Capsule "bug" that clears your legal status. But there's nothing stopping you from causing a massacre in G1 and hopping over to G2 to start a new life.

It's dishonest for sure-- when you drop it next to a station. But when you're being swarmed by bad guys and down to your last energy bank, it can be the difference between life and death... if you're fast enough.

[CheeseRedux]

Then again, there's the tried & tested method of visiting the [wiki]Tionisla_Orbital_Graveyard[/wiki] loaded with a Q-bomb...

[Eric Walch]

Subject: Cascade mine Glitch?

Then again, there's the tried & tested method of visiting the [wiki]Tionisla_Orbital_Graveyard[/wiki] loaded with a Q-bomb...

I have been working on an update of that oldie. When that one is released, there will be no big kill-count anymore in the graveyard.

[Gimi]

I have been working on an update of that oldie. When that one is released, there will be no big kill-count anymore in the graveyard.

Brilliant, been waiting for an update to that one. I like OXP's that make the Ooniverse match Elite and Oolite stories. Will we be seeing different types of ships as opposed to only seeing Adders in the current version.

[Pureskill123]

Thanks for the replies all.

uua90:

"Remember that Q-bombs create a domino effect-- the sphere of destruction impacts ships in range, which in turn create their own spheres of destruction. It doesn't stop until there aren't any more ships."

Well yes, I considered that. As unlikely as it sounded, I assumed two things at first.

a) That Vipers counted as more than one kill. "Extra credit", or something.
b) That several vipers were dispatched while the AOE was in, well, effect.

But when lasering Vipers (for the first time) I was rewarded with one kill, so that's why I tried to hit a lone ship with it, away from the station and see what happens...which I already wrote in my first post:

"I've just reloaded Oolite hours later, found a solitary Boa and did the same. My kill count rose by 59..."

59 kills for a single ship sounds like an odd Domino effect in the Ooniverse

[Eric Walch]

Brilliant, been waiting for an update to that one. I like OXP's that make the Ooniverse match Elite and Oolite stories. Will we be seeing different types of ships as opposed to only seeing Adders in the current version.

yes and no...
Selezen only added the adders to have starting models when creating the oxp. It was always intended to replace them with just monuments. 2 or 3 years ago Selezen published such an update, but this was never added on the wiki. Result is that everybody is still used to see the rusty adders. Selezen dislikes this and wants them out. So my current compromise is to divide all data over 3 oxps.
- Main one with all the scripting and some basic monuments to get the best performance on low end computers.
- Package with the more complex monuments. (A lot of work went into that by some people and it would be a shame loosing them)
- Package with a mix of rusty ships. So, folks that liked the rusty ship can install it in addition.

The additional packs just makes that some of the simple monuments are replaced with the new ones. And everyone can add models to their own packs when he likes.

Its ready for some months, but it is still missing my final inspiration to make it a release. My current state you can download here. As far as I am aware its bug free and needs only some minor cosmetic adjustments and the documentation.

"I've just reloaded Oolite hours later, found a solitary Boa and did the same. My kill count rose by 59..."

59 kills for a single ship sounds like an odd Domino effect in the Ooniverse

That sounds like something buggy if the observation is correct. While working on the graveyard I didn't notice this effect. All monuments have a ship-script that lowers the player.score by just one when killed by the player. Now, when the player q-bombs the graveyard with its 200 ships, the score rises only by a few point that are fully explainable by the few normal ships that fly in the graveyard. No ship was counted twice.
That was tested with trunk, but I think 1.74 should do the same.

[Pureskill123]

That sounds like something buggy if the observation is correct. While working on the graveyard I didn't notice this effect. All monuments have a ship-script that lowers the player.score by just one when killed by the player. Now, when the player q-bombs the graveyard with its 200 ships, the score rises only by a few point that are fully explainable by the few normal ships that fly in the graveyard. No ship was counted twice.
That was tested with trunk, but I think 1.74 should do the same.

Just to clarify, I'm not talking about the graveyard. That Oxp may have different script to destroying ships in the "vanilla" game, but I'm sure you get the same thing when using a CQM on normal ships right.

So, is there any way I can fix this? I want to be able to use QCM's after all, not avoid them because of the extra kills I get...

[another_commander]

Alright, so any way I can fix it? I want to be able to use QCM's after all, not avoid them because of the extra kills I get...

Can you please try to use the QMine without any OXPs? Smells like some script is getting in the way.

[Pureskill123]

Alright, so any way I can fix it? I want to be able to use QCM's after all, not avoid them because of the extra kills I get...

Can you please try to use the QMine without any OXPs? Smells like some script is getting in the way.

Yeah, I just removed the AddOns folder and each kill counts as one. Would you like the list of Oxp's I currently use?

[another_commander]

That would help track down the problem. Even better, install your OXPs, run the game again, detonate the qmine to initiate the bug, then exit the game and post here Latest.log.

[Pureskill123]

Interesting.

I thought it was the Fual Collector OXP, as my log displayed this:

[script.javaScript.warning.ooliteDefinedError]: ----- JavaScript warning (Fuel Collector 0.06): Ship.hasEquipment("EQ_FRAME_FUEL_COLLECTOR") is deprecated, use ship.equipmentStatus("EQ_FRAME_FUEL_COLLECTOR") == "EQUIPMENT_OK" instead.
[script.javaScript.warning.ooliteDefinedError]: ----- JavaScript warning (Fuel Collector 0.06): Ship.hasEquipment("EQ_FRAME_FUEL_COLLECTOR") is deprecated, use ship.equipmentStatus("EQ_FRAME_FUEL_COLLECTOR") == "EQUIPMENT_OK" instead.
[script.javaScript.warning.ooliteDefinedError]: ----- JavaScript warning (<unidentified script>): The event handler shipDestroyedTarget has been renamed to shipTargetDestroyed. The script Fuel Collector must be updated. The old form will not be supported in future versions of Oolite.
[script.javaScript.warning.ooliteDefinedError]: (null), line 0.
[script.javaScript.warning.ooliteDefinedError]: ----- JavaScript warning (Fuel Collector 0.06): Ship.hasEquipment("EQ_FRAME_FUEL_COLLECTOR") is deprecated, use ship.equipmentStatus("EQ_FRAME_FUEL_COLLECTOR") == "EQUIPMENT_OK" instead.

But after removing it and trying again, still had the same problem. And it looks like the Fuel collector has an issue too

Anyway here's my latest.log (Without the fuel collector):

[log.header]: Opening log for Oolite version 1.74.2 (x86-32 test release) under Windows at 2011-01-21 14:00:21 +0000.
2 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: 0
[display.mode.list.native]: Windows native resolution detected: 1152 x 864
[searchPaths.dumpAll]: Unrestricted Mode - Resources paths:
Resources
../AddOns
../AddOns/BGS-A1.3.2.oxp
../AddOns/Cabal_Common_Library1.0.oxp
../AddOns/captKev_dodo.oxp
../AddOns/Diso.oxp
../AddOns/display_reputation.oxp
../AddOns/Famous_Planets_v2.5.oxp
../AddOns/Fuel Station 1.31.oxp
../AddOns/Fuel Tank v2.2.oxp
../AddOns/griff_asteroids_normalmapped.oxp
../AddOns/griff_rock_hermit_fullsize_textures.oxp
../AddOns/griff_shipset_all_in_1.oxp
../AddOns/Lave.oxp
../AddOns/MilHUD-v3.4.oxp
../AddOns/OXPConfig2.0.1.oxp
../AddOns/Snoopers2.0.9.oxp
../AddOns/System_Redux.oxp
../AddOns/Target Autolock Plus 1.10.oxp
../AddOns/Tianve1.3.oxp
../AddOns/Welcome Mat 1.10.oxp
[rendering.opengl.version]: OpenGL renderer version: 3.3.10317 ("3.3.10317 Compatibility Profile Context")
Vendor: ATI Technologies Inc.
Renderer: ATI Radeon HD 4600 Series
[rendering.opengl.extensions]: OpenGL extensions (178):
GL_ATI_texture_mirror_once, GL_ARB_framebuffer_sRGB, GL_AMD_draw_buffers_blend, GL_ARB_depth_texture, GL_ARB_texture_env_add, GL_NV_texture_barrier, GL_EXT_pixel_buffer_object, GL_ARB_draw_instanced, GL_EXT_texture_compression_rgtc, GL_ARB_half_float_vertex, GL_EXT_texture3D, GL_EXT_compiled_vertex_array, GL_EXT_texture_shared_exponent, GL_EXT_separate_specular_color, GL_ARB_framebuffer_object, GL_EXT_shadow_funcs, GL_EXT_texture_buffer_object_rgb32, GL_EXT_texture_cube_map, GL_EXT_rescale_normal, GL_ARB_shader_texture_lod, GL_ATI_draw_buffers, GL_ARB_transpose_matrix, GL_ARB_texture_rgb10_a2ui, GL_ARB_texture_cube_map_array, GL_ARB_texture_compression_rgtc, GL_ARB_texture_border_clamp, GL_ARB_multisample, GL_ARB_half_float_pixel, GL_AMD_seamless_cubemap_per_texture, GL_ATI_separate_stencil, GL_ARB_texture_non_power_of_two, GL_EXT_bgra, GL_ARB_sync, GL_EXT_texture_env_dot3, GL_EXT_direct_state_access, GL_EXT_provoking_vertex, GL_SUN_multi_draw_arrays, GL_ARB_sampler_objects, GL_ARB_vertex_shader, GL_ARB_shader_objects, GL_ARB_map_buffer_range, GL_NV_texgen_reflection, GL_EXT_multi_draw_arrays, GL_AMDX_debug_output, GL_EXT_texture_object, GL_ARB_vertex_program, GL_KTX_buffer_region, GL_EXT_framebuffer_sRGB, GL_ATI_texture_env_combine3, GL_ARB_texture_float, GL_ARB_imaging, GL_AMD_sample_positions, GL_ATI_texture_compression_3dc, GL_ARB_draw_buffers_blend, GL_AMD_shader_stencil_export, GL_ARB_fragment_coord_conventions, GL_AMDX_vertex_shader_tessellator, GL_EXT_stencil_wrap, GL_EXT_bindable_uniform, GL_EXT_texture_swizzle, GL_NV_primitive_restart, GL_EXT_framebuffer_blit, GL_ARB_uniform_buffer_object, GL_ARB_vertex_array_bgra, GL_ARB_texture_gather, GL_ARB_texture_compression, GL_EXT_blend_color, GL_ARB_vertex_array_object, GL_EXT_blend_minmax, GL_ARB_texture_query_lod, GL_EXT_texture_integer, GL_EXT_gpu_shader4, GL_ARB_sample_shading, GL_EXT_transform_feedback, GL_ARB_shader_bit_encoding, GL_EXT_texture_lod, GL_EXT_texture_compression_s3tc, GL_EXT_subtexture, GL_ARB_occlusion_query2, GL_ARB_timer_query, GL_ARB_point_sprite, GL_ARB_depth_clamp, GL_AMD_vertex_shader_tessellator, GL_EXT_vertex_array, GL_EXT_abgr, GL_NV_blend_square, GL_ARB_vertex_buffer_object, GL_ARB_instanced_arrays, GL_EXT_framebuffer_multisample, GL_ATI_envmap_bumpmap, GL_NV_conditional_render, GL_ARB_multitexture, GL_EXT_vertex_array_bgra, GL_ARB_seamless_cube_map, GL_ARB_copy_buffer, GL_ARB_draw_elements_base_vertex, GL_ARB_transform_feedback2, GL_ARB_geometry_shader4, GL_ARB_transform_feedback3, GL_ARB_shadow, GL_EXT_draw_instanced, GL_EXT_blend_subtract, GL_ARB_fragment_program_shadow, GL_ARB_shader_stencil_export, GL_ARB_window_pos, GL_IBM_texture_mirrored_repeat, GL_EXT_texture_lod_bias, GL_ATI_meminfo, GL_ARB_texture_multisample, GL_EXT_texture_snorm, WGL_EXT_swap_control, GL_ARB_texture_env_crossbar, GL_ARB_point_parameters, GL_ARB_shadow_ambient, GL_ARB_depth_buffer_float, GL_NV_float_buffer, GL_ARB_vertex_type_2_10_10_10_rev, GL_EXT_timer_query, GL_EXT_texture_edge_clamp, GL_EXT_copy_texture, GL_ARB_texture_rg, GL_EXT_texture_sRGB, GL_ARB_texture_env_combine, GL_WIN_swap_hint, GL_ARB_fragment_program, GL_AMD_performance_monitor, GL_ARB_explicit_attrib_location, GL_EXT_packed_float, GL_AMD_texture_cube_map_array, GL_EXT_texture_filter_anisotropic, GL_EXT_texgen_reflection, GL_EXT_histogram, GL_ATI_fragment_shader, GL_EXT_draw_range_elements, GL_ARB_pixel_buffer_object, GL_EXT_texture_buffer_object, GL_EXT_copy_buffer, GL_EXT_packed_depth_stencil, GL_ARB_texture_snorm, GL_ARB_texture_rectangle, GL_EXT_geometry_shader4, GL_EXT_fog_coord, GL_AMD_conservative_depth, GL_NV_half_float, GL_SGIS_texture_lod, GL_EXT_gpu_program_parameters, GL_ARB_fragment_shader, GL_ARB_shading_language_100, GL_EXT_secondary_color, GL_AMD_debug_output, GL_EXT_point_parameters, GL_ARB_draw_buffers, GL_SGIS_generate_mipmap, GL_NV_copy_depth_to_color, GL_EXT_texture_rectangle, GL_EXT_draw_buffers2, GL_AMD_texture_texture4, GL_ARB_blend_func_extended, GL_AMD_name_gen_delete, GL_NV_explicit_multisample, GL_EXT_blend_func_separate, GL_ARB_texture_cube_map, GL_ARB_texture_buffer_object, GL_EXT_texture_array, GL_ARB_occlusion_query, GL_EXT_texture_mirror_clamp, GL_EXT_packed_pixels, GL_EXT_framebuffer_object, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_env_dot3, GL_EXT_texture_compression_latc, GL_ARB_provoking_vertex, GL_EXT_blend_equation_separate, GL_ATI_texture_float, GL_ARB_color_buffer_float, GL_EXT_texture_env_add, GL_SGIS_texture_edge_clamp, GL_EXT_texture_env_combine
[rendering.opengl.shader.support]: Shaders are supported.
[rendering.opengl.shader.mode]: Shader mode set to SHADERS_FULL.
[script.load.world.listAll]: Loaded 19 world scripts:
BGS-M 1.3.2
Cabal_Common_Functions 1.0
Cabal_Common_Keyboard 1.0
display-reputation-contract 1.1
display-reputation-passenger 1.1
Famous Planets 2 Launch Script 2.0.2
FuelStation-Setup 1.31
genericHUDswitch.js 1.01, modified by Wyvern
oolite-cloaking-device 1.74.2
oolite-constrictor-hunt 1.74.2
oolite-nova 1.74.2
oolite-thargoid-plans 1.74.2
oolite-tianve 1.3
oolite-trumbles 1.74.2
OXPConfig 2.0.1
snoopers 2.0.9
System Redux 1.2 1.2
targetAutolock 1.10
Welcome Information Script 1.1
[loading.complete]: ========== Loading complete. ==========
[script.load.world.listAll]: Loaded 19 world scripts:
BGS-M 1.3.2
Cabal_Common_Functions 1.0
Cabal_Common_Keyboard 1.0
display-reputation-contract 1.1
display-reputation-passenger 1.1
Famous Planets 2 Launch Script 2.0.2
FuelStation-Setup 1.31
genericHUDswitch.js 1.01, modified by Wyvern
oolite-cloaking-device 1.74.2
oolite-constrictor-hunt 1.74.2
oolite-nova 1.74.2
oolite-thargoid-plans 1.74.2
oolite-tianve 1.3
oolite-trumbles 1.74.2
OXPConfig 2.0.1
snoopers 2.0.9
System Redux 1.2 1.2
targetAutolock 1.10
Welcome Information Script 1.1
[gameController.exitApp]: .GNUstepDefaults synchronized.

Closing log at 2011-01-21 14:01:39 +0000.

[Cmdr James]

Makes me wonder if we should stop ships from launching if there is a q sphere anywhere near the docking point....?

Seems a bit odd for people to launch into certain death

[Commander McLane]

Makes me wonder if we should stop ships from launching if there is a q sphere anywhere near the docking point....?

Seems a bit odd for people to launch into certain death

Seems sensible.

However, I very much doubt that launching ships would raise the kill count that much. The first post claims a kill count of 200(!), which is way more than the total entity count in a typical Oolite system (70ish in vanilla Oolite, up to 140ish with OXPs), and most of the entities are nowhere near the main station. So there is absolutely no way that a q-bomb anywhere in the system could cause 200 kills (unless it's in the middle of an Assassins scenario, but Assassins is not on his OXP list).

The kill number reminds me of the each-subentity-counts-as-a-kill bug, but that has been squashed before 1.74.2. And still, even if there were 40 ships in the vicinity of the main station (which is an extremely high number), each of them would have to have five subentities on average, which is again unlikely, given that the standard ships contribute exactly 0 to the mix.

In other words: the kill count numbers seem absolutely buggy to me, but I have no idea what could have caused them.

[Pureskill123]

Makes me wonder if we should stop ships from launching if there is a q sphere anywhere near the docking point....?

Seems a bit odd for people to launch into certain death

Seems sensible.

However, I very much doubt that launching ships would raise the kill count that much. The first post claims a kill count of 200(!), which is way more than the total entity count in a typical Oolite system (70ish in vanilla Oolite, up to 140ish with OXPs), and most of the entities are nowhere near the main station. So there is absolutely no way that a q-bomb anywhere in the system could cause 200 kills (unless it's in the middle of an Assassins scenario, but Assassins is not on his OXP list).

The kill number reminds me of the each-subentity-counts-as-a-kill bug, but that has been squashed before 1.74.2. And still, even if there were 40 ships in the vicinity of the main station (which is an extremely high number), each of them would have to have five subentities on average, which is again unlikely, given that the standard ships contribute exactly 0 to the mix.

In other words: the kill count numbers seem absolutely buggy to me, but I have no idea what could have caused them.

He's probably talking about in general.

I'm surprised no-one else has encountered this, the first thing I did was do a Search.

Has the log not helped? I think I'll see which AddOn is conflicting with the Script. Post results later...