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.

My most beautiful creation! Credit to Alffd for the images.

Internal Office Memo: Message To: Comms Officer Jenkins Message Sender: A.L.I.C.E. DONOTREPLY Message Title: Appointment Reminder Message Body: This is a reminder of your upcoming scheduled surgery training program, which you were randomly selected for. You will be fulfilling the following role: Patient. As per section 445C of your contract, attendance is mandatory. Your surgeon-in-training will be: Steve.

It was a joke :^(

Thanks a bunch for this man, I've passed it on to the people who do the technical stuff and i'll ping them here so they remembe @Allfd when you get time can you look at all this or pass it to someone else who can?

Dramatic setting in place! There was a fight and they fell off of something but they're fine, it's fine, everything is fine...

It sounds like a 0.5 out of 5 stars fan made skyrim modification from category "non-serious/other" I mean... It just doesnt fit the game

Ah, yes. This again. Now, before I say anything, I should note that Section 3, Sub-Section A-15 of a standard NanoTrasen work contract reads, and I quote: "By signing this contract, [name of employee] acknowledges that possession by, or encounters of varying damage with, hostile Xenos-class organisms shall not be held against NanoTrasen. NanoTrasen does not hold itself accountable for any incident which might result in the possession, replacement, substitution or death of [name of employee] as a result of encountering a Xeno-class organism." We figured it was easier than spending more money in screening out shit that even our Bluespace nerds can't figure out. I mean really, vampires? And shadow creatures and shit? Fuck that, it's easier to just repair the station and clone you all from the master copies. As for the agents thing, well, to be perfectly frank, we don't continuously screen people after we hire them unless they're involved in anything above a Class-Red Authorization Level, so a bunch of lower-level employees can, and often do, slip under the cracks when it comes to Syndicate blackmail. We do screen out people with existing connections to the Syndicate, but Class-Red notwithstanding, we're not constantly looking back. I mean really, we have better things to do. Ah, yes, hello Mister Warden. We apologize for your job existing, but it's cheaper than using proper surveillance and modern jailing techniques. As for your first question, I'm going to have to defer to something the eggheads over in Virology cooked up; I'm not a microbiologist, so I'll defer to people who claim to be. ###cd medi_shit### ###cd viro_stuff### ###type virus_viral_mutat.doc### ### ### ###cd response_shit### Alright, so, what it says here is that the viral strains that normally plague not only the Cyberiad but also other installations with a similar number of individuals can be attributed to a few factors: A) We routinely ship people from all around the galaxy to work together, increasing the probability that one of them might be carriers for an hitherto unknown strain of a known viral agent, and increasing the number of vectors for existing strains to mutate across. It doesn't help we also keep hiring species with substandard hygiene habits, like the goddamn chickens Vox; B) The station is constantly bombarded by radiation that is often strong enough to break through standard shielding, hence the whole rad alert thing and reinforced maintenance tunnels. Remember: radiation + time = shitty mutations; C) Virology exists. Even our own eggheads are scared of the shit they're allowed to do Moral of the story is: eat healthy. As for the second one, well... to be honest, we've stopped screening for mental imbalance years ago; it's why we just give psychiatrists a cubicle that's smaller than the Janitor's closet and don't even provide for psychoactive medication. Sure, it makes crime rates shoot through the roof, but if you look at the bigger, galactic picture, it... honestly becomes cheaper to just let that happen rather than going through the hoops of ensuring mental well-being. I mean really, why do you think we give you so many cells to work with? It ain't for decoration! So, keep on keeping on, brig those fuckers, knock 'em on the ass a couple of times, and call it a day. Make sure to flag them on the records too, so we know who to assign to Janitorial duty.

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?

More Star Wars stoof

A screenshot from discord because why not?