Let fragmentary particles explode after a short time

Screet · Post by **Screet** » Mon Mar 16, 2009 2:51 pm

Hi,

now I've got a log entry for one of those members from the immense particle clouds:

[Fuel Collector]: got role
[dumpState]: State for <ShipEntity 0xfec8438>{"Fragmentary Particle" ID: 745 position: (-8407.99, -857.834, 157174) scanClass: CLASS_MISSILE status: STATUS_IN_FLIGHT}:
  [dumpState.entity]: Universal ID: 745
  [dumpState.entity]: Scan class: CLASS_MISSILE
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (-8407.99, -857.834, 157174)
  [dumpState.entity]: Orientation: (0.338067 + 0.675387i + 0.627625j + 0.18881k)
  [dumpState.entity]: Distance travelled: 0
  [dumpState.entity]: Energy: 5 of 5
  [dumpState.entity]: Mass: 1393.67
  [dumpState.entity]: Owner: <ShipEntity 0xfec8438>{"Fragmentary Particle" ID: 745 position: (-8407.99, -857.834, 157174) scanClass: CLASS_MISSILE status: STATUS_IN_FLIGHT}
  [dumpState.entity]: Flags: isShip, isSunlit
  [dumpState.shipEntity]: Name: Fragmentary Particle
  [dumpState.shipEntity]: Display Name: Fragmentary Particle
  [dumpState.shipEntity]: Roles: <OORoleSet 0x1b1e8930>{fragparticle missile}
  [dumpState.shipEntity]: Primary role: fragparticle
  [dumpState.shipEntity]: Script: <OOJSScript 0x1b1eb4c8>{"oolite-default-ship-script" version 1.72.2}
  [dumpState.shipEntity]: Subentity count: 0
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_IDLE
  [dumpState.shipEntity]: Destination: (0, 0, 0)
  [dumpState.shipEntity]: Other destination: (0, 0, 0)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 0
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 0
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: fragparticleAI.plist
    [dumpState.ai]: Current state: GLOBAL
    [dumpState.ai]: Next think time: 6.28551e+010
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 0
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 100384
  [dumpState.shipEntity]: Spawn time: 58.852 (384.435 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 51
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: escortsAreSetUp, isFrangible, canFragment]

Screet

Post by **Kaks** » Mon Mar 16, 2009 2:57 pm

Hmmm, they're stuck in GLOBAL, with no speed - which shouldn't happen: they should be given an initial speed and sent to FRAGMENT almost immediately.

To get them unstuck, hopefully all that's needed now is to change global from

GLOBAL = {
ENTER = ("setSpeedFactorTo: 0.75", "setStateTo: FRAGMENT");
EXIT = ();
UPDATE = ();
}

to

GLOBAL = {
ENTER = ("setSpeedFactorTo: 0.75", "setStateTo: FRAGMENT");
EXIT = ();
UPDATE = ("setStateTo: FRAGMENT");
}

Screet · Post by **Screet** » Mon Mar 16, 2009 3:01 pm

Kaks wrote:

GLOBAL = {
ENTER = ("setSpeedFactorTo: 0.75", "setStateTo: FRAGMENT");
EXIT = ();
UPDATE = ("setStateTo: FRAGMENT");
}

This looks like a workaround for a bug where ENTER is not called, but should be. Maybe not only this fix should be used, but also searched for ways how this could happen at all, as other AIs may suffer from the same problem.

I didn't give the development environment a test yet, but if it allows breakpoints, maybe add one where update is called without enter being called first and then have a look at how the code got there. This may require a debug build with a debug-boolean which goes to true when entering and false when exiting global....if I understand this properly from watching the script.

Screet

Post by **Eric Walch** » Mon Mar 16, 2009 5:01 pm

Kaks wrote:
Hmmm, they're stuck in GLOBAL, with no speed - which shouldn't happen: they should be given an initial speed and sent to FRAGMENT almost immediately.

I have often seen ships stuck in GLOBAL in the past. Specially with scripts I was working on. It was always caused by a syntax error in the code with me. But in that case it should always happen and not occasionally.

Are you sure you indeed have that AI installed as current M&B does not use that name but did in the past.

Screet · Post by **Screet** » Wed Mar 25, 2009 6:11 pm

Hi,

I've got a problem with that workaround: it doesn't work. Most probably because the particle says it's AI is fragparticleAI.plist while I only could find and update rmb-fragparticleAI.plist.

Any ideas? Missing AI file and thus a misbehaviour?
Different filename and AI name and the patch idea just not doing it's job?
Something else?

Screet

Post by **Eric Walch** » Wed Mar 25, 2009 6:24 pm

Screet wrote:
I've got a problem with that workaround: it doesn't work. Most probably because the particle says it's AI is fragparticleAI.plist while I only could find and update rmb-fragparticleAI.plist.

Any ideas? Missing AI file and thus a misbehaviour?

Most likely. Those particles are not from M&B as that uses rmb-fragparticleAI.plist. So there is an other oxp adding those particles without supporting an AI file. It was just counting on that M&B supported that file.

It's probably the usual oxp that is to blame for. I still feel a larger urge to ignore any bug report unless it explicitly tells the bug also happens without RS installed.

Cmd. Cheyd · Post by **Cmd. Cheyd** » Wed Mar 25, 2009 6:34 pm

Actually Eric, FragParticleAI.plist is in ..\Missiles and Bombs v1.1.oxp\AIs.

Code: Select all

{

    	
	FRAGMENT = { 

	ENTER = (setDestinationToCurrentLocation, "setDesiredRangeTo: 250", performFlyToRangeFromDestination);
 "DESIRED_RANGE_ACHIEVED" = ("setStateTo: DETONATE"); 
	EXIT = (); 
 	UPDATE = (); 
	
	
		};

	DETONATE = {
	ENTER = ("setDesiredRangeTo: 500.0", dealEnergyDamageWithinDesiredRange, becomeExplosion); 
        EXIT = (); 
        UPDATE = (); 
    }; 

    	GLOBAL = {
        ENTER = ("setSpeedFactorTo: 0.75", "setStateTo: FRAGMENT");
        EXIT = (); 
	UPDATE = (); 
    };

 	
 
}

Screet · Post by **Screet** » Wed Mar 25, 2009 6:47 pm

Eric Walch wrote:
Most likely. Those particles are not from M&B as that uses rmb-fragparticleAI.plist. So there is an other oxp adding those particles without supporting an AI file. It was just counting on that M&B supported that file.

It's probably the usual oxp that is to blame for. I still feel a larger urge to ignore any bug report unless it explicitly tells the bug also happens without RS installed.

Shouldn't there be an error message if an AI file is missing? Should it also not be impossible to enter GLOBAL with a behaviour like BEHAVIOUR_IDLE in that case?

As to that oxp...I've removed missiles and bombs and use the version that comes with the OSE WIP...maybe L did add and rename the files, but I'm not too sure about that being the cause. Still I'd miss an error message in the log about a missing AI in that case.

A find in files turns out that OSE does use "rmb-fragparticleAI.plist" while trident down does use "fragparticleAI.plist" without providing it.

Just a guess: L did rename the M&B file from the name used in Trident Down, did change the calls in his OXP but never thought about some other OXP being dependent upon M&B and thus not finding the proper AI?

Still I miss an error message in that case...GRRR...would have made things much easier to find. Maybe it could be logged but isn't done with the standard log configuration of Oolite? If so, I suggest to add that to the standard log behaviour, as it can cause trouble.

EDIT: It's a bug from trident down, as missiles and bombs already comes with the name L uses, thus he and his OXP have NOTHING TO DO with that problem!

Results:
1) Trident Down requires an update to the name used by Missiles and Bombs and needs to add M&B to it's required OXPs (it's missing there!)
2) Oolite should log such missing AI file bugs

EDIT#2: I did have Trident Down 1.1 and missed the 1.2 update - guess it's gone with that newer version...*GRRR* we need writeable Wiki again! That states 1.1 is current...

EDIT#3: Got Trident Down 1.2 now - and the bug still is in there!
Screet

Cmd. Cheyd · Post by **Cmd. Cheyd** » Wed Mar 25, 2009 6:54 pm

It looks like M&B went through an AI renaming between versions 1.1 (where that AI did exist) and 2.1 (Current release on Ramiez's download site). I'm scanning through RS currently to see if I can find that AI being called by it, but am having to do it between getting real work done.

Wiki pages · Post by **Thargoid** » Wed Mar 25, 2009 7:21 pm

RS doesn't include Missiles and Bombs as one of it's OXPs. OSE (beta) does include M&B v2.0 (and will presumably update to include v2.1 with the next version). And this has the "RMB-" version of the AI, which is correct for the shipdata that it has. So RS doesn't have the frag particle AI in it, as it doesn't have the frag particle in it.

So as Screet says, RS and OSE have nothing to do with this issue. I can confirm that it's Trident Down that's the source of the rogue frag particles, not M&B due to the missing AI and/or broken hidden dependency, depending on how you look at it.

The frag particle there also has a secondary role of "missile" (not "missile(0)"), which could be where it is coming from, as it's an equally likely pick for an NPC ship weapon.

Ramirez · Post by **Ramirez** » Thu Mar 26, 2009 12:56 am

Ok, my bad. Trident Down duplicates some of M&B's frag particle stuff in order to produce flares and I forgot all about it - it's only used for one very specific instance. Serves me right for developing two OXPs at the same time! A simple fix is to remove the missile role from the frag particle entry in shipdata. What I'll do is revise the Trident Down shipdata to remove all mention of frag particles and just create flares as standalone entries.

Lestradae · Post by **Lestradae** » Thu Mar 26, 2009 7:30 am

Hi Eric,

Eric Walch wrote:
It's probably the usual oxp that is to blame for. I still feel a larger urge to ignore any bug report unless it explicitly tells the bug also happens without RS installed.

Screet wrote:
EDIT: It's a bug from trident down, as missiles and bombs already comes with the name L uses, thus he and his OXP have NOTHING TO DO with that problem!
...
EDIT#3: Got Trident Down 1.2 now - and the bug still is in there!

Thargoid wrote:
RS doesn't include Missiles and Bombs as one of it's OXPs. OSE (beta) does include M&B v2.0 (and will presumably update to include v2.1 with the next version). And this has the "RMB-" version of the AI, which is correct for the shipdata that it has. So RS doesn't have the frag particle AI in it, as it doesn't have the frag particle in it.

So as Screet says, RS and OSE have nothing to do with this issue. I can confirm that it's Trident Down that's the source of the rogue frag particles, not M&B due to the missing AI and/or broken hidden dependency, depending on how you look at it.

Or, Eric, perhaps it is the usual prejudiced reaction that is to blame for.

I'm not complaining, just suggesting that there might be more efficient ways of effective bug detection than automatically blaming RS/OSE, as has happened time and again, often with a result like the above.

Bugs in oxps and in the core game will happen, no matter how careful the creators are that produce them, and there's no reason to stomp on anyone because of that. Better to have a quick look and inform them if something goes awry.

But, no offense taken and none meant, just food for thought.

L

Ramirez · Post by **Ramirez** » Mon Mar 30, 2009 3:17 pm

I've notched up Trident Down to v1.3 which should fix the frag particle problem. However, let me know if you still see anything unusual going on.

Screet · Post by **Screet** » Mon Mar 30, 2009 4:15 pm

Ramirez wrote:
I've notched up Trident Down to v1.3 which should fix the frag particle problem. However, let me know if you still see anything unusual going on.

I fixed the previous version manually and since then, I've had no more encounters with frag particle clouds

Screet