Scripters cove

Discussion and information relevant to creating special missions, new ships, skins etc.

Moderators: winston, another_commander

Post Reply
User avatar
Frame
---- E L I T E ----
---- E L I T E ----
Posts: 1474
Joined: Fri Mar 30, 2007 8:32 am
Location: Witchspace

Post by Frame » Fri Jul 27, 2007 11:01 pm

Try posting your AI for detection of the buoy here... and i´ll see if i can find anything wrong...

My rock hermit locator which includes a new rock hermit AI, checks and finds asteroids/custom objects... And Destroyes them. Similar to what you want... a ship to switch/do something...

Cheers Frame...
Bounty Scanner
Number 935

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Sat Jul 28, 2007 10:56 am

To show the same ship really reappears after a hyperspaceExit I wrote a little demo to show it. The ship will appear just out of scanner range. Fly towards the planet and it will probably the first ship you find. It hails you and than disappears. Fly back to the witchpoint beacon and it will be there. And it will staying disappearing and re-appearing as long as you are in his scannerrange. It happens with Oolite 1.65. Maybe the problem is solved in newer versions.

Create a textfile with name wormholeTestAI.plist with the following content


{
"WAIT_FOR_PLAYER" = {
ENTER = ();
EXIT = ();
"TARGET_FOUND" = ("commsMessage: Hey, are you in trouble?.", "pauseAI: 15.0","setStateTo: EXIT_SYSTEM");
UPDATE = ("scanForNearestShipWithRole: player", "pauseAI: 15.0");
};
"EXIT_SYSTEM" = {
ENTER = ();
EXIT = ();
UPDATE = (performHyperSpaceExit);
"WITCHSPACE OKAY" = (wormholeEscorts);
};
GLOBAL = {ENTER = ("setStateTo: WAIT_FOR_PLAYER"); EXIT = (); UPDATE = ();
};
}


----------

Add the following ship to your shipdata.plist

<dict>
<key>anaconda-wormhole</key>
<dict>
<key>ai_type</key>
<string>wormholeTestAI.plist</string>
<key>like_ship</key>
<string>anaconda</string>
<key>roles</key>
<string>wormholeTest</string>
</dict>
</dict>

-------

then add to you script:

<dict>
<key>conditions</key>
<array>
<string>status_string equal STATUS_EXITING_WITCHSPACE</string>
</array>
<key>do</key>
<array>
<string>addSystemShips: wormholeTest 1 0.05</string>
</array>
</dict>

------

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton » Sat Jul 28, 2007 12:24 pm

It turns out that the behaviour you’re seeing is deliberate; it’s to replenish the stock of traders in the system when one leaves. I’ll add a performHyperSpaceExitWithoutReplacing method for future use.

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Sat Jul 28, 2007 12:48 pm

Try posting your AI for detection of the buoy here... and i´ll see if i can find anything wrong...

My rock hermit locator which includes a new rock hermit AI, checks and finds asteroids/custom objects... And Destroyes them. Similar to what you want... a ship to switch/do something...
I downloaded it, exelent programming. I always like things that look impossible to do, but can be done with a lot of creative thinking. Only the death_actions can do with one condition and a else instead of two conditions.

I tried for another time to tackle the problem. I now start the IA script with the next lines:

"WAIT_FOR_BUOY" = {
ENTER = ();
EXIT = ();
"TARGET_FOUND" = ("commsMessage: Buoy witchpoint found.", "pauseAI: 10.0", "switchAITo: enteringTraderAI.plist");
"NOTHING_FOUND" = ("pauseAI: 15.0", "setStateTo: WAIT_FOR_PLAYER");
UPDATE = ("scanForNearestShipWithRole: buoy-witchpoint", "pauseAI: 15.0");
};

This did the trick. I thought I tried it before, but then I probably did the check in the enter-part and not in the update-part. Probably a mather of timing he didn't find the buoy before.
If the ship is not near the buoy it acts as intended and uses the remainder of the AI script. If it is recycled near the witchpoint it switches to a trader and acts further as a normal system ship.
Last edited by Eric Walch on Sat Jul 28, 2007 12:56 pm, edited 3 times in total.

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Sat Jul 28, 2007 12:53 pm

It turns out that the behaviour you’re seeing is deliberate; it’s to replenish the stock of traders in the system when one leaves. I’ll add a performHyperSpaceExitWithoutReplacing method for future use.
Or just replace ships with normal system roles like trader, hunter and so on. that are created by the system itself to fill the solarsystem. And don't recycle ships with custom defined roles.

Eric

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton » Sat Jul 28, 2007 1:07 pm

Unfortunately, a ship can have both a standard role and a custom role.

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Sun Aug 12, 2007 10:58 am

If I install the OXP "cargo_wrecks_teaser" version 1.2, I frequently get crashes of Oolite 1.65. And this is such a nice OXP that brings live into Oolite.

By now I now that this often happens if there is a missing link in a script. So I followed all links insite this OXP and found the cause:

In shipdata.plist the OXP defines a foodpod_type2. As model for this foodpod he refers to: "nubarrel.dat". But this file doen not exist in the OXP nor inside Oolite. And on placing ships or other items with wrong references Oolite crashes.

If anyone have the same problem, open the shipdate.plis with a texteditor, search for "nubarrel" and replace it with just "barrel". The problems should be over.
The author never discovered this as he probably had the nubarrel.dat present in an other OXP.

-----

The same crashes happen if you add an OXP in Oolite that says it also needs an other OXP. If you don't install that other OXP you also might get crashes if the tries to add items or ships from the missing OXP. But in this case it's the users fault. But it would be nice if Oolite would give a nice missing file error instead of just crashing. But maybe this is already better in post 1.65 versions

User avatar
TGHC
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 2157
Joined: Mon Jan 31, 2005 4:16 pm
Location: Berkshire, UK

Post by TGHC » Sun Aug 12, 2007 12:48 pm

in which case it would be best to have all OXP's installed then.
The Grey Haired Commander has spoken!
OK so I'm a PC user - "you know whats scary? Out of billions of sperm I was the fastest"

User avatar
Arexack_Heretic
Dangerous Subversive Element
Dangerous Subversive Element
Posts: 1878
Joined: Tue Jun 07, 2005 7:32 pm
Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
Contact:

Post by Arexack_Heretic » Sun Aug 12, 2007 9:18 pm

My appologies,

I used Giles' nubarrel (x-ships_oxp) for some of those experimental talking barrels.
I should have mentioned the OXP dependency.

To my defence, I assumed the engine just skipped over references to models that are faulty or missing.
This is an increasingly flimsy excuse, as I often have had crashes with corrupt models. ;)
Riding the Rocket!

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Wed Sep 05, 2007 12:53 pm

In oolite script you can use variables. You must put them between brackets [ ] to distinguish them from a string. This works in the "do" and "else" part of an expression.

In the "conditions" part of an expression this does not work.

So the next routine:

"set: mission_temp1 5", "set: mission_temp2 5",
{
conditions = ("mission_temp1 equal [mission_temp2]");
do = ( "commsMessage: variable in conditionpart worked");
else = ( "commsMessage: variable in conditionpart did not work" );
}

gives as answer: "variable in conditionpart did not work".

OK this I knew as I desperately wanted this to work for my own OXP. But I still kept seeing other OXP were they did use it in the condition part. I always thought this was a bug in version 1.65 and they only wrote and thested it for the newer versions. But I came in doubt and today I wrote above script and ran it also with oolite version 1.69.1.2 It had the same result that it didn't work. You still can't compare variables in a condition.

So all the OXP's that are around and using this have a condition build in that never will become true. It was never an important routine of those scripts but nevertheless is it a bad thing that the authors never noticed this.

I found a workaround by subtracting both variables from eachother and compare the result against zero. Or more precise: If they are equal the result becomes "0.000000" and not "0".
And as I was not sure if there would always be 6 decimals in future oolite versions, I choose to use an increment on the variable so the result became the integer "1".

I think it would be easy to implement the conditions part right in Oolite, but on the other hand you would have a script that only will work on the latest Oolite version. And such a script is better directly written in JavaScript if it only works on the newest oolite versions.

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton » Wed Sep 05, 2007 1:41 pm

Eric Walch wrote:I think it would be easy to implement the conditions part right in Oolite, but on the other hand you would have a script that only will work on the latest Oolite version. And such a script is better directly written in JavaScript if it only works on the newest oolite versions.
Yes, exactly.

User avatar
Arexack_Heretic
Dangerous Subversive Element
Dangerous Subversive Element
Posts: 1878
Joined: Tue Jun 07, 2005 7:32 pm
Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
Contact:

Post by Arexack_Heretic » Fri Sep 28, 2007 10:50 am

Would it be possible to OXP the trumbles into different types of pest?

For example faster breeding, but smaller versions.
Or just using different graphix for variation.
And can movement be scripted or restricted to certain areas of the screen?


I'd still love to have a pet creature.
Just sitting in the corner of the screen, sleeping, warbling at the commander, preening itself and sitting on the scanner console, when it's food_eq runs out.

Might lead to another fun 'who can create the best/funniest/cutest/slimiest/tastiest/most-precious sci-fi alien pet' competition.

Some imaginative scripting may be fun too:
"You have a cute juvenile Jabberwocky"
"Your Jabberwocky is hungry."
"your Jabberwocky has taken to living in the cargohold"
"you Jabberwocky now weighs 2 tonnnes"
"A 3tonne Jabberwocky chewing on your ship is not a good thing. FEED IT!" (creature has a chance of damaging EQ if not fed properly)
"You can't sell mature Jabberwocky, it's illegal."
"If you're really serious about getting rid of it, you could return it to it's native planet."
"Jabberwocky? According to GalCoop colony administration, there are severa planets in this galaxy with Jabberwocky populations."
etc.
Riding the Rocket!

User avatar
Arexack_Heretic
Dangerous Subversive Element
Dangerous Subversive Element
Posts: 1878
Joined: Tue Jun 07, 2005 7:32 pm
Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
Contact:

Post by Arexack_Heretic » Tue Oct 02, 2007 10:58 pm

Meh I am starting to repeat myself with those pe(s)ts. :oops:


So...more 'cove theorizing, as a mind game:

How would you go aboot constructing a big-thing in oolite?
(scripting, not models)

For instance a minature Dyson-sphere, battleship or station.
This should take a long time to build, so damage done to it should be visible upon returning to the system.

-I'd set up various stages of progress.
-Get the player to transport bottleneck supplies and items from all over the galaxy.
-game-timer + playermission could determine whether it's possible to increment stage.
-Each stage could initiate several parts of the object, each setting a mission_parameter to BUILT.
-script checks these parameters for model to be spawned at a defined location+heading.
-destruction of a part sets the parameter to CAPUT and prevents spawning it.
-building and replacing parts... timer?
-destruction of enough parts decrements the construction-STAGE.
-Once a stage is completed, the parts may be replaced by a single model constructed of subunits. (ie in during stage2, stage1 parts are combined into a single model.) (anchor- mainmodel needs to be indestructable)

Alternatively, the player could be tasked to sabotage the project.
Riding the Rocket!

User avatar
Arexack_Heretic
Dangerous Subversive Element
Dangerous Subversive Element
Posts: 1878
Joined: Tue Jun 07, 2005 7:32 pm
Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
Contact:

Post by Arexack_Heretic » Fri Oct 05, 2007 5:00 pm

If noone is interested in brainstorming pipedreamz,

does one of us know how to check for player-equipment-missiles and then compare this to playership-max-missiles?

I know there is a key <missiles> in the commander-savefile,
but is this accesable through some code-chickanery without going J-script?

My goal: to have the free-missile pod in wrex behave like the constrictor pod.
Script_action: check whether player has a free pylon.
Condition true: award free missile
Else: award a tonne of [%R]ian BattleWeapons (fireArms)
Riding the Rocket!

User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch » Fri Oct 05, 2007 8:30 pm

Arexack_Heretic wrote:I know there is a key <missiles> in the commander-savefile,
but is this accesable through some code-chickanery without going J-script?
Not possible. You can't even remove missiles with a removeEquipment.

With the awardEquipment there is a special check for mines an missiles. They must be treated separately as other equipment. This check does not exist in removeEquipment so that command will think there were no missiles.

Post Reply