I get a "Unspported Browser" message, but only after the page has loaded all fine.
Probably because of the mobile.
(shocking, I think I never got this with Opera before. That a site refuses to at least try to display, not just an error message.)
mcarans wrote:
I've been playing with a non-linear sensitivity on the XBox 360 controller axis using xboxdrv (I don't use the Oolite built in button mapping to double sensitivity).
However, when targets are far away, I still find that v small stick movement produces 0 movement then on increasing the deflection of the stick slightly, there will at some point be a sudden jump not the gradual increase I'm looking for. I'm not sure if this is a product of the stick or Oolite, but I'll keep experimenting.
Are you playing at low framerates ?
I always blame this on my poor PC / the low framerates; the minimum rotational movement step seems to be angular frequency divided by framerate.
So the more manoeuverable your ship, the stronger the "jumping" cursor effect.
this is however belief, not knowlesge.
Last edited by snork on Wed Aug 11, 2010 7:25 pm, edited 4 times in total.
Second bug report, I'm afraid.
The first link just took me to a page telling me to use another browser and the second takes me to what amounts to a blank page...
Will update the Wiki page that suggested the capital E now...
The page never suggested a capital E, but clearly gives the correct name in the very first sentence. I've highlighted it now, but I don't see the need to insert another disclaimer in front of that.
Will update the Wiki page that suggested the capital E now...
The page never suggested a capital E, but clearly gives the correct name in the very first sentence. I've highlighted it now, but I don't see the need to insert another disclaimer in front of that.
Fair enough. Missed that in the heat of the battle with the beer cooler.
Didn't think it was major enough, but it's there now. Additional testimonials on its wiki page welcome
I hope you don't mind but I added a Max Version because that's how we will tell in the future if the OXP is being maintained - if that Max Version is not updated, then a reasonable assumption is that you are not maintaining the OXP any more (and someone else could take over if they wanted to and test that it still works).
Didn't think it was major enough, but it's there now. Additional testimonials on its wiki page welcome
I hope you don't mind but I added a Max Version because that's how we will tell in the future if the OXP is being maintained - if that Max Version is not updated, then a reasonable assumption is that you are not maintaining the OXP any more (and someone else could take over if they wanted to and test that it still works).
Oh ok, I misunderstood "max version" as the maximum version the OXP will work with. As there is no known reason that the OXP would not work with 1.74.3 or whatever comes next I left it empty.
And unless you're the one who's going to maintain the table rather than the OXP maker, it may help to get the data right?
For example all of my current OXPs will max out at 1.74.99 not 1.74.2 as listed. And that's only to give pause to the bug reports from people using trunk who possibly shouldn't be and are reporting bugs in OXPs that are actually bugs (or glitches or tests or features) in trunk.
Oh and Gates and Fuel Station maybe shouldn't be dockables, as you can't dock with them, only fly through them
I don't think the Max Version field should be left blank, because what happens when some new version comes along and deprecates lots of stuff? How will we tell if the OXP has been upgraded to work or not?
I think that we need a field that should be updated with each significant version change of Oolite. I have not been playing Oolite long enough to know if an update from 1.74.2 to 1.74.3 could break lots of stuff or not - my initial assumption was that it could, but if it is only the change from 1.74 to 1.75 that will likely break things, then putting 1.74.x as Max Version would be suitable. If even 1.74 to 1.75 is a minor change, then 1.7x would be suitable. Please can someone say what constitutes a major version change.
I would recommend that OXP authors correct any entries I have got wrong. I have PMed Ahruman to ask if its possible to have the OXP categories pages made world writable so people don't have to log in to edit those pages, but I guess he might be away as I've had no response.
Depreciations are in the 1.7x changes (usually), with the 1.74.x changes usually being bugfixes and/or introduction of new features.
You'll be very unlucky to have something work in 1.74.2 that doesn't in 1.74.3 for example, unless of course it relied on something that was broken (ie working but not as planned) and then fixed. But it's quite possible that something that needs a feature in 1.74.3 won't work in 1.74.2.
I would agree with Kaks though, any information in the table should specifically reflect the required.plist file information in the OXP. If no file is present, then no min or max should be in the table, and if only min is in the file (or only max, but I don't recall ever seeing that) then only that data should be there. And it should be correct! (see my previous post).
And as an OXP author I'd prefer it if once and for all it's decided what the table formats etc are going to be. Currently we have several and it's getting rather a pain to have to keep updating (and correcting) so many of the things
I would agree with Kaks though, any information in the table should specifically reflect the required.plist file information in the OXP. If no file is present, then no min or max should be in the table, and if only min is in the file (or only max, but I don't recall ever seeing that) then only that data should be there. And it should be correct! (see my previous post).
While I'm sure that you set min and max version in the required.plist correctly, I would not be surprised if other authors don't set it or maybe don't even know about it.
Thargoid wrote:
And as an OXP author I'd prefer it if once and for all it's decided what the table formats etc are going to be. Currently we have several and it's getting rather a pain to have to keep updating (and correcting) so many of the things
Since the number of flames I have received has reduced dramatically, it appears people are reasonably happy with the new OXP pages.
The only issue remaining is the max version. So if we can resolve this, that should settle the matter I hope. Let me pose the problem by asking 2 questions:
1. If as a newbie, you were looking at OXPs on the wiki, how would you tell if they work with the current Oolite version?
2. If the author of an OXP has vanished, how can we tell from the wiki that his/her OXP is not being maintained (so we could eventually remove it or someone else could take over developing it)?
Since the number of flames I have received has reduced dramatically, it appears people are reasonably happy with the new OXP pages.
Silence != Assent. Some of us are just waiting the 2-3 month period before the next person comes along and decides to remake the tables. Or add new versions.
mcarans wrote:
2. If the author of an OXP has vanished, how can we tell from the wiki that his/her OXP is not being maintained (so we could eventually remove it or someone else could take over developing it)?
Keep in mind, taking over someone else's OXP is a very grey area unless they have given specific permission to do so, or their license states that such is possible. Hence why I put a "Dead Man's Switch" clause in my OXPs' licenses.
The only issue remaining is the max version. So if we can resolve this, that should settle the matter I hope. Let me pose the problem by asking 2 questions:
1. If as a newbie, you were looking at OXPs on the wiki, how would you tell if they work with the current Oolite version?
2. If the author of an OXP has vanished, how can we tell from the wiki that his/her OXP is not being maintained (so we could eventually remove it or someone else could take over developing it)?
Speaking for my own OXPs:
1) Look on my wiki page, or the wiki page of the OXPs themselves, where it lists which Oolite versions they work with.
2) Look in the documentation in the zip file of the OXP, where likewise it states.
3) Try and run them. They all have a required.plist in them which will prevent them running with Oolite versions with which they are either incompatible or untested.
As for anyone elses OXPs, they aren't my responsibility, although I know of a number of my fellow authors who do similar documentation and/or plist settings.
As to orphaned OXPs, this arguably is a reason not to host them on the wiki itself but on personal space like box.net. If the author vanishes, then usually after a period of time then the OXPs will as well as their hosting site expires. Or conversely something like OXPCentral.net works for it, as it's explicitly designed from the ground-up to be a proper hosting environment, which a wiki frankly isn't.
But I'm getting deja-vu from this kind of discussion with the last person who wanted to redesign the tables etc, and whilst your aims are laudable, it's getting a tad repetitive, nor to mention frustrating (it's a pain to have to maintain wiki pages, let alone several lists of closely duplicate functionality). Ergo from now onward I'm just going to update my OXP pages and the main list, and if anyone else wants to do their own lists etc then they can deal with adding and updating the details.
That a site refuses to at least try to display, not just an error message.)
