Random Hits OXP

[JensAyton]

I think it’s time to insert a reminder that a bunch of bugs with ship selections have been found in 1.71, and it’ll work completely differently in 1.72. :-)

[Commander McLane]

I've experienced the following strange behaviour for a couple of times now:

I am killing my mark using my lasers only. No WMDs, no missiles, no involvement of NPCs. Sometimes s/he abandons the ship and I kill the escape pod with my lasers only. No missiles, no WMDs, no involvement of NPCs. Yet I get fined for using unfair tactics.

It's quite annoying.

The only thing that could have gotten wrong is that I probably at some point during the fight I used the cloak in order to dodge his missiles. But please note, at the time of the kill I was not cloaked anymore.

A guess: the relevant variable mission_random_hits_whoshot is only set through the this.shipBeingAttacked-event in the target's ship script, not anymore through the this.shipDied-event. Could it be that during an ongoing attack mission_random_hits_whoshot gets reset when I use my cloak, but the this.shipBeingAttacked-event is not handled anymore, because my uncloaking doesn't start a new attack? This would basically mean that any use of the cloaking device at any point of a random hit would disqualify the hit. The only way to circumvent it would be to wait sufficiently long after uncloaking, so that the next salvo would get counted as a new attack by the engine, and therefore trigger the this.shipBeingAttacked-event again.

[Eric Walch]

I am killing my mark using my lasers only. No WMDs, no missiles, no involvement of NPCs. .... Yet I get fined for using unfair tactics.

I have not played RH much, but last week I reinstalled it and I also got fined for the first mark I killed.

To be complete: I flew to the system and saved there. Than I hired me some UPS escorts at the main station. It happened to be a system with a GRS station so I took a look there first, leaving my escorts behind around the main station. When I went back to the main station I noticed that my escorts were killing the escape pod. (They probably had also killed the mark). To get some credits for the kill I hurried up to make the final kill myself. This I just managed but I got fined for unfair play like you. No cloak was involved in this, only non player ships hitting the target.

[Commander McLane]

To get some credits for the kill I hurried up to make the final kill myself. This I just managed but I got fined for unfair play like you. No cloak was involved in this, only non player ships hitting the target.

Which actually should be treated differently altogether, because in tha case mission_random_hits_whoshot should be set to NPC_ATTACK, not be undefined, and is handled as an extra case by the script.

Question: How can I debug when event-handlers are fired? I have the strong suspicion that those are somehow the culprit.

[LittleBear]

Ah Yes Sorry. Its a bug introduced by the Optimised Script. It is fixed on the WIP versions which you can get here:-

http://www.box.net/shared/esaf3ygrpq

The WIP version also recognises accidental death causes (like the mark injectoring into an asteroid). In the previous version would unfairly treat this as a dishonerable player kill.

The trumble in the ScriptPatch is here:-

When you kill the victim WHO_SHOT is correctly set to player. The script sets the status to a player kill AND THEN RESETS THE WHO_SHOT VARIABLE:-

Code: Select all

			<!-- If the player killed the mark and no escape pod was launched or the player destroyed the pod, reset the short description and send a congratulations message.  -->
			<key>conditions</key>
			<array>
				<string>mission_random_hits_whoshot equal PLAYER_ATTACK</string>
			</array>
			<key>do</key>
			<array>
				<string>set: mission_random_hits_status COMPLETE</string>
				<string>removeMissionDestination: [mission_random_hits_planetnumber]</string>
				<string>setMissionDescription: random_hits_shortdescription2</string>
				<string>consoleMessage6s: [random_hits_complete_comms]</string>
				<string>reset: mission_random_hits_whoscooped</string>
				<string>reset: mission_random_hits_whoshot</string>
			</array>

However, as the variable who_shot is now undefined. The Dishonerable kill script gets run:-

Code: Select all

			<!-- The Game does not regard e-bombing q-mining or lasering whilst cloaked as an attack. Thus if whoshot is undefined and the Mark is dead, he's been got in a dishonerable way by the player!  -->
			<!-- The Player is credited with the kill, but as he's a cowardly custard he is fined and he won't earn any points for completing this hit!  -->
			<key>conditions</key>
			<array>
				<string>mission_random_hits_whoshot undefined</string>
			</array>
			<key>do</key>
			<array>
				<string>set: mission_random_hits_status COMPLETE</string>
				<string>awardCredits: -[mission_random_hits_fine]</string>
				<string>removeMissionDestination: [mission_random_hits_planetnumber]</string>
				<string>setMissionDescription: random_hits_shortdescription2</string>
				<string>consoleMessage6s: [random_hits_complete_ebomb]</string>
				<string>set: mission_random_hits_store_skill 0</string>
				<string>reset: mission_random_hits_whoscooped</string>
				<string>reset: mission_random_hits_whoshot</string>
			</array>
		</dict>

The fix is just to add the condition that the status is still KILLED, like this:-

Code: Select all

			<!-- The Game does not regard e-bombing q-mining or lasering whilst cloaked as an attack. Thus if whoshot is undefined and the Mark is dead, he's been got in a dishonerable way by the player!  -->
			<!-- The Player is credited with the kill, but as he's a cowardly custard he is fined and he won't earn any points for completing this hit!  -->
			<key>conditions</key>
			<array>
				<string>mission_random_hits_whoshot undefined</string>
			   	<string>mission_random_hits_status equal KILLED</string>
			</array>
			<key>do</key>
			<array>
				<string>set: mission_random_hits_status COMPLETE</string>
				<string>awardCredits: -[mission_random_hits_fine]</string>
				<string>removeMissionDestination: [mission_random_hits_planetnumber]</string>
				<string>setMissionDescription: random_hits_shortdescription2</string>
				<string>consoleMessage6s: [random_hits_complete_ebomb]</string>
				<string>set: mission_random_hits_store_skill 0</string>
				<string>reset: mission_random_hits_whoscooped</string>
				<string>reset: mission_random_hits_whoshot</string>
			</array>
		</dict>
	</array>

Oops!

[Commander McLane]

Okay, thanks! Back to hitting my marks!

Another issue: In the AI-folder, there is:

randomhitsmark1AI.plist
randomhitsmark2AI.plist
randomhitsmark3AI.plist

and there is

randomhitsmark1sAI.plist
randomhitsmark2aAI.plist
randomhitsmark3aAI.plist.

Somehow I am sceptical towards randomhitsmark1sAI.plist. Shouldn't that probably be randomhitsmark1aAI.plist, like the other two?

[LittleBear]

Nah the s is correct. Its a varient used by marks in very small ships (like boyracers). Its virtually impossible to follow a boyracer through his wormhole if he decides to jump. Because the racer is so small he leaves a tiny wormhole which invarabley collapses almost at once. So this varient of the AI doesn't jump. The a is used as a varient for those marks who have armed Worms aboard. They launch them through the aft-hatch. None of the Level 1 victims carry worms (ships too small), so they have the varients normal and s.

[Commander McLane]

Ah! Thanks for enlightening me.

[JensAyton]

Question: How can I debug when event-handlers are fired? I have the strong suspicion that those are somehow the culprit.

Well, I run Oolite under a debugger and set a breakpoint…

Failing that, though, the so-called printf method of debugging will at least tell you what order things are happening in.

Code: Select all

this.traceHandler = function (name)
{
    log("script.trace", "*** " + name + " called.");
}

this.shipLaunchedFromStation = function ()
{
    traceHandler("shipLaunchedFromStation");
    
    // Do stuff...
}

This will appear in the JS console, if active, as well as the log.

(Why use a separate function? Because it lets you disable all your trace messages by commenting out one line.)

[Commander McLane]

Question: How can I debug when event-handlers are fired? I have the strong suspicion that those are somehow the culprit.

Well, I run Oolite under a debugger and set a breakpoint…

Sorry, you lost me here. Please remember, I am not actually a programmer.

Anyway, in this case it turned out it wasn't the culprit, so I won't need to do it.

[Frame]

Question: How can I debug when event-handlers are fired? I have the strong suspicion that those are somehow the culprit.

Well, I run Oolite under a debugger and set a breakpoint…

Sorry, you lost me here. Please remember, I am not actually a programmer.

Anyway, in this case it turned out it wasn't the culprit, so I won't need to do it.

Setting a break point while running oolite under debug, means
he puts in a break point in the source code of oolite to stop/pause oolite at an exact moment in the code so he can view all the variables, function states... etc...

Very usefull when tracking down a bug... however, not an option in JS scripts...

[LittleBear]

Added a new feature for V1.3. The BB Post now shows where the Victim's System is on the Galactic Chart. As long as you select a Victim who is in the same Sector as you (North West, North East, South West South East or Central) then you'll never have to travel more than 4 or 5 jumps to reach your victim.

Eg: I'm docked at the Worlds End Bar at Rediquat in the South West Corner of Galaxy 1. So I flip through the board until I see an Advert in my local area. There's one, so I'll accept it. The Sector where the Mark is lurking is shown in brackets in the SUBJECT section :-



Job Accepted. Now to check the long range chart. There he is a mere 14 LYs away. The code to calculate this is only done for G1 ATM. Still have to do G2 to 8!

[pagroove]

Extremly cool for one of the best OXP's that exist in the Ooniverse!

[Commander McLane]

Stumbled across a small grammar problem:


In the upper left corner you also see my current problem with the insane number of entities.

By the way: It took me a way to figure it out, but the number increases by 0, 5, or 10 (randomly, it seems), each time I flip to another announcement. So the longer I browse the board on my hunt for a convenient kill, the more ghost ships are in the system. Finally it occured to me that the culprit might be in the showShipModel-method. I removed it, and the entity-increase was history. Seems something's broken.

[LittleBear]

Fixed the grammar problem. The crime is constructed in two alternate ways "who [did_nasty_thing] [to_a_victim_thing_or_item] [using_another_thing]" or "[crime_description] [doing_natsy thing2] [to_a_victim_thing_item] [using_another_thing]". The first construction needs "boiled" "chopped up" "stabbed" etc and the second needs "boiling", "chopping up" "stabbing". The "doing natsy things involving cooking" sentence builder had the wrong word-table for the adjective .

The spawning in the wrong role bug being down to showShipModel is stange. I don't seem to hit this on the PC Build though.