Moderators: winston, another_commander, Getafix
Really? Could it be that you misinterpreted the deprecation warnings as errors?johnt wrote:Thanks, It works a treat. Downloaded the latest svn, built latest trunk and ran... "oops, to many errors with oxp's". Built latest 1.73 branch and all is sweet.
It looks like you're somehow missing some files there...johnt wrote:I don't know if these qualify as errors but here is my log...
are these fixable?
Code: Select all
[script.javaScript.warning.ooliteDefinedError]: ----- JavaScript warning ("vector" 1.3): Mission.choice is deprecated and will be removed in a future version of Oolite.
The actual files contained inside the Resources directory do change between Oolite versions, so to run Oolite trunk correctly, you need to copy the Resources directory across too. The .dll files aren't guaranteed to stay the same either, but we didn't need to change them for trunk - yet!johnt wrote:Hi Screet,
Yep, I built the latest trunk and then I copied everything under the oolite.app directory to my newly created c:\oolite directory. I then added the addon directory with all my oxp's. Since the oolite.app directory contains a resource directory with all the resources in it I thought that it would be okay. Maybe I haven't understood the process correctly. Do I actually have to build a installer?
Doing it that way (without the installer) may work with the executable only. With you also copying all the other files manually, I think it should work, but your log somehow says that it's got a problem there.johnt wrote:Yep, I built the latest trunk and then I copied everything under the oolite.app directory to my newly created c:\oolite directory. I then added the addon directory with all my oxp's. Since the oolite.app directory contains a resource directory with all the resources in it I thought that it would be okay. Maybe I haven't understood the process correctly. Do I actually have to build a installer?
I already started translating a bit of my code for trunk here. For me it did cut down most deprecation warnings so the real errors better stand out.Screet wrote:For me, using trunk with an immense amount of oxps I do virtually only get such warnings:Which means that it's still working that way but trying to notify the user that this support will be dropped some time soon.Code: Select all
[script.javaScript.warning.ooliteDefinedError]: ----- JavaScript warning ("vector" 1.3): Mission.choice is deprecated and will be removed in a future version of Oolite.
Incidentally, with the new planet code this is 336 bytes… although there’s an additional 366 KiB of static data, and two smaller associated objects (84 bytes each). In the old code, a planet with an atmosphere is actually two 1139496-byte objects. </preen>johnt wrote:Okay, I have down loaded the latest nightly trunk build and applied all the oxp's. This is much improved with only 3 error locations left. trying to search oolite bulletins for answers.... (Continued thanks to all of you)
…
[size.dump]: OOPlanetEntity: 1139496 bytes
These appear to be intentional and are basically harmless. The error message can be suppressed by adding is_tempate = yes; to the relevant shipdata.plist entries. (I don’t know offhand what OXP this is from, but clearly it involves stations.)johnt wrote:[shipData.load.begin]: Loading ship data...
[shipData.load.error]: ***** ERROR: the shipdata.plist entry "PAGroove-icosahedron-reference" specifies no model.
[shipData.load.error]: ***** ERROR: the shipdata.plist entry "PAGroove-dodecahedron-reference" specifies no model.
[shipData.load.error]: ***** ERROR: the shipdata.plist entry "PAGroove-coriolis-reference" specifies no model.
Well, like it says, “What” shouldn’t be in junkAI.plist. I don’t know where that comes from, and its very badly-chosen name gives no clue.johnt wrote:[ai.unpermittedMethod]: Handler "INCOMING_MISSILE" for state "AVOID_HAZARD_POINT2" in AI "junkAI.plist" uses "What", which is not a permitted AI method. In a future version of Oolite, this method will be removed from the handler. If you believe the handler should be a permitted method, please report it to [email protected].
Someone appears to have confused ship roles with shipdata keys. <system script_actions> means it’s a script from a system dictionary in planetinfo.plist.johnt wrote:[script.addShips.failed]: ***** SCRIPT ERROR: in "<system script_actions>", addShipsAt: could not add 1 ships with role "krait"
Oh yes. I was going to reintroduce those. (General note: it’s a bad idea to rely on specific models in Oolite, use like_ship instead.)johnt wrote:Started introducing oxp's one at a time. It seems that some oxp's require models such as cobra3_redux1.dat, python_redux1.dat, python_redux2.dat
etc. After investigation found that these models where in the 1.73.4 branch but not in the trunk.
WHAT???johnt wrote:Started introducing oxp's one at a time. It seems that some oxp's require models such as cobra3_redux1.dat, python_redux1.dat, python_redux2.dat
etc. After investigation found that these models where in the 1.73.4 branch but not in the trunk.