Trunk nightly

[Norby]

The ship.checkScanner(true) return the same list as with false: all objects, not just the powered ships. Moreover wormholes are not listed at all.

[cim]

The ship.checkScanner(true) return the same list as with false: all objects, not just the powered ships. Moreover wormholes are not listed at all.

Thanks - fixed the true/false issue.

Wormholes not being listed is intentional - it's a convenience function to avoid inefficient iteration over system.allShips at the potential cost of accuracy in extremely busy environments. You can iterate over system.wormholes quickly enough anyway, in any vaguely normal situation.

(Also included NSDate.h - we'll see if this helps)

[Getafix]

...The solution should be simply including NSDate.h in the manager class...

...then again...maybe not...


Managed to meet with a_c and investigated the case.
The issue is that gnustep-base 1.20.1, used in both Windows and Linux builds, supports neither setDateFormat nor stringFromDate.

Temporarily patching the code as follows (this is how you catch-up with "long time no see" friends?!?... with ad-hoc dev-parties?!? )

Code: Select all

			NSString *updatedDesc = nil;

			NSUInteger timestamp = [manifest oo_unsignedIntegerForKey:kOOManifestUploadDate defaultValue:0];
			if (timestamp > 0)
			{
				// list of installable OXZs
				NSDate *updated = [NSDate dateWithTimeIntervalSince1970:timestamp];
			
				// NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
				// [dateFormatter setDateFormat:@"yyyy-MM-dd"];
				// updatedDesc = [dateFormatter stringFromDate:updated];
				updatedDesc = [updated description];
				
				// [dateFormatter release];
				[gui setArray:[NSArray arrayWithObjects:DESC(@"oolite-oxzmanager-infoline-size"),[self humanSize:size],DESC(@"oolite-oxzmanager-infoline-date"),updatedDesc,nil] forRow:OXZ_GUI_ROW_LISTINFO2];
			} 

resulted to the following, that is of course at least functional but still needs some string formatting tweaking...


For both Windows and Linux, the "Last update: " value follows the user's O/S timezone setting.
As soon as we saw this, the following question popped-up: What was the behavior that cim was looking in the first place; use the user's timezone or not?

...and this is where we said goodbye to each other... our spare time was up!

[cim]

The issue is that gnustep-base 1.20.1, used in both Windows and Linux builds, supports neither setDateFormat nor stringFromDate.

Pity. That would have been quite useful.

As soon as we saw this, the following question popped-up: What was the behavior that cim was looking in the first place; use the user's timezone or not?

When it works ... date only, no time or timezone at all. Having the date be localised is fine, but printing the time/TZ isn't ideal.

[Getafix]

When it works ... date only, no time or timezone at all. Having the date be localised is fine, but printing the time/TZ isn't ideal.

It was clear from your code that the final format needed was yyyy-mm-dd.
This was just a quick and dirty hack to have a proof of concept that the issue is only in this small chunk of code.

The question was actually for the localized date and you already answered. Cheers!

[Cody]

Another one of these:

Code: Select all

01:07:49.930 [script.javaScript.exception.ooliteDefined]: ***** JavaScript exception (Oolite Escort AI 1.81): Error: Ship.removeDefenseTarget: Invalid arguments ([Wormhole destination: Qudior ttl: 48.47s arrival: 2089849:12:05:33]) -- expected target.
01:07:49.930 [script.javaScript.exception.ooliteDefined]:       Resources/Scripts/oolite-priorityai.js, line 4017.

[cim]

Another one of these:

Thanks. That (and several similar ones) should now be fixed.

[Cody]

Just seen a Viper warning an Icosahedron station that it was breaking GalCop law.

Icosahedron Station, you are in breach of Cooperative law. Leave the system or be destroyed.

It was chaotic though - seemed to be two groups of escorts tangling with each other.

[cim]

There does seem to be a mechanism where a station could get given a bounty in particular circumstances, which would then cause the Vipers to attack it. I'll see what I can do to fix it.

[Vincentz]

Sorry if this has been posted before, but I get a CTD when changing filter settings for commodities during flight.

[Cody]

Confirmed (and nothing in the log).

[cim]

Thanks. Should be fixed in tonight's build.

[Norby]

When I updated the expansion list and pressed "f" then "u" to see the packages need update then I have not get the newest one (Random Player/Ship Name) just the older updates. But when I pressed the second menu item then the newest appeared. A repeated update hide it again then the list menu show it again.

Maybe related that this OXP is listed in gray color in the full list and tell "Status: incompatible with this version of Oolite", which is not true, nor in the case of other gray ones in the list.

[cim]

Here's the currently recorded manifest for that OXP in the AddOns manager.

Code: Select all

{
	"identifier" = "oolite.oxp.spara.random_player-ship_name";
	"required_oolite_version" = "1.80";
	"title" = "Random Player/Ship Name";
	"version" = "1.0.1";
	"category" = "Ambience";
	"description" = "Add random pilot and random ship names to the ship registration interface. More variation to random ship names can be added with Random Ship Names OXP.";
	"download_url" = "http://wiki.alioth.net/img_auth.php/2/2f/Random_player_1.0.1.oxz";
	"author" = "spara";
	"file_size" = "98710";
	"information_url" = "http://wiki.alioth.net/index.php/Random_Player/Ship_Name";
	"license" = "CC-BY-NC-SA 4.0";
	"maximum_oolite_version" = "1.79";
	"upload_date" = "1430038853";
}

Required to install is >= 1.80 and <= 1.79, which probably explains the odd behaviour.

[Norby]

Required to install is >= 1.80 and <= 1.79, which probably explains the odd behaviour.

Which is probably caused by the admin page where max. 1.79 is the default setting, so I suggest to change the default to unlimited.