Leaderboard

Hey all, TL;DR: If you're interested, some of the game files could be made smaller with assistance to keep the process ongoing for new files. Cut the current sprite source size by 27% (12.8MB), audio source by ~38% (~30.7MB), paradise.rsc lowered ~28% (~28MB) with sound optimisation, another ~12% (~12MB) with sprite optimisation (~100MB -> ~66MB total) Too long; read anyway: (thanks for reading :) ) This isn't a code thing or feature to be added, but I know someone involved in the server and through them took an interest in the game data. I have experience in image / web site data optimisation and used those eyes to look over the git repo. After I grabbed a copy of it I saw that there was some data being used up that didn't need to be in the game resources. I'm not intending to step on any toes so any issues / rejections aren't a problem, just something I managed to do relatively easily (taught myself a few things) and figured I'd offer it up to take a look at in case it was helpful to the people running the server as it can be integrated into the media workflow or simply done on a semi-regular basic after a number of updates. Basic explanation: Sprites and sound files can be optimised to keep 100% of their quality (or 99.99% in the case of sound) with, in some cases, significantly smaller file sizes. What does this accomplish? Aside from the game taking up less space (Yes, it's already extremely small by todays standards) it means that the server updating clients takes less time, the resource file can be pushed out in a shorter time in a smaller size, consuming less bandwidth for the server infrastructure etc. The savings get multiplied for every player that connects for the first time, or with a broken resource cache, or after an update etc. How is this done? The sprites can be batch optimised, I've already done a complete test to crush them as far as they can possibly go with 100% exact pixel accuracy to their originals. I've written a batch script for this but I want to add some final safety measures so that I can package it and provide it in a 'anyone can use this without necessarily knowing how it works, or risking data damage in the process' with statistics and warnings if issues arise (also without overwriting files if there's an error etc). The final step is just a safety check to confirm that the DMI metadata (The bit that tells BYOND how to render the directions and animations of the sprite sheet) is completely unaltered during the process so that it can warn if an issue arises that may need manual intervention. If a user repeats the optimisation on already processed data there will be no change and no damage, just wasted CPU time. The audio optimisations are a lot more complex and I do not have a way to automate them (and might not ever without potentially destroying quality or losing space efficiency), but someone with enough knowledge / practice and a Digital Audio Workstation (even a free one) can do some manual analysis and alterations (spectrum analysis, lowering the sample rate if it doesn't need to be so high based on frequencies used etc) to the sound files before encoding them, and testing which encoding setting provides the most accurate data for the lowest file size (basically encoding several examples at different settings and then just comparing them to the original, because 'the highest setting' is not always the best. A file might only need to be 1MB in order to be 'perceptably perfect', but higher settings may make that same file significantly larger). These kinds of optimisations must be done on the highest quality source available (not the existing ogg files unless absolutely necessary) and should only ever be done once per new sound file added. As I've gone I've also been writing the basic outline of a tutorial / best (ish) practice to guide others through the process, depending on demand that may be turned into a full fledged tutorial on the process. After the sprite optimisation I ran up a private server and had a poke around, but not being a player I was only able to run around and do basic interactions, the sprites seemed fine as far as I tested. The sound optimisation I'm not currently 100% sure will work as I have not tested that and there may be edge cases with the alterations I've made that cause some files to fail, though I am not able to actively test this myself, I have simply stuck to the limitations of the FMODex sound system that BYOND uses, so 'on paper' they should work. In reality however, I do not know and would appreciate testers if people are interested. I've forked the repo and added a testing branch to my own for this purpose until I know my alterations are sound, it can be found at: https://github.com/timegrinder/SS13-Paradise/tree/testing Currently it only has the audio optimisations as I want to thoroughly check the DMI metadata on the sprites to make sure they are all intact before uploading them. The process can also be backported to the other stations / code bases if people care, whether just them finding out your data is in a better envelope and pulling it, or them processing their own in some way. Hope you survived the rant! Any responses or comments / questions etc are welcome, I might not respond terribly quickly or sometimes forget to check back.

###INPUT AUTHORIZATION### ###USERNAME:### ComoJayDog ###PASSWORD:### ******************************************************************************* ###PROCESSING...### ###AUTHORIZATION GRANTED. WELCOME, COMMUNICATIONS OFFICER ROBERT D. JENKINS### ###AWAITING INPUT### ### ### ### ###run announce_cyb.exe### ###WARNING: UNAUTHORIZED ANNOUNCEMENTS ARE PUNISHABLE BY DISCIPLINARY ACTION. DO YOU WISH TO PROCEED?### ###Y### ###CONFIRMED. PLEASE INPUT MESSAGE### Hail Cyberiad, this is the Trurl here, Comms Officer Jenkins speaking. Following the disastrous attempts at improving workplace morale via the use of mutated teddy bears animated with the latest in Bluespace technology (apologies, Captain Samuels, you'll be well remembered), the NanoTrasen Board of Directors has opted for a more... subtle method of appearing marketable approachable, and to improve general crew morale, along with... whatever "Workplace Inter-Cooperation and Teamwork Doubleplusgood" is. Pretty sure that last one's not a word. In following with company tradition of not really wanting to waste a lot of money in things deemed "Class-3 Non-Essential Company Initiatives", they dumped the job onto me, and I frankly can't be bothered either, so when they told me to come up with something, I, being the well-beloved and attentive curator of the Cyberiad's airwaves that I am, decided to, I dunno, open a direct mailbox thing? Ask me shit and I'll spill company secrets because I'm bored. Just don't ask me anything about the non-existent Deathsquads, I'm not allowed to talk about those anymore. End communication.

ERT Gallia-3 dispatched to location. Please stand by. Instructions unclear, hopefully a 3D-printed pair of safety scissors should be enough? Did you lose your gun again? Ah, yes, Peggy. ... Peggy. I'm ever so happy to report that, due to outstanding work ethic and general operational efficiency, dearest Comms Officer Peggy has been reassigned away from this shithole promoted to a position as Diplomatic Liaison with the Sol Trade Consortium. Something about wanting to capitalize on "cultural propensities for trade" or whatever. I'll make sure to relay this wonderful message and totally get an autographed mixtape from our dearest mutual friend. Also no, we're not currently hiring anyone for "diversity", we already brought a batch of soap-munchers Drask on-board and have been having fun seeing how many of them make it through the selection process. As for the random skipjack crews that tended to show up, you are aware that the only reason they did was because they somehow managed to skirt through our defense grid, right? All it took was our Bluespace nerds getting their hands on one of their ships and reverse-engineering their engine drive to block them off from approaching our installations without proper authorization. Something about "improved filtering" tech, whatever that is. To compensate, I've enclosed the full collection of "Vox Gone Wild" holovids in a physical flash drive and mailed it over to your registered address (Supply Closet BA-1422, right?). Hopefully it'll make up for the lack of dearest Peggy.

A wonderful question, Mister Maintenance. Or is it Mister "in Maintenance"? Mister Lurker? Ah, who cares. Now, before I answer that, I'm afraid I need to check if I can answer that. You see, even though company policy says I'm not supposed to be privy to a whole bunch of information that regularly flows through my workstation's console, I can't help but be a sneaky bugger and nose around places I shouldn't. Brennan's been more than happy to ignore it, so long as I don't divulge anything I'm not technically supposed to, so uh... ###cd auth_lvl### ###type danger_cyb_auth.txt### ### ### ###cd response_shit### Alright, so, according to what I'm technically allowed to say, as far as the Board of Directors is aware, there is no known reason why the NSS Cyberiad keeps being targeted by all these "strange disturbances", which I can only assume are all the Syndicate agents you keep getting infested with, or the nerds over at the SWF. As far as anyone can tell, it's probably because: A) It's our newest, shiniest station and these people are petty assholes; B) Epsilon Eridani is... let's say "contested" territory and somewhat difficult to keep fully controlled. Hence why so many of you keep showing up to work with the loaded gun of Syndicate blackmail pointed at their head Such is life when you try to slowly take over the galaxy by buying people out, it tends to generate enemies both reasonable and eldricht. This is why our insurance premiums have been going through the fucking roof in the past standard years. Unless, of course, you're talking about the random anomalies you keep experiencing, of the gravitic or pyroclastic variety, among others; those are because we deliberately put the station in an orbit that would make it pass through multiple, prearranged pockets of Bluespace distortions, in order to, uh... it says here "facilitate the endeavors of the on-board research team". Sorry about that, I guess?

I can't believe no one has posted this yet:

Departmental lathes would solve this problem. Instead of the protolathe being one all in one machine to all the best stuff, each department gets it's own protolathe that can only print things relevant to their department. Each lathe would be locked to an ID of that department, so even if engineering builds a science protolathe it won't do them any good without a science ID. It has the added bonus of decentralizing power away from science. Part of the reason departments do this is because sometimes getting science to actually give other departments stuff is pulling teeth. Half of science is usually traitors and you're lucky if you can find someone who will be nice enough to actually man the RnD window and not just print all the best stuff for themselves and go wander off blow up monkeys or something.