Oolite Bulletins

Found it. I've changed a ship-script to ship.deployEscorts(); That causes some more enemies than intended. The mission-script is ok. And it only happens if you load a saved game with a running mission. I'll check all other ship-scripts and upload in an hour a corrected version. Thanks for that Hoopy.

all part of the service!

I'm never quite sure whether i'm the first to try all the OXPs or if I'm just the pickyest!

(I think it's the latter, I'm a software programmer by trade and have done my fair share of formal testing - it tends to make us almost as picky as the compiler is...)

edit: so if everybody stops launching their new OXPs I'll get a chance to try and create my own

Hoopy wrote:

in your PM you asked whether you thought it was took hard. I think it's fine with a cloaking device (you just have to manage shield levels vs energy levels) but would be very hard without it. I like the way it evolves into one continuous dogfight with more ships entering as you kill them off. Just like in an anarchy on the BBC version

I don't think it is to difficult. It was me who complained after the first release that it was to easy. I could just went off and shoot the bunch down without using any tactics. In the next release the targets got a little harder with stronger opponents and now it starts to get a challenge. I think under Oolite 1.71 it even will be harder as the escorts now suffer from a oolite bug that makes them loose their escort function. Under 1.71 mother and their escorts will all turn to you immediately when you hit one of them. (now they have to locate you individually)

But cloaking is cheating yourself. I just finished mission 18 several times. I never use cloaking, it is just a matter of fight tactics. Don't go for the whole bunch, distract some from the group (use your injectors), kill them off, wait until full shields and go for the next few. This way I accomplished the mission nr 18 now 3 or 4 times. But never came to save it $%$#@$.

When hitting save in full screen mode, I found myself in the settings menu. I could come back to the mainscreen but all key-input was blocked. Even quitting was impossible. The only solution was a forced quit by the system. It happened me now several times after trying to save an accomplished mission nr 18. But I was the last few weeks so occupied with UPS that I didn't look at it further. And for UPS testing I rarely saved games and always started from old test files. But today I dove deeper in it. Removed Local_hero, flushed the cache and retied with the same result. So it was not Local_hero. The fact that is was always a local_hero save was pure coincidal. Save in an other system: the same. Frustrating. A save in window mode gave the solution. It worked. I used a new name and now the new file also works well. There must have been something corrupted in that file. (I'll try to look in it once).

But it means I still have to start again on mission 18.

i always turn the cloak off to fire (so i get credited with the kill). This means that the enemy can still see you - and shoot at you! If you leave the cloak on too long (to let the lasers cool) then you won't have enough energy to turn it on again afterwards.

You're right, I could just achieve a similar affect by injecting away and then back in each time - but who's to say which techniwue is more 'cheating' than the other

To be honest I find having to inject away and back again is a bit too tedious to be fun. Just like fighting a FdL as they often use that tactic. That's one of the fiew times I'll ever fire a missile at something - I just can't be bothered to dogfight it for 10 minutes...

Ok. Online. I think it was a c&p mistake and I'm so angry that I haven't noticed it before. I have had put it in for some tests and forgot to delete it.

BTW: If you have some trouble with the localhero.oxp, please enable the oxp-logging (line 17 in localhero.js) and send me your log-file.

Eric Walch wrote:

When hitting save in full screen mode, I found myself in the settings menu. I could come back to the mainscreen but all key-input was blocked. Even quitting was impossible. The only solution was a forced quit by the system.

I've spotted this too. But it has happened only one or two times. And good to know that it doesn't happen in windowed mode.

I just finished translating the MilitaryFiasco.OXP into JS. But I always was thrown back into my first missionscreen. Then I started to setting "logs". It seemed that the "mission.choice" and the "mission_offering" both stayed cleared. But the code could never come in my clearing routine.

At last I thought about removing the last added OXP. That was Local_Hero. Now the problem was over. My last save game was in a station were Local_Hero would offer me a mission when entering the system_data screen. But I never went to that screen. Even the first offering page of my mission was shown but Local_hero kept clearing all choices I made.

That looks if it needs an update again.

Yes Eric. You are right. It's currently totally aggressive and does sometimes confusing or suppressing other screens. And because of it's dressiness on Launching nobody will notice it. But you have. Thanks again.

Svengali wrote:

Yes Eric. You are right. It's currently totally aggressive and does sometimes confusing or suppressing other screens. And because of it's dressiness on Launching nobody will notice it. But you have. Thanks again.

I found the bad guy I think. When docking and not in the "missionHero" screen you set your Mission variable to "LOOP". Then on a missionScreenEnded event you do:
For some reason you assume the "missionScreenEnded" event was generated by your OXP and you reset things without testing if it really was your OXP that triggered the event.

Eric Walch wrote:

For some reason you assume the "missionScreenEnded" event was generated by your OXP and you reset things without testing if it really was your OXP that triggered the event.

I've changed it and spotted some other problems after changing it. The called function is called on about 20 different places (with different arguments), so I may need some time for frickling around with it. And no. This was meant to switch back to the handling routine if it was NOT my Oxp. I have to think about the consequences every change would cause. And you're right. The main-problem is in the called function. Splitting it into two parts will do the trick, I think. But I may need a deeper knowledge about the whole problematics. Thanks a lot, Eric.

Next version is online (V1.03.6). I've implemented Eric's suggested timer, the missionscreen problem seems to be solved and I've added a sweety little reminder. So you won't miss it if a new mission is available. http://wiki.alioth.net/index.php/Localhero_OXP

Back to the optimization.

Thanks for your answers Cmdr. James and Ahruman. Your discussion was very interesting. Specially:

Ahruman wrote:

JavaScript is not interpreted directly, but rather is compiled to bytecode at load time.

Cmdr. James wrote:

Id say the best thing to do, is to convert to a number (parseint) and then compare to a number.

I've already used this way, but I was not shure. So the next question is a little bit more specific and I think the result or the consequence of thinking about speed optimizing. Is there a safe way for an Oxp to reckognize the save-situation?

If you mean “are scripts notified about saving”, then no. You should make sure your mission state is reflected in mission variables at all times (or rather, between invocations of your script; the game can’t be saved in the middle of running a script). In particular, you should not rely on saving only occurring while docked; someone suggested auto-saving at witchjumps, and while I don’t intend to work on it at the moment it is feasible.

World scripts are notified of loading through the reset() event.

someone suggested auto-saving at witchjumps, ... it is feasible.

YES! YES! Please put that one in ... would also be VERY handy in case of crashing game!

Would it also be possible to script in saving the game in other stations than the main one? As that would also be great, and a good crash insurance!

Enthusiastic

Lestradae

it's only possible to save at the main station as it's the only station that's guarenteed to be there when the game next loads.

Imagine saving at a hoopy casino, exitting the game, removing the casino OXP, restarting the game and loading your save.

It wouldn't be able to put you where you were because it isn't there...

Lestradae wrote:

Would it also be possible to script in saving the game in other stations than the main one? As that would also be great, and a good crash insurance!

No, for the same reason as it always wasn't: There is no way to guarantee that a scripted (extra) station would be generated again the next time the system is populated. And that includes the time it is populated when you reload your saved game.

So possibly the station you had saved at wouldn't be there anymore.

Which would put you straight into ... Nirvana?!?

Not a good place to be, if you want to fly a ship.

he he he he

For once I posted quicker than Commander McLane