localhero oxp ALPHA

[Svengali]

If you mean “are scripts notified about saving”, then no.

Thanks Ahruman. I was just thinking about two sets of variables, but this plan has now gone to Commander McLane's Nirvana.

[Hoopy]

a minor bug in the OXP - I just got awarded the rank of confed guard but then my statistics said my rank was 'NONE'. I'm guessing my rank gets awarded AFTER the screen is displayed?

All good fun so far

[Svengali]

All good fun so far

Thanks Hoopy.

I just got awarded the rank of confed guard but then my statistics said my rank was 'NONE'. I'm guessing my rank gets awarded AFTER the screen is displayed?

No. It's a missing line in the code. The missionVariable has raised, but I forgot to insert

Code: Select all

success++;

in line 393. It doesn't affect your stats except that the correct stat is not displayed. Your savegame is not affected too. The displayed Rank is lowered by 1. Fixed in the next version. I think I haven't took a look for a long time on the displayed stats. Thank you Hoopy.

[Hoopy]

another minor bug - i finished the next mission (the change in tactics one) and when i docked i got a UPS message saying that a variable hadn't been reset (sorry, I forgot to remember which one it was!). I didn't get a Local hero 'well done' screen either. The F5 screen message was correctly cleared though and F7 says call again later.

A possible enhancement you could make: it says that they're using a change of tactic on this mission so maybe the ships could be a different type or have a different AI. Maybe they could fire loads of missiles instead of concentrating on lasers or something?

Please don't feel I'm complaining with these bug reports - they don't affect the playability and I'm enjoying the OXP. It also has quite a different feel to other OXPs so adds some good variation .

Must go now, the galactic navy are calling!

[Svengali]

i got a UPS message saying that a variable hadn't been reset.

Strange. This will only happen if you launch while a mission offer is displayed. UPS detects that the mission.choice or missionVariables.offering is not cleared and sets a variable to true. But Localhero clears both variables. The problem is that UPS detects it before Localhero clears it. Both are reacting on the shipLaunchedFromStation-Event. Eric has implemented this check to show that it is necessary to clear the used variables, it is a 'educational method' for players and scripters. And we have no control which script is earlier executed.

But you've said that a debrief was not displayed. I've implemented a timer, so you should wait a few seconds (I've set the interval to a higher value than Eric) and the script 'restarts' the whole screen handling by itself.

And all changes are only done if a localhero screen was visible.
I've just played two missions and everything is fine.

Edit: Possibly a third script has set one or both variables, but that means other Oxps can't show their screens. Localhero has a protection (UPS too). But the Loop-Counter must have a higher value. So as I said. Wait a few seconds.

so maybe the ships could be a different type or have a different AI

I'm already thinking about some changes. The behaviour could be more aggressive. But that needs a lot more tests and will last a few weeks.

When I started this oxp it was intended to be a 'mission generator'. I thought it would be easy to make a working oxp, easy to understand and with a 'good' complexity. The last point is the only left over point.

Please don't feel I'm complaining with these bug reports...

No Hoopy. I don't feel offended. Every criticism helps to get things working better. So feel free to post more of these sweety little things.

It also has quite a different feel to other OXPs so adds some good variation

I've used some very uncommon ways to do things (specially the RaidAIs) and it has some features that you currently won't find in other Oxps. The 'real' voices are only one of them.

Anyway. A new version is online (v1.03.8 - 706KB) with an overhauled interval handling. The handling depends on the internal logging. If it's switched on the interval is set to a higher value to prevent from getting a oversized Logfile.

[Hoopy]

i've got UPS, random hits, galactic navy and local hero all running at the moment (lots of other missions OXPs but they're all finished). So maybe one of them confused matters?

I'm pretty sure I was in the station for more than 10 seconds. I was puzzled that the mission success didn't appear so visited each of the screens a few times to see if I could find it. That would have taken a while. I always buy more fuel and check to see if there's gold/platinum.gems worth buying/selling as well, so that takes a while.

The navy mission was the only pending mission (the next system had a nice battle waiting for me). Actually, wasn't there a fix for the navy OXP regarding mission variables - not sure if I downloaded the new version or not... I wish I'd remembered the variable name!

Thanks for investigating and fixing things so quickly

[Eric Walch]

i got a UPS message saying that a variable hadn't been reset.

Strange. This will only happen if you launch while a mission offer is displayed. UPS detects that the mission.choice or missionVariables.offering is not cleared and sets a variable to true. But Localhero clears both variables.

The problem is that UPS detects it before Localhero clears it. Both are reacting on the shipLaunchedFromStation-Event. Eric has implemented this check to show that it is necessary to clear the used variables, it is a 'educational method' for players and scripters. And we have no control which script is earlier executed.

Yes launching from within an offer is bad. Some oxp's even stop working forever after that. But to be on the save side and allow other OXP's to react on such behaviour, I relocate the check to the docking event in UPS next release and add to the text that the error could also be caused by launching from within a screen.

Legacy scripts get their event on launch before JS so they run always sooner. A problem stays that the legacy scripts runs 10 seconds after the mission-screen has been set-up. When the player reads the text for 10 seconds or longer to make a choice, the legacy script can evaluate the choices immediately after the screen ended. But when a player knows the text and immediately makes his choice and than launches, (launches within 10 seconds after the missionscreen start) things can go wrong. It could even be that his own script is missing the choices. With JS there is always a trigger when the screen ends. (Only not when launching from within a screen, but that is also corrected in Oolite 1.71)

[Svengali]

I'm pretty sure I was in the station for more than 10 seconds. I was puzzled that the mission success didn't appear so visited each of the screens a few times to see if I could find it. That would have taken a while. I always buy more fuel and check to see if there's gold/platinum.gems worth buying/selling as well, so that takes a while.

That's strange Hoopy. Localhero has a timer that checks if a missionscreen is currently active and if Localhero has already made his job. If not and a loopcounter is greater than a few times, it clears both variables and reactivates the screen handling. If it happens again, please activate the Oxp-internal logging and try to reproduce the error. Then you could send me the log-file.

BTW: What have you done before? Have you docked while the mission is running without choosing an option? Scooped any other escape-pods (non-mission)? Or left the system?
I think we should dig a little bit deeper.

I relocate the check to the docking event in UPS next release and add to the text that the error could also be caused by launching from within a screen.

Great Eric . I'm already loving this check. It helps us to find some weak points in our scripts. And it is a good reminder that there is still a lot of work.

[Hoopy]

I'll enable logging next time i take a local hero mission and try to reproduce it. I think i did scoop some other stuff (I killed the helpful people who battled with me to defeat the incoming wave) but i didn't leave the system.

[Eric Walch]

But when a player knows the text and immediately makes his choice and than launches, (launches within 10 seconds after the missionscreen start) things can go wrong. It could even be that his own script is missing the choices.

Not right. Searching something else in the code I noticed that Oolite is explicitly checking every script immediately after finishing a mission-screen in a normal way (By pressing space or hitting return).

In that part of the code I also noticed that script checking immediately starts when pressing F7. (The screen Local Hero uses. But without a tickle it needs an other trigger )

[Svengali]

In that part of the code I also noticed that script checking immediately starts when pressing F7. (The screen Local Hero uses. But without a tickle it needs an other trigger )

But that's why I'm wondering. There is a timer additionally to the tickle. I've tested it several times and it is working (except the version 1.03.8 that has used a faster interval than Oolite could process when more ressources were needed). And the timer doesn't stop on a GUI_SCREEN_REPORT (the screen that is used to display the captured or rescued human/felines/...). Hmmm?!..?

So just try the latest version.

[JensAyton]

Tickles are stopped on “special” screens, but timers are not. There’s still time to change this. Arguments either way on a postcard to…

[Timm74]

Hi!

I am playing the localhero mission for a few times now, and I am always being accused as polishing my fingernails and taken off the mission.

This time I got a message that I succeeded while in flight, however, when I landed: Fingernails again and Harkov escaped. I expected more gratitude for bringing in a captured leader of Harkovs group ...

Happens with Oolite 1.70

Is this normal?

Cheers!
Timm

[Hoopy]

you have to kill everyone before returning. strange that one time you got a success message and were then told you'd failed...

[Eric Walch]

you have to kill everyone before returning. strange that one time you got a success message and were then told you'd failed...

It could be that you are using an older version of the OXP. Some older ones (the pre Java versions) don't work on 1.70. They behave similar in that you get the success message. but nothing on docking.