oops- After launching from the Hunting lodge I get this conflict message (I guess a conflict with UPSoxp)
This is a general problem of a lot of oxp makers. They only look if their oxp works as a stand alone thing but don't look at other oxp's running simultaneously. I already noticed that this oxp never clears the choices when ready.
This means other oxp's never know if the choice is already read out or not. This is because the oxp that starts first after a missionscreen is finished, is not always the one that generated the screen. If it sets up a screen of its own, the choices in memory are reset and the script that originally created the screen won't find the choices anymore.
For Oolite 1.74 things will get much easier in writing. Than we have a new way of setting up a missionscreen that only returns the choices to the script that generated the screen.
Thanks for the quick reply Eric
I know UPSoxp is your's too. (I didn't mean to sound as if the problem was directed at you)
Is there a quick fix us plebs can cut'n'paste into either oxp to stop the conflict, while we wait for 1.74?????
Thanks
It's one of these things that doesn't show up on a mac.
Might have known it was Bill Gates fault
Although the Mac GLSL parser is in general a good one, in this particular case it’s the one that’s wrong.
Incidentally, this problem would go away if people adapted the approach to lighting used in the default ship shader. I guess I should put together some simpler examples.
oops- After launching from the Hunting lodge I get this conflict message (I guess a conflict with UPSoxp)
This is a general problem of a lot of oxp makers. They only look if their oxp works as a stand alone thing but don't look at other oxp's running simultaneously. I already noticed that this oxp never clears the choices when ready.
This means other oxp's never know if the choice is already read out or not. This is because the oxp that starts first after a missionscreen is finished, is not always the one that generated the screen. If it sets up a screen of its own, the choices in memory are reset and the script that originally created the screen won't find the choices anymore.
Eric, could you out together a stand-alone version of your error checking script so we can integrate it into Debug.oxp? This would increase the chances of people fixing the problem when updating/cloning existing mission scripts.
Thanks for the quick reply Eric
I know UPSoxp is your's too. (I didn't mean to sound as if the problem was directed at you)
Is there a quick fix us plebs can cut'n'paste into either oxp to stop the conflict, while we wait for 1.74?????
Thanks
It is not a conflict itself. It is just a diagnostic message that there could be a conflict. I added it as hint to other oxp-writers that they should check their code. And as warning to the player that there is a small chance of trouble.
Ahruman wrote:
Eric, could you out together a stand-alone version of your error checking script so we can integrate it into Debug.oxp? This would increase the chances of people fixing the problem when updating/cloning existing mission scripts.
Yes, I can do it. With the future changes in 1.74 I removed these messages from ups itself as ups don't needs them anymore, but I still think it helps tracing flaws in other scripts, so inside debug.oxp might be a good idea.
Apologies, I didn't realise there was a problem with clashing choices as well as mission screens. I had assumed that as choices are called as part of the runMissionScreen function they somehow stay with the the screen rather than being a standalone thing.
Would I be right in thinking this can be fixed by adding mission.choice = null after each of the choice evaluation screens? If so I'll get onto it a.s.a.p.
Looks like a v1.1 won't be far off!
Download Resistance Commander plus many other exciting OXPs HERE
With a saved game starting in Aronar, the saved game loads, but when I launch from the station (F1) I crash immediately. I'm on Ubuntu Linux (not the new one, the one just before it Jaunty something), I'll download the new Feudal States and try it again tonight.
With a saved game starting in Aronar, the saved game loads, but when I launch from the station (F1) I crash immediately. I'm on Ubuntu Linux (not the new one, the one just before it Jaunty something), I'll download the new Feudal States and try it again tonight.
No I'm a Jaunty Jackalope, I meant as opposed to a Karmic Koala.
DaddyHoggy wrote:
Chrisfs wrote:
With a saved game starting in Aronar, the saved game loads, but when I launch from the station (F1) I crash immediately. I'm on Ubuntu Linux (not the new one, the one just before it Jaunty something), I'll download the new Feudal States and try it again tonight.
Would I be right in thinking this can be fixed by adding mission.choice = null after each of the choice evaluation screens? If so I'll get onto it a.s.a.p.
Looks like a v1.1 won't be far off!
Not for all. For multi screen offers you only need it for the last choice.
Not clearing the choice does not affect your oxp but just makes it a bit more difficult for others when they want to make an offer at the same time.
With future 1.74 we will have a call-back function that deals with the choices. That way only the creator of the mission-screen receives the choices back. Translation for 1.74 will not be that difficult as you can just use your existing "this.choiceEvaluation" as the call-back function in most cases.
No I'm a Jaunty Jackalope, I meant as opposed to a Karmic Koala.
DaddyHoggy wrote:
Chrisfs wrote:
With a saved game starting in Aronar, the saved game loads, but when I launch from the station (F1) I crash immediately. I'm on Ubuntu Linux (not the new one, the one just before it Jaunty something), I'll download the new Feudal States and try it again tonight.
You'll be an Intrepid Ibex man then?
D'oh! Misread your statement as being "the one before Jaunty" when in fact you meant no such thing - I've run Oolite (1.65-.69) on Fiesty, and 1.73.4 on Gutsy - I'm just about to install it on Karmic (I have Jaunty on this laptop but Oolite's not on it - it's on the Vista partition instead)
I'll double check by uninstalling The Feudal States and checking Aronar is reachable. Then I'll re-download The Feudal States and if necessary correct the errors mentioned above as per Griff's advice. If I'm still having problems I'll uninstall All-Stars to remove unneccesary "error spew" (Hehehe that's funny) and then save a log.
I've tried all that, definitely no spaces after the \ in 'feudal-fragment-shader.fragment'. Still get a crash every time I begin Hyperspace to Aronar, but no [shader.compile.fragment.failure] error showing up. Using a fresh commander direct from Lave, and no other OXPs (just my BBC style keyboard remap) this is the log:
Have you ever tried with one of the latest trunk builds? If not, have you DEP (Data Execution Prevention) turned on or off?
Screet
DEP is excluded for Oolite.
Just tried with latest Trunk 1.74.0.2885 (excluded DEP for that too), same result, crash as begin hyperspace to Aronar, with vanilla Jameson direct from Lave and no other OXPs installed.
Incidentally, My main commanders Griff Cobra MkIII has lost it's custom paint job and decal in the trunk version. The shipdata.plist edits and save game edits are the same as 1.73.4 and it works there.