How are you reading your position? Mine's from system.mainStation.position when in Lave system. I guess yours is the same to get the 1st two figures the same...
Also have we a platform-dependent issue here? I'm on Windows and I know Eric is on a Mac. What are you on?
Distance reading: Shift-H, then loading the Latest.log
System: Ubuntu 8.10 (Intrepid Ibex), 64-bit
And as I noted before - might be more robust instead of hard-coding the position of the Academy to calculate it? That way even if there -are- any platform/version/OXP issues, they won't matter. Dunno how easy/hard that is to do in a script though.
I'm a little surprised that you got the expired message, that should only trigger after 15 minutes (it's only in there to prevent people starting the course and then wandering off and things running on forever). I'll look into that one a little more.
I am surprised you think 15 minutes is plenty of time. The first round I was confused as not all buoys send a message "go here". So after passing a ring and going to the next buoy I got a bit lost to what should be the next one and kept going to wrong buoys until I noticed that even the equipment of a Jameson could already get a ships name by targeting it.
Today I retried it. First time almost all at full speed and it still took 9m25s. At the end I notice to late there was a moment I was not mass locked. But again a bit confused as buoy 3 and 4 didn't sent messages and from the previous buoy it was not yes possible to target them for their name. Still I headed for the right ones.
On my second try today I again did it all at full speed and watched for moments to use the j-drive. But this time I was mass locked the whole route. (by station, the rings and some nps ships). This time 8m37s.
15 minutes is good to do but you do need more half that time. (Fresh Jameson with a cobra)
It certainly is nice and good as training. The two buoys that don't send messages should also be easy findable as there were only 3 visible. The one you came from, the one you were heading for and a third unknown one. You just get confused at the start as the first few send a message and you expect all others will do also. But it is good this way as it is a training course. You have to learn something and I certainly progressed in my three rounds.
--
On the crash, that is just bad luck and an oolite bug with the timers. I noticed my last ups release also suffers from this bug during the boa mission. UPS will also crash Oolite when jumping out of the system while the target boa is still there. I fixed this now as good as possible and probably upload it tomorrow.
I just tried it on my Ubuntu box (8.10 32 bit, oolite v1.72.2) and that agrees with my Windows machine (z component 592262).
So we have a difference between 1.72.2 and 1.72.3
I'd have to think about doing the calculation route. At the moment I'm using the shipdata spawn key to set positions, so I can use the spawn command to bring the entities into play linked to script variables (which you can't do with legacy_addShipsAtPrecisely). The only other thing to be done is spawn the whole lot somewhere in deep space and then move it, but even that wouldn't work for the pilot course.
So my alternate questions would be why has the station position changed in the WIP version, is it deliberate and is it going to stay in the release version?
Or do I have to make Lave Academy for v1.72.2 and below and a new version for 1.72.3?
The station position one seems odd to me though, it's either 1.72.3 vs 1.72.2 or a platform difference perhaps. Neither of which are appealing!
very strange having two different-axis should not be possible. I am also on 1.72.2.1. The difference is certainly not in the Oolite version numbers. From my console readings:
It are indeed different figures as on the windows platform. As written in an other thread the planet z position is calculated as 12 times the planet radius with a variation of 3 radii. This variation is a pseudo random number that uses the same seed for a given system. Should always give the same number for Lave. This discrepancy somehow suggest it doesn't.
Are you sure you used a new commander to read the values. An other oxp might have written an "override" position for lave.
Last edited by Eric Walch on Sun Mar 08, 2009 10:38 pm, edited 1 time in total.
I am surprised you think 15 minutes is plenty of time. The first round I was confused as not all buoys send a message "go here". So after passing a ring and going to the next buoy I got a bit lost to what should be the next one and kept going to wrong buoys until I noticed that even the equipment of a Jameson could already get a ships name by targeting it.
Today I retried it. First time almost all at full speed and it still took 9m25s. At the end I notice to late there was a moment I was not mass locked. But again a bit confused as buoy 3 and 4 didn't sent messages and from the previous buoy it was not yes possible to target them for their name. Still I headed for the right ones.
On my second try today I again did it all at full speed and watched for moments to use the j-drive. But this time I was mass locked the whole route. (by station, the rings and some nps ships). This time 8m37s.
15 minutes is good to do but you do need more half that time. (Fresh Jameson with a cobra)
It certainly is nice and good as training. The two buoys that don't send messages should also be easy findable as there were only 3 visible. The one you came from, the one you were heading for and a third unknown one. You just get confused at the start as the first few send a message and you expect all others will do also. But it is good this way as it is a training course. You have to learn something and I certainly progressed in my three rounds.
My testing with a brand new Jameson in an unmod'd Cobra can do the course in 8 minutes. Hence why I set 15 minutes, it seemed a fair figure but it's not set in stone, if people find it too short it can be increased.
As to the messages, I'd love to know why some of the buoys don't transmit them. They're sent by the AI, and all the buoys use the same one. Could you have a look at it and see if I need a pause or some other tweak in there to ensure they transmit?
Eric Walch wrote:
On the crash, that is just bad luck and an oolite bug with the timers. I noticed my last ups release also suffers from this bug during the boa mission. UPS will also crash Oolite when jumping out of the system while the target boa is still there. I fixed this now as good as possible and probably upload it tomorrow.
v1.0.1 should get around it. I've used an AI state to call a function in the ship-script to shut the timer down and then remove the ship, rather than just removing it directly. It seems to work. I couldn't get a direct call to the ship script to work for some reason, although that's probably more related to the state of my brain tonight...
The station position one seems odd to me though, it's either 1.72.3 vs 1.72.2 or a platform difference perhaps. Neither of which are appealing!
I can confirm that the Academy is much further from the station in 1.73, but no idea what causes this difference. The directional buoy is also invisible from Lave station in 1.73. A partial solution could be:
if(this.wayBuoyArray.length == 0)
{
var edu=system.shipsWithPrimaryRole("laveAcademy_academy")[0];
var thatWay=system.mainStation.position.direction(edu.position);
system.legacy_addShipsAtPrecisely('laveAcademy_wayBuoy',1,'abs',system.mainStation.position.add(thatWay.multiply(22000)));
//system.legacy_spawnShip("laveAcademy_wayBuoy");
}
as long as you've got both buoy & station directly behind you, you'll definitely get to the Academy.
To be compatible with both 1.72.2 & 1.73, it would probably be best to reposition the academy and all the buoys if their distance from the main station is longer than - say - 80000 m
Thargoid, I've more or less done that already in my copy of LaveAcademy_systemScript. Shall I PM you my meagre efforts?
Kaks - the problem is going to be with the pilot course, as that too is currently positioned by absolute positioning. So that too would need to be moved when its spawned if things aren't where they should be. It's caused by the Coriolis/main planet not being in the same place in 1.73/1.72.3 as in the current 1.72.2.
I can do it, but I'm loathed to do so without knowing the reason behind why it needs to be done, and why everything seems to have moved in 1.72.3 / 1.73 (whatever it's correctly designated). Especially given that the setPosition/position = change will also come into play.
So for the moment until I can get some answers for that (and whether these position changes are actually going to be in the final version) then there's too much risk that it'll be a lot of work for no good reason. I'm sticking with my 1.71 --> 1.72 policy of not coding for a WIP version until it's released and stops becoming a WIP. Or else I'm probably going to get as frustrated as Frame with all these moving targets to code at.
Maybe this is also related with the claim by some people say the Lave racing rings don't work anymore since a few oolite versions. I never understood what was not working with them as they still work with me. But they must also suffer from this position bug on those window machines.
Oolite very precise tries to recreate the random generator of old elite versions. This is because nothing was hard coded in old elite but calculated with pseudo random numbers generated with fixed system seeds. For this is even creates 16 bit calculations to ensure the rounding is the same as the old 16 bit processors.
It seems that the bug is already fixed in the 1.73 release? It would also be interesting if it always wrong or only when starting from the station and not by entering from witchspace.
The racing rings (the original ones in Lave.oxp) have always worked for me (on my Windows machines) so I don't think this is the case. The opposite may be true, but as I said above the position figure I get on both my Windows and Ubuntu boxes agrees. So I would say it's something much newer than this, in the update from 1.72.2?
What may be interesting is to see if the sun positions are also changed between the two versions, and the positions of planets and main stations in other systems as well. If so then this needs looking at, as I guess other OXPs may well use absolute positioning and they'll get potentially broken too.
And having given it some more thought, if you report that 1.72.2.1 on Mac has the same problem, then something is going to need to be done. Kak's code above seems as good a way as any (although the distance to the Academy is still going to be huge, but at least you'll be pointed in the right direction) so I'll roll that into the code and post another update tonight. I am going to change it slightly though to add a second buoy if the distance between the main station and the academy is > 70km, so people don't get too lost.
// set the system seed for random number generation
seed_for_planet_description(system_seed);
/*- space planet -*/
a_planet = [[PlanetEntity alloc] initWithSeed: system_seed]; // alloc retains!
double planet_radius = [a_planet radius];
double planet_zpos = (12.0 + (Ranrot() & 3) - (Ranrot() & 3) ) * planet_radius; // 10..14 pr (planet radii) ahead
Every time Ranrot() is called it changes the seed so it will generate a new value the next time. I suspect that with the introduction of textured planets the Ranrot() sometimes get an extra call between resetting the seed and calculating the distance. It even could depend on preferences. So maybe it is solved for 1.73 or maybe it used other preferences. e.g. shaders or low quality
So in summary 1.72.2 test release is as it should be (and the Academy hard-coded positions are near the station), 1.72.2.1 (Mac) and 1.72.3 (WIP) have a problem which should hopefully be fixed in 1.73 to revert the station and planet positions back to where they should be by sorting out the Ranrot() calls?
In the meantime a little dynamic coding of the buoy positions should suffice to lay a trail of breadcrumbs between one and the other.
Or have I misunderstood? I'm something of a confused alien at the moment And if so who's going to raise the bug report (or does it need one, given we're talking about WIP)?
In the meantime a little dynamic coding of the buoy positions should suffice to lay a trail of breadcrumbs between one and the other.
Or have I misunderstood? I'm something of a confused alien at the moment And if so who's going to raise the bug report (or does it need one, given we're talking about WIP)?
No need for the bug report! The Ranrot() > textured planet thing might well be what's causing all this kerfuffle, & I'll have a good look at the problem this evening if noone else does between now & then...
About the trail of buoys, yes as things stand a 2nd one would be very helpful, but I definitely wouldn't put the extra effort at this stage. As you rightly say, trying to hit a moving target is 'a bit' pointless. If Eric's analysis is correct - and it normally is - I've already got a fairly good idea how to correct this situation, and put all those worlds back where they belong!
Edit: bingo, it's as Eric said. Switching off the textured planets avoids the extra calls to Ranrot() and everything is where it should be. All that's needed is a Ranrot2() function just for textured terrains & clouds! One bugfix coming up, should have it ready in 2/3 hours, if I'm sneaky enough!
Good idea with the random number generator - a quick look at the code seems to indicate that Procedurally Textured Planets don't change the number of calls made between reinitialising the seed (to be more precise, the seed is saved and then restored after planet generation meaning planet generation (with or without Procedural generation) should have no impact on the random number sequence).
However, that -is- actually something which I enabled for my build of 1.72.3 (WiP) so I'll have a closer look hopefully tonight whether or not that compile-switch makes a difference, or in general whether something mucked about with random numbers between 1.72.2 and the current 1.72.3 (WiP).
[edit]Looks like Kaks beat me to it.. good hunting, Commander! [/edit]
No need for the bug report! The Ranrot() > textured planet thing might well be what's causing all this kerfuffle, & I'll have a good look at the problem this evening if noone else does between now & then...
Ok, no probs. I just didn't like to presume that you'd be the one who looked into it (or had time to do so). But if you have/will, then that's fine.
Kaks wrote:
About the trail of buoys, yes as things stand a 2nd one would be very helpful, but I definitely wouldn't put the extra effort at this stage. As you rightly say, trying to hit a moving target is 'a bit' pointless. If Eric's analysis is correct - and it normally is - I've already got a fairly good idea how to correct this situation, and put all those worlds back where they belong!
Edit: bingo, it's as Eric said. Switching off the textured planets avoids the extra calls to Ranrot() and everything is where it should be. All that's needed is a Ranrot2() function just for textured terrains & clouds! One bugfix coming up, should have it ready in 2/3 hours, if I'm sneaky enough!
I've already put the code together (it's just one more if statement conditional on the distance between the main station and the Academy, optionally performing another addShipsAtPrecisely). I'll leave it in, as from what Eric implies the Mac version 1.72.2.1 seems to have this issue too, and that's a current test release. Windows and Linux shouldn't be affected either way, and the If statement won't kick in so it's redundant coding there anyway.
.
And if so who's going to raise the bug report (or does it need one, given we're talking about WIP)?