Random Hits - abandon mission without leaving galaxy?

[el_Paraguayo]

As those of you who saw my first post will know, I'm pottering round G2 in a Cobra Mk I, and getting blown to bits fairly consistently.

I need cash to upgrade to a Mk III but the 400-500 credits per easy Random Hits mission (plus the travel time) was just going to take too long. So I thought I'd pick a slightly harder mission for 5k...

Bad idea.

I'm getting ripped apart every time by my target's escorts whose lasers just don't miss!

I tried accepting an easy mission but my mission list is still showing the harder one.

Is it possible to abandon a mission without leaving the galaxy? I'm trying to save money and don't want to cough up for a Galactic drive but at the same time I don't want to be stuck on a mission that I can't do in this ship (yeah yeah, workman blaming tools, I know I know...!)[/u]

[Smivs]

I don't believe I'm suggesting this, but had you considered an Energy Bomb?

[Eric Walch]

I don't believe I'm suggesting this, but had you considered an Energy Bomb?

I didn't thought at that. That will kill them. No reward, but at least the mission is finished.

The code itself gives no option for withdrawal of a mission. I don't know if this had a real reason, or that it was just difficult to implement (In legacy code does any addition influence the whole script so things become complex fast). In the current JS version there is already a special screen for docking while a mission is running. It would be simple to add a third choice: cancel the mission at 10% of the contract value

But that is to Little Bear to decide.

[el_Paraguayo]

Thanks guys. That would probably work.

However, it's a moot point now:

I went back to the planet for the 20th time, started getting ripped apart by acurate lasers. This time I managed to destroy the fleet by picking off one, zooming away to let shields recover and then re-engaging.

Didn't find the target though.

On pressing F5 I found out he'd had an unfortunate accident and I was compensated to the tune of 103 Cr.

Nice. So much for my easy money!!

[tonyhippy]

Meanwhile every time you visit a Seedy Space Bar, buy up all the cheap gold, platinum and minerals, and sell them booze and food for which they pay highly for. When you're full of gold etc sell it at a rich system for top dollar.

[Poro]

I've yet to engage a mark that doesn't use fuel injectors to escape when you hit them a couple of times. Try to identify your target as quickly as possible, and hit 'em a couple of times. They will probably boost away and leave their friends behind - giving you ample chance to isolate them and gradually run down their shields.

The only thing to worry about is how long it will take their friends to catch up.

[Eric Walch]

...I'm getting ripped apart every time by my target's escorts whose lasers just don't miss!

I tried accepting an easy mission but my mission list is still showing the harder one.

Is it possible to abandon a mission without leaving the galaxy?

It was never thought of that someone would want to cancel a mission. But, if you want to be a coward: I added now a cancel option. It will cost you 10% of the contract fee and also your status it lowered. The cancel option will only be there if you have enough money to cancel....

Just uploaded it as version 1.4.1.

[caracal]

It was never thought of that someone would want to cancel a mission. But, if you want to be a coward: I added now a cancel option. It will cost you 10% of the contract fee and also your status it lowered. The cancel option will only be there if you have enough money to cancel....

Just uploaded it as version 1.4.1.

Nice one, Eric. I cannot imagine ever cancelling a mission, but it's nice to know the option is there.

By the way, not that it's relevant, but in case nobody has reported it yet: Random Hits missions are a no-go in trunk. Script runs too long, gets the axe. The space bars are still there, though, and I still visit them for the visual enjoyment and occasional trading and even more occasional massive gun battles outside.

[Eric Walch]

By the way, not that it's relevant, but in case nobody has reported it yet: Random Hits missions are a no-go in trunk. Script runs too long, gets the axe. The space bars are still there, though, and I still visit them for the visual enjoyment and occasional trading and even more occasional massive gun battles outside.

Yes, currently trunk is not really suited for playing because of a lot of script cut-off code. (At least playing a mission would be not wise as an important piece of code for that mission might not run) The idea is to find bottlenecks in the code and see if such things can be optimised. Adding ships is the slowest code but that is already excluded from the timer. The second slowest code is probably scanning of entities. I already reduced the scanning around to bar by at least 90%. Instead of all individual ships doing the scan, its only the bar that does a full scan and send the other ships an attack message when needed.
Ahruman is working at this code. I assume that code that can't be optimised, just will get a longer allowed time in future.

[caracal]

Yes, currently trunk is not really suited for playing because of a lot of script cut-off code. (At least playing a mission would be not wise as an important piece of code for that mission might not run) The idea is to find bottlenecks in the code and see if such things can be optimised.

Yes. I know this. You and a_c and Thargoid and Ahruman and anybody else who is within fifty light years has said this about seven hundred times since the 13th. Should I just keep quiet about any anomaly I see when running trunk, and let you discover it yourself in due time? Do bugs in trunk just magically run out into the light without benefit of playtesting? If so, let me know how you guys do that, because I have some code that could use the technique!

I'm sorry for being a bit testy about this subject, Eric, but it seems I have to wade past a lecture every time I try to help in this way. I've been a professional programmer for over thirty-five years, and have been following oolite (and building it from source) for two. Any way I could get, like, a badge or something, that says that you can assume I'm not a total idiot from square one?

Adding ships is the slowest code but that is already excluded from the timer. The second slowest code is probably scanning of entities. I already reduced the scanning around to bar by at least 90%. Instead of all individual ships doing the scan, its only the bar that does a full scan and send the other ships an attack message when needed.
Ahruman is working at this code. I assume that code that can't be optimised, just will get a longer allowed time in future.

Sure, it makes sense for rooting out bugs that might not be obvious any other way. And if any script is going to be hit by the timer check, it'll be Random Hits--of all the OXPs I have installed, oolite-randomHits.js is by far the largest, almost twice the size of its nearest competitor. I was just noting the behavior, not complaining about it.

[Eric Walch]

Adding ships is the slowest code but that is already excluded from the timer. The second slowest code is probably scanning of entities. I already reduced the scanning around to bar by at least 90%. Instead of all individual ships doing the scan, its only the bar that does a full scan and send the other ships an attack message when needed.
Ahruman is working at this code. I assume that code that can't be optimised, just will get a longer allowed time in future.

Sure, it makes sense for rooting out bugs that might not be obvious any other way. And if any script is going to be hit by the timer check, it'll be Random Hits--of all the OXPs I have installed, oolite-randomHits.js is by far the largest, almost twice the size of its nearest competitor. I was just noting the behavior, not complaining about it.

Any bug report is welcome. However, as the code has just been implemented and is still strongly changing, I think a lot of the reports are false reports were Ahruman is still working on. I think it will take some time for cut-off are reliable.
That said, their might be already bugs in the current code that are worth reporting.
For random hits, it is not the oxp itself that is shut off, but the scanning of the bar for offenders. And the cut-off seems to depend on the number of installed oxp's also. When playing with my full set of oxps I see cut-offs in the log that do work in my reduced oxp environment.

[Kaks]

By the way, not that it's relevant, but in case nobody has reported it yet: Random Hits missions are a no-go in trunk. Script runs too long, gets the axe.

Hi caracal,
First off, and seriously: thanks for the report, always appreciated.

Hopefully we should be upgrading the js engine soon. By we I actually mean Ahruman, once he's back from his holidays: nobody is particularly keen on touching that part of Oolite, mainly because of the amount of potential breakages that could happen as a result, so by default the Supreme Grand Admiral found that unenviable task sitting on his lap.
Once that upgrade is made, all the code time-out problems will be worked on, hopefully in an orderly fashion, but before then it might not make too much sense to try and correct parts of the code that might be removed/modified beyond recognition in a couple of weeks time.

Probably the best thing to do - until the new!, improved! js engine is put in place - is to keep a unified list of what oxps (/ oxp combinations) are way too slow, so when we finally get round to working on it it's easy to find the information, rather than chase it down various seemingly unrelated threads...


PS: I don't think anybody thought you don't know what you're doing/talking about, it's just that we're trying to say we can't work on those specific problems just yet!

[Thargoid]

Or to put it another way, the reports are of great interest, but to the game trunk developers rather than the OXP makers themselves at this stage.

Our work will follow later once the engine has been changed, the turbo cleaned out and the nitrous injectors refitted and upgraded. Oh and the Stig has taken it around the track once or twice

And yes it is something of a mantra for many of us, simply because we get reports so often by people who are trying to use trunk for gaming and who don't know the "back history" nor have heard the warnings. Consider yourself the blessed exception to the rule

[caracal]

Any bug report is welcome. However, as the code has just been implemented and is still strongly changing, I think a lot of the reports are false reports were Ahruman is still working on.

Too soon, huh?

I think it will take some time for cut-off are reliable.

Yeah, back when it first appeared, at 0.05 seconds, it was hitting a lot of scripts. Now at 0.25 just a rare few. The way Ahruman talked about it, some sort of script maximum time will probably be retained in the code, but setting it so low initially was more of a debugging tool, just to get an idea of the scope of the problem.

That said, their might be already bugs in the current code that are worth reporting.

This doesn't look like a bug to me, more an interesting fact to take note of. But it sounds like you have some ideas about why it's happening, and maybe you're waiting until a more "final" timeout value is chosen to see if any action is needed. I mean, we all like optimized code, but squeezing the last few nanoseconds out of code if unnecessary is a waste of time.

For random hits, it is not the oxp itself that is shut off, but the scanning of the bar for offenders. And the cut-off seems to depend on the number of installed oxp's also. When playing with my full set of oxps I see cut-offs in the log that do work in my reduced oxp environment.

A-HA! So you do play the trunk version!

Interesting note about the number of OXPs affecting the run rate. Sounds like something I should try.

[caracal]

Hi caracal,
First off, and seriously: thanks for the report, always appreciated.

Yeah, sorry I got exercised over Eric's response. I know how it is on a support forum, and should have been more understanding.

Hopefully we should be upgrading the js engine soon.

Oh? As in, moving to something other than SpiderMonkey, or actually tinkering with its internals? Or do you mean the way oolite uses SM?

By we I actually mean Ahruman, once he's back from his holidays: nobody is particularly keen on touching that part of Oolite, mainly because of the amount of potential breakages that could happen as a result, so by default the Supreme Grand Admiral found that unenviable task sitting on his lap.

Poor man, and he's welcome to it. I know the JS engine itself is in C, but Ahruman wrestles daily with ObjectiveC as well. I've used some oddball languages in my time, but looking at ObjC makes my eyes burn. And my brain hurt. ("It will have to come out!")

Once that upgrade is made, all the code time-out problems will be worked on, hopefully in an orderly fashion, but before then it might not make too much sense to try and correct parts of the code that might be removed/modified beyond recognition in a couple of weeks time.

Right, hence my comment to Eric about unnecessary optimization. I just shouldn't have posted my initial comment, sigh.

Probably the best thing to do - until the new!, improved! js engine is put in place - is to keep a unified list of what oxps (/ oxp combinations) are way too slow, so when we finally get round to working on it it's easy to find the information, rather than chase it down various seemingly unrelated threads...

Is there already such a thread, and I missed it? Anyway, the only timeout I've seen since the switch to 0.25 seconds is Random Hits.

PS: I don't think anybody thought you don't know what you're doing/talking about, it's just that we're trying to say we can't work on those specific problems just yet!

Don't bullshit a bullshitter, my friend. After you've run a support forum for a while, you begin to assume that everybody is an idiot (especially when they approach a hot-button issue like I did), unless you know them personally. I just haven't been around long enough, I suppose. Anyway, I apologize for causing a ruckus, and will choose my words more carefully in the future.