SRL Archive - News and General

EDIT: Due to some problems with the file size this will be delayed.

Woo!

So this will be automatically installed when updating SRL?

Great! I'll use this before my DDTM walking now :P But I'll keep that as a backup.

From: Flight
So this will be automatically installed when updating SRL?

Yes, although I'm not sure if you will have to move the plugin manually.
I don't know how Simba updater handles those.

When I tried it out, it walked perfectly fine but once it arrived at the destination, it wanted to go there again, and again, and again until spitting out an endless loop of…

[ERROR] GATHERMINIMAP:: Exception: Access violation
[SPS] Did not gather Minimap.

Nvm, my bad. I didn't see that WalkPath also did flagging already.

Is there any way to reduce the size of the 104 MB world map or those chunks? It's really bad that the SRL4 git repo is 120+ MBs now (with the Simba auto-updater people will have to download ALL those files every time).

Looks cool though, just wish it was smaller.

What the fuck?

~/Programs/srl-opendev/SRL/core/SPS $ du -sh .
226M    .

Does SPS require all these bitmaps? I'm going to have to revert these commits before we blow away the SRL server until we find a better solution.

Why wasn't this discussed in the first place?

E: Reverted until we find a solution.

From: Wizzup?
What the fuck?

~/Programs/srl-opendev/SRL/core/SPS $ du -sh .
226M    .

Does SPS require all these bitmaps? I'm going to have to revert these commits before we blow away the SRL server until we find a better solution.

Why wasn't this discussed in the first place?

Umm this has been open for discussion for weeks. I've made several threads about this.
You have even replied to the one in Public SVN?

Is the size really that big a problem? No-one has said that it'd be a problem until now?
Nava2, saturn, zeph, Coh3n etc. nobody has mentioned that large bitmaps in the repository would be a problem?

And no, there is no way to do this otherwise.

From: marpis
Umm this has been open for discussion for weeks. I've made several threads about this.

Is the size really that big a problem?

200MB is quite the problem. That's like SRL 200 times.

I didn't see a thread were you discussed adding this to SRL, including 200MB in bitmaps…

Can't you make it so it just downloads the segments you need? For example, I needed only part (9_5) for my script but I have the lot of them. Seems a bit redundant, no?

From: Wizzup?
200MB is quite the problem. That's like SRL 200 times.

I didn't see a thread were you discussed adding this to SRL, including 200MB in bitmaps…

This is in the Public SVN, which implies I was going to upload it to SRL.
http://villavu.com/forum/showthread.php?t=62286

From: Wizzup?
There?

This is in the dev section:
http://villavu.com/forum/showthread.php?t=61804
I've mentioned in the very first post that there will be many bitmaps with 100% zoom from the RS worldmap. You also have replied to this thread.

You really can't say this hasn't been open for discussion.


—-

From: Floor66
Can't you make it so it just downloads the segments you need? For example, I needed only part (9_5) for my script but I have the lot of them. Seems a bit redundant, no?

That wouldn't be practical at all in the end. Most of us want to use many scripts, in many locations.

From: marpis
This is in the Public SVN, which implies I was going to upload it to SRL.
http://villavu.com/forum/showthread.php?t=62286


This is in the dev section:
http://villavu.com/forum/showthread.php?t=61804
I've mentioned in the very first post that there will be many bitmaps with 100% zoom from the RS worldmap. You also have replied to this thread.

You really can't say this hasn't been open for discussion.


—-

I read the threads again and I still don't see a fat huge warning saying that it will download over 200MB in bitmaps. Really, I don't want to argue over whether we discussed this enough but this comes to quite a surprise to me. You have to realise that every commit people will need to redownload over 200MB (5 users = 1GB, 500 users = 100GB, about 5 commits per month = a lot of GB) because of SPS. To work around this, I'll have to update my server side scripts as well as the Simba SRL extension which doesn't automatically update itself. I think you're simply not seeing how many troubles this causes. I like the project but we'll need to release this with again with more care. If you want to distribute it now I suggest you just re-add the SPS Simba file to the SRL repository (put it in misc, btw) and upload the bitmaps elsewhere. Also, as far as I know, Simba can load .png files too, which should already be significantly smaller. If you want I can convert them all to lossless png's this evening.

It could downlad the map from runescape.com and cut it into pieces itself.

If pascal doesn't have the functionality, you could use java, maybe it does.

From: Wizzup?
I read the threads again and I still don't see a fat huge warning saying that it will download over 200MB in bitmaps. Really, I don't want to argue over whether we discussed this enough but this comes to quite a surprise to me. You have to realise that every commit people will need to redownload over 200MB (5 users = 1GB, 500 users = 100GB, about 5 commits per month = a lot of GB) because of SPS. To work around this, I'll have to update my server side scripts as well as the Simba SRL extension which doesn't automatically update itself. I think you're simply not seeing how many troubles this causes. I like the project but we'll need to release this with again with more care. If you want to distribute it now I suggest you just re-add the SPS Simba file to the SRL repository (put it in misc, btw) and upload the bitmaps elsewhere. Also, as far as I know, Simba can load .png files too, which should already be significantly smaller. If you want I can convert them all to lossless png's this evening.

Yea, I admit that I don't know any of the trouble this will cause. Not saying it won't, just that I don't know.
Also I will definately use .png if possible, just gotta learn how to.

I apologize, marpis. I didn't realize how big it was/didn't even think about it.

I thought about it, but was more focused on getting it working. >.>

Perhaps we should use an updater and then have it force to update from the server if necessary. Otherwise, its a HUGE file. Perhaps we could host it on github and download from there? If so, there *definitely* needs to be a warning for users that the files is massive.

Has the plugin been reduced in size at all?

Since everyone else took this moment to defend themselves I will too.

I thought of SPS not being released as part of SRL, but as another include e.g. {$i sps/sps.simba}



However if we want to include it as a part of SRL, we can just do

function LoadSPS;
begin
  if not WeHaveSPSBitmaps then
    DownloadSPSBitmaps; // includes/SPSMaps
end;

So not distribute the bitmaps as part of the include but have them available for SPS.simba to download.

That's actually a great idea. :)

Is there an interest in combining SPS with CTWB to resolve this and other issues?

From: Boreas
Is there an interest in combining SPS with CTWB to resolve this and other issues?

Tell us more please :) Or link a thread.

Are the images in the public svn version the same ones?

edit:I got them down 10.3 mb being pngs then pngcrushed. http://uppit.com/1i0ji8w09ima/SPS.rar

From: marpis
Tell us more please :) Or link a thread.

http://villavu.com/forum/showthread.php?p=780848#post780848 That's talking about bitmaps being in memory, but it applies to download size as well, as only the small pieces needed have to be downloaded. It wouldn't help with disk space on the server, just the bandwidth. The small text files with symbol/tree/etc info would be downloaded by everyone to start with, and for every repo rev (if I understand correctly, the extensions grab entire snapshots everytime, not just changed files like git/svn). Then for a given path the script downloads the pieces it needs (skipping ones it already has). If you get teleported or lost so much that you go off the path (and you have a web walker (which can also be used for reflection)), it looks at what is on the minimap, and checks the text files for which bitmaps to scan, downloading ones it doesn't have on the fly.

After a while, most people that auto a lot of skills/places will have the majority of the f2p map, where each piece was downloaded just once, and not all at the same time. If they want to go somewhere new, it simply grabs what is needed (they may need to help make new pieces for uncommon p2p areas).

I way that I would suggest would be to host it on Google Code and not include it into the main SRL (why do I say Google Code instead of Github? Github forces https and Simba doesn't support https yet). Make 2 version files, one for the bitmaps and one for the main script file, and then SPS.simba grabs that file off Google Code and compares it to the local version. Piece of cake and won't clog up SRL's download size :D

I can host the images on Villavu too. It's not such a big issue as long as it's not downloaded every time. png should help a lot, too.

Myles, what does pngcrush do? Forgive me for not googling.
E: I see. Well, as long as they are still loadable by Simba. :)