Back to the 'stutter' for a second - it's very noticeable when moving the cursor (with the arrow keys) on F6 (it used to move smoothly).
Cannot reproduce this after a quick pair of tests and I think being on the F6 screen does not have any bearing on the issue. Assuming that the current theory that the game is waiting for a texture to complete loading is correct, the wait may just have happened while doing something on the chart screen and it could/would have happened all the same in any other screen, be it GUI or flight.
If you believe that the F6 screen could be related, please revert to a previous version and retry doing what you did before (exact same steps). Revert multiple times between previous and current version and pay attention to compare only cases where number of entities and collisions are similar, because this is also a big differentiator and a reason why precise testing is difficult in Oolite.
Back to the 'stutter' for a second - it's very noticeable when moving the cursor (with the arrow keys) on F6 (it used to move smoothly).
Cannot reproduce this after a quick pair of tests and I think being on the F6 screen does not have any bearing on the issue.
We do currently have planet texture preloading enabled, so moving the cursor around the F6 screen will set texture generation going. That should end up safely in a side thread, but maybe not all of it is...
The reference to learorce.png has me baffled as there is no such image file, nor did I bring up Learorce on the F7 screen at any time.
The exception should be fixed, which may or may not have anything to do with those beams.
Something in one of the OXPs you have has assigned a "learorce.png" texture to some planet (or maybe an ex-OXP set that texture in your save file for a planet), though.
Back to the 'stutter' for a second - it's very noticeable when moving the cursor (with the arrow keys) on F6 (it used to move smoothly).
If you believe that the F6 screen could be related, please revert to a previous version and retry doing what you did before (exact same steps). Revert multiple times between previous and current version and pay attention to compare only cases where number of entities and collisions are similar, because this is also a big differentiator and a reason why precise testing is difficult in Oolite.
For anyone using the update script in conjunction with the nightly build, (such as Cody or myself) this is not really possible..
Does the nighties server archive prior versions, or just discard them? If they were archived, it might be possible to create a reversion script. Even if only the two previous versions were retained on a rotating basis, it could prove very handy in comparison testing situations such as this.
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
The docking protocol problems are happening quite often, btw... I got mashed last night by a launching ship.
A few docking protocol bugs are fixed in a54c729, which will be part of tonight's build - ships launching while you're cleared for approach, and unexpected "no suitable launch docks" messages should both be gone, as is at least one cause of "ship stuck on approach not moving" (though there may be more than one cause of that)
A few docking protocol bugs are fixed in a54c729, which will be part of tonight's build - ships launching while you're cleared for approach, and unexpected "no suitable launch docks" messages should both be gone, as is at least one cause of "ship stuck on approach not moving" (though there may be more than one cause of that)
Thanks, Admiral - that combination had made docking somewhat tricky lately.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
Something in one of the OXPs you have has assigned a "learorce.png" texture to some planet (or maybe an ex-OXP set that texture in your save file for a planet), though.
Yes, that is quite likely the case. I'll dig through my saved game.
Guys, we seem to have too many open subjects in one thread alone. I would kindly ask that new bug reports be made in their own thread, possibly with [Trunk] included in the title so that we know that we refer to the development version. I have already moved Keeper's yaw deadzone issue to its own topic. Thanks.
I would kindly ask that new bug reports be made in their own thread...
Understood, AC.
My problem resolved as the ever brilliant Cim brought back to mind an abandoned WIP of mine that wrote several local_planetinfo_overrides to a saved game. Once the offending lines were removed, order was restored.
... ships launching while you're cleared for approach...
I just had a station launch two slow ships immediately after giving me clearance - first occasion since the fix.
I've also seen two Adders launch, take a short tour of the way-points, then return and dock - not seen that for a while either.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
I haven't managed much flight time this week, but I got out there tonight - and had a CTD. Running the usual set of OXPs, with test OXPs disabled. I'd been wanting the chance to follow one of the 'elusive taunters' again, and tonight I found one - but as I was about to dive into its wormhole cloud, the CTD happened.
I have had a little trouble with gfx drivers over the past week, but it didn't feel as if it was related to that.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
22:50:34.258 [plist.parse.failed]: Failed to parse C:\Oolite-New/oolite/oolite.app/GNUstep/Library/Caches/org.aegidian.oolite/Oolite-download.plist as a property list.
Parse failed at line 282 (char 10387) - unexpected character (wanted ';' or '}')
22:50:34.260 [oxz.manager.error]: Downloaded manifest was not a valid plist, has been left in C:\Oolite-New/oolite/oolite.app/GNUstep/Library/Caches/org.aegidian.oolite/Oolite-download.plist
I think this is a problem with the plist not the build though...
Yup. The line that kills it is this: file_size = 168,938;
The comma is the culrprit. And the identifier of the OXZ is: identifier = "oolite.oxp.Diziet.Q-Bomb-Detector";
I also note in your screenshot that the string [oolite-oxzmanager-update-list] does not get expanded to "Update expansions list".
Yup. The line that kills it is this: file_size = 168,938;
The comma is the culrprit. And the identifier of the OXZ is: identifier = "oolite.oxp.Diziet.Q-Bomb-Detector";
Oops..
I should fix, yes?
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
![[EliteWiki]](/images/elitewikismall.png){kind=small}
New Cargoes
