Unscoopable Cargo

[LowLife]

First post - can I just say how fabulous Oolite is.

Minor niggle - I've been playing for some weeks with no problem. Today I installed the Cargo wrex oxp. Fisrt game after, I blew up a Pyhton and went to scoop up all of it's lovely cargo (about eight containers). I could scoop all except for one which just seemed to pass straight through me whenever I tried to scoop it. I couldn't lock onto with my ident system and it seemed impervious to laser fire.

I'm running version 1.65 under Windows XP. the container in question was a green pyramidal one (alien items?)

[aegidian]

This is probably part of the 'ghost ships' bug that's a bit of a nuisance at the moment.

There's some debugging info you could send me if it happens again - if you can access console.log or STDERR.TXT - press pause, press zero (this dumps out some information) and press c and then d - then unpause try to collide with the ghost again - pause once more, press zero - and send me the last few pages of messages in console.log or STDERR.TXT

Or not. Nothing's helped with this bug yet!

[LowLife]

Okay, will do if it happens again.

[Eric Walch]

Possible solution for uncollidable cargo and splinters. This is a long existing problem and according the code it is tried to correct on several places in the code. Cargo and splinters have a dumbAI.plist when put in space. When you do an entity dump you always see that these things have an nullAI.plist. Looking in the code it can only be set this way on one place. And that is while being scooped as it has to be uncollidable then.
:

Code: Select all

- (void) getTractoredBy:(ShipEntity *)other
{
	desired_speed = 0.0;
	[self setAITo:@"nullAI.plist"];	// prevent AI from changing status or behaviour
	behaviour = BEHAVIOUR_TRACTORED;
	status = STATUS_BEING_SCOOPED;
	[self addTarget: other];
	[self setOwner: other];
}

I looked intensive at the scooping process of ships. In most cases the cargo is in one try scooped, but somethimes it takes time to tractor it in. You see the cargo flying around the ship for several seconds. I once saw that the cargo flew away at last with some speed. This cargo is handled properly and i can confirm that it can be scooped. Then I waited again for a ship having troubles tractoring the cargo. This time I shot the ship and the remaining cargo was uncollidable.

There is a check for (status == STATUS_BEING_SCOOPED). in the code:

--------

Code: Select all

	// double check scooped behaviour
	//
	if (status == STATUS_BEING_SCOOPED)
	{
		if (behaviour != BEHAVIOUR_TRACTORED)
		{
			// escaped tractor beam
			status = STATUS_IN_FLIGHT;	// should correct 'uncollidable objects' bug
			behaviour = BEHAVIOUR_IDLE;
			frustration = 0.0;
		}
	}

But this check does nothing when (behaviour = BEHAVIOUR_TRACTORED). I think it just needs a timer. When (status == STATUS_BEING_SCOOPED) and timer is not set, it is set. And when after 30 seconds the timer is still running, just assume it may become collidable again. There are problably better solutions as checking if the tractoring ship still exists.

(I've put it on berlios also as a comment to an new topic with this name.)

[TGHC]

At some stage Giles did do a major rewrite for tractoring the cargo, I do recall he had some issues with it working properly, it was also the time when he introduced the scooping sound effect.
There are times when scooping, as you say, that the cargo seems to spiral around for ages before it gets fully scooped, hitting the accelerator fixes that.

[Dr. Nil]

@Eric: Nice if you could kill the ghost cargo bug. I've come across those ghost cannisters far more often than the ghost ships. Perhaps it could also lead you to the cause of ghost ships?

[Eric Walch]

Nice if you could kill the ghost cargo bug. I've come across those ghost cannisters far more often than the ghost ships. Perhaps it could also lead you to the cause of ghost ships?

I only pointed in a direction. And that direction was not new as the comment in the code showed. But being able to create a situation that leads to the bug helps finding the course.

I never have seen ghost ships till now. So they must be very rare. (or clean as I hardly never shoot clean ships) Are they always of the same type, role or OXP generated?

[TGHC]

I don't think they are OXP related, IIRC it was a bug Giles had on his todo list just before his retirement.

[Commander McLane]

I have encountered ghost ships two or three times, but I agree that they are considerably more rare than ghost cargo.

I think one way to create one is killing a ship. Under (obviously very rare, and on top of that unknown to me) circumstances it seems to happen that, although the ship explodes, after the explosion it is still there, now as a ghost. Or it could also be that it just doesn't explode, but transforms into a ghost instead. I remember reports here on the board pointing in the direction of at least one of these two possibilities. I remember specifically one report whose author claimed that he killed a ship, which went alive again and even fired at him again, but was a ghost, so he couldn't kill it again. (So it was the special case of a zombie!) This could point to the possibility that the (itself rare) state of a ship being disabled, but not killed, could be involved. So perhaps a ghost is produced when something special happens the very moment a ship is disabled, or just one *tic* before it would then explode.

As some very special circumstances seem to be involved in their genesis, I guess it could take ages (and a lot of kills) to create one.

This is a lot of guessing, but, I hope, of the helpful kind.

[Eric Walch]

At the moment I am writing a script where I place two clusters of 8 asteroids each in deep space on the back side of a planet. I also place several miners on a course that goes through these clusters. When they find them, they start mining. The asteroids have a high gold/platinum content, so the player must hurry to also scoop something of it. As I currently have no mining laser mounted, I wait till a miner has generated the splinters and then try to scoop as many I can before he has collected them all.

This seemed to be the ideal setting for creating the unscoopeble bug. In the normal mining script they shoot a rock and then do a scanForRandomLoot. This will find any splinters or cargo flying around. They do it until nothing is found and than they all start to shoot the random next rock.

This means the last splinter is always found by all ships nearby and all will go for it. If the first one scoops it directly things are OK, but when he has trouble scooping it in, the others keep approaching the splinter. This often ends in a crash where both ships are killed. I noticed several occasions where two yellow dots disappeared from the radar and changed into a bunch of white radar dots. Yesterday I even found a bunch of 7 unscoopeble splinters on such a point. six of them were clustered in two bunches of three splinters each. Clearly a sign of splinters being in the scooping process.

In normal Oolite live there is seldom more than one miner active in a field, but this is the most likely scenario for unscoopeble cargo. After a bunch of pirates killed their victim, they all start scooping the cargo and they all will go for the last barrel. So this must occasionally lead to crashes between colliding pirates. Specially when one has problems getting the cargo in.

Besides making the barrel scoopeble again when the scooper crashes, I think it also helps avoiding crashes when a "TARGET_LOST" is send to others that are targeting a barrel when one of them starts the process of scooping.

[TGHC]

That does seem to fit because Giles was working on collision detection as well.