Page 3 of 5

Posted: Mon Dec 24, 2007 4:11 pm
by Eric Walch
Thinking about it, I will upload an improved version myself.

I found the author to be Murgh. There were also some problems with the AI. It used the old Behemoth AI, but that one I improved some time ago. Since then the Levetian flies well on that AI well on my computer.

There was just one bug left in the AI. The Levetian carrier has a maximum flight speed of 320. Some of the defence ships only have half of that value. So when the carrier launched ships at full speed the Levetian regularly crashed into his own defenders.
I solved this hopefully by giving the defenders a 5 seconds speed-burst after launch. That burst seemed to solve the problem in a first test. But I had to change ship characteristics for this. 1 defender had always fuel injection, but the two others had only a 75% chance of it. I had to raise all to 100% chance to let all ships clear well with a speed burst at high launch-speed.

If anybody has found an other bug I can change it also. Otherwise I'll upload it somewhere soon. Just want to test it a few days more.

Posted: Mon Dec 24, 2007 7:44 pm
by TGHC
Star Gazer wrote:
Might it be a good idea for some of these really useful posts that give huge insights into how to write oxps become part of the wiki...?
Yes, and it could be called Eric's corner! :wink:

Posted: Tue Dec 25, 2007 12:07 pm
by Ark
Eric Walch wrote:
Thinking about it, I will upload an improved version myself.
Well done commander :D :D
It is nice that someone out there will look after those abandoned oxps by
fixing their bugs. Military fiasco is one of my favorite mission OPXs

Posted: Wed Dec 26, 2007 3:52 pm
by Eric Walch
It is nice that someone out there will look after those abandoned oxps by fixing their bugs. Military fiasco is one of my favorite mission OPXs
Once started I noticed more bugs: The two escorts are selected by role. This never has worked in Oolite because escorts only work with role = "escort". But I think there is a fix around. (At least for 1.65 till 1.69 I can change the role to escort)). For 1.70 I need JS to call the "setPrimaryRole" function. I just was not able to do this. Maybe somebody else does know. I made a ship script to change the role. :

Code: Select all

this.name           = "leviathanEscort";
this.author         = "Eric Walch";
this.copyright      = "Dec2007";
this.description    = "bugFix";
this.version        = "1.00";

this.shipSpawned = function()
{
  this.ship.legacy_setPrimaryRole("escort");
  delete this.didSpawn;
}
But the keyline is saying "unknown command" in the log.


Further I noticed the max speed of the escorts is lower than the leviathan cruise speed. (just as the defenders) So, even when it would have worked, the mother would have always outrun the escorts.

Posted: Wed Dec 26, 2007 4:19 pm
by JensAyton
In JavaScript, primaryRole is read/write. So what you need is this.ship.primaryRole = "escort".

The legacy_ prefix doesn’t do any magic, it’s just used for some functions that I intend to replace with more flexible alternatives. There is, however, a similar magic command: this.ship.call("setPrimaryRole:", "escort"). I recommend avoiding it if possible, though.

Posted: Wed Dec 26, 2007 6:34 pm
by Eric Walch
Ahruman wrote:
So what you need is this.ship.primaryRole = "escort".
Thanks. It was my first js script. I couldn't find a example of something similar. But it works now as intended. In script_actions I use "setRoles: escort". Starting from 1.70 this does not work anymore. But I added a script key that launches the js script under 1.70. This way it gives the ship both in 1.65/1.69 and 1.70 the role escort. This way I got escorts created with "escort-role" working again. And under neither system an error is generated as none of the versions gets the, for them, unknown code to see. (setRoles vs. setPrimaryRole)

No clean programming and only necessary to flatten out a bug in Oolite. But the result counts in this case.

Posted: Wed Dec 26, 2007 7:27 pm
by Ark
Eric Walch wrote:
Ahruman wrote:
So what you need is this.ship.primaryRole = "escort".
Thanks. It was my first js script. I couldn't find a example of something similar. But it works now as intended. In script_actions I use "setRoles: escort". Starting from 1.70 this does not work anymore. But I added a script key that launches the js script under 1.70. This way it gives the ship both in 1.65/1.69 and 1.70 the role escort. This way I got escorts created with "escort-role" working again. And under neither system an error is generated as none of the versions gets the, for them, unknown code to see. (setRoles vs. setPrimaryRole)

No clean programming and only necessary to flatten out a bug in Oolite. But the result counts in this case.
:D :D

Posted: Thu Dec 27, 2007 1:23 pm
by TGHC
Great work guys and I fully support the tidying up and debugging of "abandoned" OXp's.

Posted: Thu Dec 27, 2007 10:59 pm
by Eric Walch
TGHC wrote:
Great work guys and I fully support the tidying up and debugging of "abandoned" OXp's.
OK, the "improved" Military Fiasco seems to be working on my machine. I will just check if I ruined something before I re-upload.

While busy I also looked at my other favourite: Thagoid Wars 4.1

As this is also an always active oxp, I thought it wise to also change this code a bit to improve execution speed a little by rearranging the code. I'm ready with it and now the code runs selectively with as little as much during flight situations.

By doing this, I stumbled over two bugs.
- One I already removed a half year ago on my computer: On launching after accepting the "station attack" mission, the legal status was cleared. But that was never Commander Wombat intention.

- The other was a bug in how the "station attack" mission was offered. It had the same bug as the old Trumble mission: When you launched from the station during the offer, the mission was cancelled and never offered again. (I already wondered why I never got this mission lately, but looking in my save file I saw that I was also affected by this bug). It could be triggered again by an other OXP's mission with a YES/NO option and thereby killing this oxp's mission. (just like the old trumble mission).
I added code to restore old save files that were affected by this bug. Yes, it works: I now got the "station attack" mission again.

I'll also let this oxp run for some time on my computer to see if I didn't add a new bug. After that I re-upload it at the WIKI.

Posted: Sat Dec 29, 2007 9:33 am
by Ark
We shall rename the post from "military fiasco" to "abandoned OXP adoption".

Suggestion : The PNGs for the medals awarded from Thargoid Wars are awful (even the creator of this oxp didn’t like them). Maybe we can find or create better ones and replace them in the updated release.

Posted: Sat Dec 29, 2007 1:29 pm
by Eric Walch
OK, I believe Military Fiasco working better now.

Version 2.1 Additions by Eric Walch:

1) The version of Murgh was not compatible with other mission OXP's running simultaniously. Now added code for compatibility with other mission offering OXP's. So called MOP code (Mission Offering Protection). (Was already present in the latest version uploaded by Little Bear)

2) Changed the program structure slightly so that is uses less processor time. The game itself is in no way altered. Specially after finishing the game it still kept checking all possible game conditions and thereby consuming useless time. Will now use a minimum of time when finished but should stay in place when one still wants to see all the nice new ships to randomly appear.

3) Removed a bug that made it impossible to restart the game after a delay.

4) Gave leviathan escorts a separate entry in shipdata.plist with its own AI file and added code to make that they always get role "escort". (needed to fix a bug in Oolite itself that was present until at least the current version 1.70). Gave one ship a higher max_flight_speed to be able to follow the mother.

5) Changed intelligence code of the leviathan defenders so they do a 5 seconds speed burst after launching. In the old situation they regularly were hit by the mother when launching at full speed.

6) Changed intelligence code of the military leviathan. Main noticeable difference is that he will move around obstacles instead of just flying through it. This is standard practice for current Oolite internal ships.

7) Renamed several "military" AI.plist references into "militaryFiasco" AI.plist references to avoid potential name conflicts with other OXP's.
The game play itself is in no way altered. I didn't change the intelligence of the target ships. It is just as easy or difficult as it was before.

Direct download link: Military Fiasco 2.1

Link to wiki page: Military Fiasco

Posted: Sat Dec 29, 2007 1:35 pm
by Ark
Oh man that was fast!!!!!!!!!!!
Nice work commander :D
Maybe in the future you should fix some other "buggy" abandoned mission opxs (like Ionics).

Posted: Sat Dec 29, 2007 2:04 pm
by Eric Walch
Ark wrote:
Suggestion : The PNGs for the medals awarded from Thargoid Wars are awful (even the creator of this oxp didn’t like them). Maybe we can find or create better ones and replace them in the updated release.
To late, I already uploaded it. But it is not my intention to improve existing OXP's functionally or change their game effects. I only wanted to tackle the speed impact of some scripts that stay active over longer time. That effects mainly mission OXP's and there are not much of them around. From the mission OXP's I found it only worth to look at those that always stay active. The only two I found were Thargoid Wars and Military Fiasco. There I could get about 95% off from the idle execution time. From some others the author is still around. I also looked at my own UPS mission. That was already structured written but I think I also made it a further 5 to 10% faster by nesting conditions deeper.

Other long mission scripts like "deposed" with 115 condition sets on the main level (about 300 individual conditions to test every update time), or "assassins with over 500 condition sets at the main level (about 1500 individual conditions to check on every update) are removed after finishing the missions. So for these missions the speed effect is only temporally.

However, I did looked at Deposed. Every condition set includes a check for galaxy 4 or 5. That are 115 check together that could be replaced by just two shell conditions. By that you not only avoid 113 (=115 - 2) checks, but also the checks for the other galaxy. But as said before: that mission is removed after finishing.

Posted: Sat Dec 29, 2007 4:58 pm
by Eric Walch
I could not resist, I just went for deposed of Cdr. Wombat.

Added the code to make it compatible with other simultaneously running missions offering OXP's. (added MOP code)

Restructured the code for speed.

Changed version number from 1.1.1 to 1.2

No bug fixing. But working on it, it looked as if there were bugs in it. When e.g. the mission status changed to "PIRATE17", it would display a message and change the status to "PIRATE18".
But in the next command series it is also displaying a message when "PIRATE18" and depstat is clean. This second message was overwriting the previous. Because of the addition of the MOP code, the second display will now wait until the player clears the screen with a keystroke. Looking at the code this was probably intended.


Download: Deposed 1.2.1 (EDITED)

Posted: Sat Dec 29, 2007 6:21 pm
by Ark
I am afraid that the old wiki version (1.1.1) was not the latest one. In the old oosat2 there was a 1.2 http://oldsat.alioth.net/node/27 by the original author.

For more details
https://bb.oolite.space/viewtopic.php?t=4095

So now we have two 1.2 versions. The one from the original oosat2 (written from commander Wombat) and the updated (from 1.1.1) hosted in wiki.
Oh boy I am confused :?