Page 45 of 138

Posted: Sun Jun 27, 2010 8:23 pm
by Eric Walch
I noticed the macro time is not yet part of trunk. But you can easy add it to your macros by typing in the console:

Code: Select all

:setM time console.profile(function() { eval(PARAM) })
After that the :time works as advertised in the previous messages

Posted: Sun Jun 27, 2010 8:34 pm
by JensAyton
Actually, it was checked in on the 15th of June. The issue is that macros in debugConfig.plist aren’t merged with the ones in preferences like they should be.

I suggest using the following canonical definition of :time, which doesn’t include the overhead of compiling your expression in the profile:

Code: Select all

:setM time eval("this._profileFunc = function() { " + PARAM + " };"); console.profile(this._profileFunc, this);

Posted: Sun Jun 27, 2010 8:54 pm
by Eric Walch
Thanks. Works perfect. Very interesting to get a feeling how long commands take.

console.profile(function() { system.countShipsWithPrimaryRole("pirate") })

Code: Select all

Total time: 0.079941 ms
JavaScript: 0.012788 ms, native: 0.067153 ms
console.profile(function() { system.shipsWithPrimaryRole("pirate") })

Code: Select all

Total time: 15.7563 ms
JavaScript: 0.010835 ms, native: 15.7455 ms
console.profile(function() { system.filteredEntities(this, function(entity) { return entity.isShip && entity.isPirateVictim}) })

Code: Select all

Total time: 20.4347 ms
JavaScript: 6.41403 ms, native: 14.0207 ms
Just counting pirates is much faster than creating an array of them. The difference is much greater than I would have thought. And I thought that a filtered entities with isPirateVictim would take much longer than isPirate because there are many more strings to compare. To my surprise both were just as fast. (At least the native time. JS has something to do in the last one)

Posted: Sun Jun 27, 2010 9:03 pm
by JensAyton
Odd, here the last one takes four times as long native – and that’s counting the JSFunctionPredicate line as non-native.

Posted: Mon Jun 28, 2010 12:04 am
by JensAyton
A handful of oddly interrelated JavaScript changes:
  • Mission variable names may no longer begin or end with underscores.
  • Script names may no longer begin or end with underscores or whitespace.
  • The call() debug method has been renamed callObjC() for clarity, and to avoid confusion with the completely different, standard Function.call() method.
  • The debug OXP no longer pollutes all objects with “call” (or “callObjC”) and “inspect” properties visible to for (x in y) iteration.
  • for (x in y) iteration now works on missionVariables.

Posted: Mon Jun 28, 2010 9:15 am
by JensAyton
All JavaScript class reference pages are now up-to-date for 1.74 (and 1.74.1). I don’t take any responsibility for other types of reference pages.

All information about deprecated properties has been removed, as has information about when properties were added for versions earlier than 1.74. If you feel some strange urge to target obsolete test releases, the old versions are there in the page histories.

Posted: Mon Jun 28, 2010 1:15 pm
by JensAyton
The Materials in Oolite documentation is now up to date.

Posted: Wed Jul 28, 2010 3:04 pm
by JensAyton
When the player enters a post-nova system, two groups of asteroids are spawned to represent debris of explodificated planets. Previously, these were susceptible to overheating at the usual rate, which meant the player always arrived just in time to see the last debris burn up. As of r3728, the spawned debris instead uses a new standard role, “cinder”. The default cinder objects are like_ship copies of standard asteroids and boulders with their heat_insulation set to 10000:

Code: Select all

"oolite-cinder" =
{
    roles = "cinder";
    like_ship = "asteroid";
    heat_insulation = 10000;
};
Since a separate role is used for this rather than manipulating normal asteroids, OXP-defined asteroids which don’t replace the standard ones won’t be used as cinders, unless the OXP is updated.

Additionally, the heat_insulation for normal asteroids has been raised to 5, and for boulders to 3.

Posted: Wed Aug 04, 2010 10:57 pm
by DaddyHoggy
That's a very simple and therefore a very "cool" fix - nice one Ahruman.

Posted: Sun Sep 19, 2010 10:07 am
by Eric Walch
Today I addd a size check for docking/launching ships to trunk. This should prevent the buggy behavior of oversized ships squeezing through the docking slot. Although its in the first place an oxp error of assigning wrong roles, I think the core game should also try to prevent this.

Ships that ask docking permission with the docking computer and are to big, are now denied permission. When using the "dockingAI.plist" to dock, this AI will return to the original AI with a message: "DOCKING_REFUSED". When a trader ship receives this message it will go sunskimming instead.

Ships that are in the launch queue and are too big are just removed before launch. The player won't see any evidence, but the fact is logged so oxp developers do know there is a problem with the ships size.

The check is very strict: there is no margin to allow for just a little to big. Ships that are just 1 meter to big will be denied by the station, even when 1 meter to big does not show by sight.

I have been using it now for 3 months on my computer without problems. There are only very few ships around that are just a bit to big. In Griffs ships set there were two, but Griff already fixed that 3 months ago. The buoy tugger in buoy repair it also just to big. We knew this already on the initial release, but now have a good reason to fix that in a future release. (Currently the tugger always sustains energy damage during docking because it is oversized)

This feature should not affect player ships that are to big, unless the docking computer is used.

-----

A new AI command "thargonCheckMother" is added in trunk to replace the current check for mother ship. By using this new command it will become more rare that the drones lose control in a crowded sky when there is still a mothership in range.

Posted: Sun Sep 19, 2010 11:55 am
by Zieman
Aww, shucks :P.

There goes the fun of making a Baakili super-dense, trying to dock and blow up hurling the station to Solar orbit ... :D

Posted: Sat Dec 18, 2010 3:18 pm
by JensAyton
Joysticks and analogue game pads are now supported under Mac OS X (10.5 and later). (Contributed by Alex Smith)

Posted: Sat Dec 18, 2010 4:35 pm
by Rxke
Wow, that's pretty big news for a lot of people! 8)

Posted: Sat Dec 18, 2010 7:03 pm
by DaddyHoggy
I don't have a Mac and even I'm pleased (on behalf of Joystick free Mac users)

Posted: Sun Dec 19, 2010 1:55 pm
by JensAyton
Before:
Image

After:
Image