Page 4 of 5

Posted: Sun Oct 07, 2007 3:14 pm
by Arexack_Heretic
Another problem remains the explosiveAI.plist.

As it is, it triggers QC directly following ECM, without pausing or communicating.

Q: Is AImethod "pauseAI: <s>" broken?
The number entered is in seconds right? not milliseconds or 0.1seconds?
When I put the pause,comms,state lines into the PAUSE, it sometimes takes way too long to cycle.
It does work...except for the delays and lack of 'commsMessage:'.
Gonna test under 1.68.
Similar effects. except there is debris in explosions.

I have since altered the AI to

-added a chance of prevent cascade at the last moment.
-added more chances to interrupt the cascade by ECM-ing. (This may be a mistake as it masks it if the AI hangs)

-added scan for the player, setTargetToFoundTarget and use sendTargetCommsMessage. still no comms.

What I don't understand is why the AI advances through all states in a moment when lines like:

Code: Select all

"commsMessage: -beep- ", "pauseAI: 1.0", "setStateTo: TIMER5"
Is script still executed from left to right?

current AI:

Code: Select all

{
	GLOBAL = {
		ENTER = ("setDesiredRangeTo: 100000.0", performTumble);
		EXIT = ();
		UPDATE = ("setStateTo: GET_PLAYER");
	};
	"PLAYER_FOUND" = {
		ENTER = ();
		COLLISION = ("setStateTo: EXPLODE");
		ATTACKED = ("setStateTo: EXPLODE");
		LOST_TARGET = ("setStateTo: GET_PLAYER");
		ECM = ("sendTargetCommsMessage: WARNING: ECM disrupts Quirium containment!", "pauseAI: 7.5", "setStateTo: CRITICAL");
		EXIT = ();
		UPDATE = ("pauseAI: 5", "sendTargetCommsMessage: -Beep!- ");
	};
	"GET_PLAYER" = {
		ENTER = ("commsMessage: -Beep!- ", "scanNearestForShipWithRole: player");
		TARGET_FOUND = (setTargetToFoundTarget, "setStateTo: PLAYER_FOUND");
		ECM = ("pauseAI: 10.0", "setStateTo: DEFUSE_CHANCE");
		COLLISION = ("setStateTo: EXPLODE");
		ATTACKED = ("setStateTo: EXPLODE");
		EXIT = ();
		UPDATE = ("pauseAI: 5", "setStateTo: GET_PLAYER");
	};	
	EXPLODE = {
		ENTER = ("setDesiredRangeTo: 150.0", dealEnergyDamageWithinDesiredRange, becomeExplosion);
		EXIT = ();
		UPDATE = ();
	};
	CRITICAL = {
		ENTER = (performTumble);
		COLLISION = ("setStateTo: EXPLODE");
		ATTACKED = ("setStateTo: EXPLODE");
		ECM = ("sendTargetCommsMessage: WARNING: Quirium Cascade imminent!", "pauseAI: 5.0", "setStateTo: TIMER5");
		EXIT = ();
		UPDATE = ("pauseAI: 5", "sendTargetCommsMessage: -Beep!- ");
	};
	TIMER5 = {
		ENTER = ("sendTargetCommsMessage: -5-");
		EXIT = ();
		ECM = ("pauseAI: 1.0");
		ATTACKED = ("setStateTo: EXPLODE");
		UPDATE = ("pauseAI: 1.0", "setStateTo: TIMER4");
	};
	TIMER4 = {
		ENTER = ("sendTargetCommsMessage: -4-");
		EXIT = ();
		ECM = ("sendTargetCommsMessage: Quirium Cascade Effect Interrupted", "setStateTo: EXPLODE");
		ATTACKED = ("setStateTo: EXPLODE");
		UPDATE = ("pauseAI: 1.0", "setStateTo: TIMER3");
	}; 
	TIMER3 = {
		ENTER = ("sendTargetCommsMessage: -3-");
		EXIT = ();
		ECM = ("sendTargetCommsMessage: Quirium Cascade Effect Interrupted", "setStateTo: EXPLODE");
		ATTACKED = ("setStateTo: EXPLODE");
		UPDATE = ("pauseAI: 1.0", "setStateTo: TIMER2");
	};
	TIMER2 = {
		ENTER = ("sendTargetCommsMessage: -2-");
		EXIT = ();
		ECM = ("sendTargetCommsMessage: Quirium Cascade Effect Interrupted", "setStateTo: EXPLODE");
		ATTACKED = ("setStateTo: EXPLODE");
		UPDATE = ("pauseAI: 1.0", "setStateTo: TIMER1");
	};
	TIMER1 = {
		ENTER = ("sendTargetCommsMessage: [bomb-last-words]");
		EXIT = ();
		ECM = ("sendTargetCommsMessage: Quirium Cascade Effect Interrupted", "setStateTo: EXPLODE");
		ATTACKED = ("setStateTo: EXPLODE");
		UPDATE = ("pauseAI: 1.0", "setStateTo: DEFUSE_CHANCE");
	};
	"DEFUSE_CHANCE" = {
	 	ENTER = ("rollD: 3");
	 	"ROLL_1" = ("setStateTo: DETONATE");
	 	"ROLL_2" = ("sendTargetCommsMessage: Quirium Cascade Effect Interrupted", "setStateTo: EXPLODE");
	 	"ROLL_3" = ("sendTargetCommsMessage: Quirium Stabilized", "setStateTo: TUMBLE");
	 	EXIT = ();
		UPDATE = ("rollD: 3");
	};
	DETONATE = {
		ENTER = ("pauseAI:1.0");
		EXIT = ();
		UPDATE = ("setDesiredRangeTo: 150.0", dealEnergyDamageWithinDesiredRange, becomeEnergyBlast);
	};
}

Posted: Sun Oct 07, 2007 7:55 pm
by Eric Walch
What I don't understand is why the AI advances through all states in a moment when lines like:

Code: Select all

"commsMessage: -beep- ", "pauseAI: 1.0", "setStateTo: TIMER5"
I had problem myself with this behaviour. The pause only means it waits that long before the next UPDATE but immediately executes all commands on that line. If it is jumpung to an other state than this is done without a timedelay. In this case you must put the pause in the ENTER part.

Posted: Sun Oct 07, 2007 8:52 pm
by Arexack_Heretic
hmm...
but if you look at the previous incarnation of this AI,
I had this line on the ENTER line,
and the behaviour was after ECM:

Immediately skip through all STATES to the final DETONATE state, without any commsMessage or pause.
at least putting stuff in the update part delays events a bit

It's that the police-warnings (via markTargetForFines (whatever)) and thargoid-curses (via death_action-commsmessage) are working (intermittedly) or I would have lodged a bug-report about this.

As it concerns MY work however, I will remain and await some lively Joe to point out my (from that point on) obvious syntax-error.

edit: ah. the wisdom of your words only reaches me now. pauseAI only is executed when recieving the 'update' AIstate-message. sounds like a bug to me! I always assumed the pause to be implemented immediately when scripted, that means inbetween methods in any commandline, not just UPDATE.

This sort of unexpected behaviour should be documented.
(and fictitious assumptions (by yourstruly amongst others) should be rectrified by those in-the-know)

Posted: Sun Oct 07, 2007 11:02 pm
by JensAyton
Arexack_Heretic wrote:
edit: ah. the wisdom of your words only reaches me now. pauseAI only is executed when recieving the 'update' AIstate-message. sounds like a bug to me!
It’s a fundamental wossname of the way AIs work. Each state is executed at one go, conceptually instantaneously. The concept of pausing an AI partway through executing a state just doesn’t fit into the model, or the implementation.

Posted: Wed Oct 17, 2007 1:56 pm
by Arexack_Heretic
PAUSE10S state has a typo,

there is a ' ; ' missing at the closing tag.

This can cause CTD I think.
(just had one when scooping a glowing alloy with a full load of trumbles, but the log only mentioned this error)

//
Just fixed acouple of typos in the special-foods descritions.
Added more descriptions, nested some for addional clarity and variation.
going to test out [d3,d6,d10_number] descriptors, for filling precious cargopods.
//

Posted: Tue May 13, 2008 4:45 pm
by Eric Walch
There is a bug in Cargo_Wrecks_teaser with the firearms pod.

There is one pod in it with the name "CARGO" on is and black/Yellow stripes at the sides that keeps hitting in my face. It very often explodes when trying to scoop.

I looked in the shipdata and saw two entries using that barrel. One is OK the other (barrel_ah) has a wrong definition. AH tries to offer firearms but uses:

Code: Select all

"cargo_type" = "CARGO_FIREARMS"; 
This is a wrong definition, that only works with ALLOY, ALIEN, MINERALS and a few other names. I updated the WIKI with the working names, for all others you need: CARGO_CARRIED. And in a second entry you have to specify the cargo.

Code: Select all

"cargo_carried" = "firearms"; 
"cargo_type" = "CARGO_CARRIED"; 
or with a quantity

Code: Select all

"cargo_carried" = "3 firearms"; 
"cargo_type" = "CARGO_CARRIED"; 
This was mend for more than one gold in a pod but will indeed work with 1ton goods and give you 3 ton firearms at once.

Also the "pirapod_gems" has no role cargopod and will never get selected. could be intentional because of problems in earlier non-mac oolite versions. In the two pirate pods he does uses the cargo_carried key
----

I must also say that spawning these pods with a script now also works in 1.71. Before it only worked with when the pods were selected by oolite itself for an exploding ship. This made testing this bug also much easier.

Posted: Fri May 16, 2008 12:06 am
by Arexack_Heretic
fixed

Posted: Fri May 16, 2008 8:21 am
by Eric Walch
Arexack_Heretic wrote:
fixed
Thanks. It was an unavoidable bug as the WIKI was unclear how to do it (I fixed that part now). And because adding cargo with a script formerly didn't work it was also very difficult to test.

Posted: Sat May 17, 2008 3:56 am
by Damos
I've tried to download the v.1.3.2 via the wiki summary page of all the oxp's. when I open the zip I get a .rar file which I'm not sure what to do with.

Help/thoughts..


Damos

xp 1.71

Posted: Sat May 17, 2008 7:43 am
by Cmdr James
Download winrar http://www.winrar.com/

Posted: Sat May 17, 2008 8:31 am
by ovvldc
If you are on a Mac, StuffIt Expander can handle it for you (even though it has problems with some other archives).

I don't really get why Arexack Heretic first RARred it and then ZIPped it, but it works..

Best wishes,
Oscar

Posted: Sat May 17, 2008 10:04 am
by Arexack_Heretic
lost winzip, so used rar, wiki doesn't want rar, so I used the archiver in windowsXP.

sorry 'bout that, should've repacked it from source.

Posted: Sat May 17, 2008 10:10 am
by Cmdr James
If you want a free windows zip too, you can use http://www.info-zip.org/ :)

Posted: Sat May 17, 2008 10:18 am
by Arexack_Heretic
I don't really mis it.
rar works fine, usually, and the inbuilt winXP zip-clone does an adequate impression. :)

Posted: Sat May 17, 2008 11:15 pm
by Damos
Any chance of being able to download the standard .zip and avoiding having to get another program just to unpack this one .oxp because of the .rar?

Having some .oxp's as just .zip while others are .rar is going to cause some confusion amongst the non tech types?

Damos