[Release] RandomHits 1.7.1

[Eric Walch]

(Mission offer on dock should probably move to an interface screen anyway, of course)

For random Hits, it is just a matter of commenting one line out, to avoid the hit offers on docking. To be more precicely, without the line (around line 170), you only can enter the hitpages through the interface screen.:

Code: Select all

this.showScreen = "firstPage"; // default page (used, unless there were pending messages).

But I noticed that during the "this.startUp" handler, the station is the main station, even when loading a game saved at a seedy bar. This handler should be the place for a script to check were he is at the start in my opinion. At least it was my first choice to check were I started, but it did't work for a saved-bar-game.

[cim]

But I noticed that during the "this.startUp" handler, the station is the main station, even when loading a game saved at a seedy bar. This should be the place for a script to check were he is at the start in my opinion.

This is unfortunately unavoidable. You can't move the player to their saved station until it's there. It won't be there until the populator function has run. You have to complete startUp before the populator runs so that worldscripts have somewhere to do necessary initialisation.

There is, however, a new startUpComplete handler which runs after the populator and after the player has been placed in the correct station.

Hmm. It would have been useful if I'd documented that... {goes to fix}

[Eric Walch]

There is, however, a new startUpComplete handler which runs after the populator and after the player has been placed in the correct station.

I did check if there were new handlers I could use for this check.

And this works. It detects being in the bar correct and adds the interface screen for the hitpages now. But it still doesn't do nothing, so the script probably needs more things to set instead of just calling the ShipDockedWithStation handler to make it work correctly without launching first. So I have some work to do.

@Thargoid: Yes it is big now. Was big already though. I downloaded it from the new http://addons.oolite.org/ pages so no hickups in Oolite itself. But I have a connection of 11 MByte/sec, so 108 MB takes here about 10 seconds downloadtime.

[Thargoid]

@Thargoid: Yes it is big now. Was big already though. I downloaded it from the new http://addons.oolite.org/ pages so no hickups in Oolite itself. But I have a connection of 11 MByte/sec, so 108 MB takes here about 10 seconds downloadtime.

I think it's my machine (which is low spec) rather than the download speed itself. I can manually download the file in about 30-40s (not quite as quick as you ), but if I try to do it in-game then things become non-responsive. But it takes a couple of minutes for the game to start-up (after a trunk build), hence the thought about it being the machine.

As I said I'm just concerned that such delays may put newer players with similar low-spec machines off either the OXZ or the whole game.

[spara]

But it still doesn't do nothing, so the script probably needs more things to set instead of just calling the ShipDockedWithStation handler to make it work correctly without launching first. So I have some work to do.

If I'm not totally mistaken, you'll need to set this.random_hits_docked = true after calling this.shipDockedWithStation(). That's how I got it to work. I was not aware of the ShipDockedWithStation handler, so I did it with guiScreenChanged . Are you doing this change? It's your code after all and you'll be more likely to take better account of things than I.

About the size. Maybe the extension manager could show some warning when the size is over some limit? With 1.79 it's also possible to chop the oxp into core + additional ship sets. That would naturally require some rewriting of the code.

[cim]

If we find there's consistent problems downloading above particular sizes, it could warn, though it does already give the download size on the install list.

[Thargoid]

About the size. Maybe the extension manager could show some warning when the size is over some limit? With 1.79 it's also possible to chop the oxp into core + additional ship sets. That would naturally require some rewriting of the code.

You can do it without re-writing anything, just packaging things up differently. Just split it into multiple OXZs (say a core one plus one or more shipset ones) and make each OXZ require all of the others. Then once loaded nothing has changed, but you can download them in smaller chunks rather than all at once.

If you really want to be complete, then have both options - a single large OXZ and the smaller chunk group which require all of the others in the group. Just make the large one conflict with each of the group ones, and the group ones individually conflict with the large one. Means more work to maintain, but then people could do it either way as suited them.

[spara]

You can do it without re-writing anything, just packaging things up differently. Just split it into multiple OXZs (say a core one plus one or more shipset ones) and make each OXZ require all of the others. Then once loaded nothing has changed, but you can download them in smaller chunks rather than all at once.

True. I was thinking something more ambitious. There could be a core package that would function on its own and then you could mix and match ship packages with it. But that's probably pointless as most users will most likely just load 'em all.

Actually splitting the textures into smaller packages and scripts into another package would be a good idea. Then a small update in the script would not require one to download the whole package.

[Eric Walch]

If I'm not totally mistaken, you'll need to set this.random_hits_docked = true after calling this.shipDockedWithStation(). That's how I got it to work.

Yep, that should work. I had missed that because it is set in the ship script. I now added:

Code: Select all

this.startUpComplete = function (){
    if (player.ship.docked && player.ship.dockedStation.name === "A Seedy Space Bar"){
        this.shipDockedWithStation();
        this.random_hits_docked = true;
    }
};

And now the leaderboard can be accessed after loading the game without launching first. It is better you upload it as I can't edit the manifest you started.

-------
Off-topic:
I had the AddOns folder in my personal cloud (Synology Nas in my LAN). With the new system I also put the Mannaged_AddOns in the cloud, so every change I make to an oxp in the addOns or the Mannaged_AddOns is synchronised between my 3 macs.
I wonderd if this would work for the managed oxz's, but I see no complains. (Only a message that there is a mismatch between installed and available oxz's)
So every mac uses the same oxp set and the same saved games.

[cim]

Just make the large one conflict with each of the group ones, and the group ones individually conflict with the large one.

I would advise in this case just having the group ones conflict with the large one (or the other way round, if you think that's easier to maintain). Otherwise you may end up with a case where the dependency check order is:

"component one"
"monolithic"
"component two"

"component one" rules itself out because it sees "monolithic", and then "monolithic" rules itself out because it sees "component two". "component one" doesn't get re-checked at this point, however, so then "component two" rules itself out because it doesn't have "component one" which it requires.


As far as separating goes ... I wouldn't generally advise it unless:

• You have a clear separation of functionality between components so you can usefully install only some (e.g. "Povray Planets" or "Your Ad Here!")
• You want to separate assets and config (e.g. "Griff's Shipset"), because you expect the config to change more frequently than the assets and don't want to force a redownload of the assets every time, or because you want to have multiple configs for the same assets - in that case, the config should depend on the assets, and the assets could add the config(s) to their optional list

Remember that people can still download and install an OXZ file with a web browser and drop it into their AddOns folder and it's still a bit easier - except on a Mac - than using the OXP format. If the OXZ manager has problems with large files, and they aren't fixable, that might be a better workaround. (If you try it, you'll see that the OXZ manager then highlights that OXZ red for "manual install" but still shows you if new versions are available)

Maybe if I get round to adding a bit more dependency helpfulness to the OXZ manager - you install an OXP and if after downloading the dependencies aren't met it offers to go and fetch them right then - it might matter less, but there are tricky things to adding that sort of extra functionality, so not for 1.80.

[Diziet Sma]

I'm wondering how much of this download difficulty is due to the download method Oolite uses, and also perhaps the Wiki software involved.

It's well known that some download methods and protocols are quite aggressive about continuing a download over a flaky connection, whereas others will give up quite easily if a connection is lost/dropped or times out. If the internet connection is poor, or internet conditions unstable, as happens now and then, a large download is much more likely to exhibit such problems.

Ideally, I'd like to see Oolite using FTP for downloads, rather than HTTP. FTP was designed from the ground up with bad connections in mind.

[maik]

I'm wondering how much of this download difficulty is due to the download method Oolite uses, and also perhaps the Wiki software involved.

I was wondering the same regarding the wiki, however Thargoid mentioned

I can manually download the file in about 30-40s (not quite as quick as you ), but if I try to do it in-game then things become non-responsive.

[Diziet Sma]

Which would tend to suggest that it's Oolite that isn't coping well with less-than-ideal conditions.

On the other hand, how well does the Wiki software and server cope with multiple simultaneous large downloads going on? If a number of large downloads are going on at once, as may well happen after a new release of a popular OXZ, are some connections timing out, perhaps, as the server struggles to serve all requests in a timely fashion?

Server load could have dropped considerably in the time between Thargoid trying to download via the OXZ Manager, and downloading via his browser.

[maik]

On the other hand, how well does the Wiki software and server cope with multiple simultaneous large downloads going on? If a number of large downloads are going on at once, as may well happen after a new release of a popular OXZ, are some connections timing out, perhaps, as the server struggles to serve all requests in a timely fashion?

Good question. I don't know the server's specs off the top of my head but I recall they were mentioned on the BB after a server switch took place. It wasn't too shabby though. I'd be surprised if it wouldn't be able to answer hundreds of parallel download requests, which seems absurdly high.

Server load could have dropped considerably in the time between Thargoid trying to download via the OXZ Manager, and downloading via his browser.

That can be easily tested by repeating it a few times.

[Diziet Sma]

Good question. I don't know the server's specs off the top of my head but I recall they were mentioned on the BB after a server switch took place. It wasn't too shabby though. I'd be surprised if it wouldn't be able to answer hundreds of parallel download requests, which seems absurdly high.

I'm inclined to agree, particularly as it appears to be on a dedicated server, and not shared hosting. It ought to be able to cope with anything (legitimately) thrown at it.