Fox McCloud

Just wanted to say a quick thing, Plotron. Yeah, the newer CPU's aren't that much faster than the current, butttt, they are DDR4---the way BYOND reads and writes variables means that memory can actually have a larger impacts on certain performance than others; when TG upgraded to DDR4 they also upgraded to a CPU that was like 10-20% faster...but the performance for LINDA, specifically, increased by 80% because of the memory.

I'd be happy to touch on this. here's TG's processor: https://www.cpubenchmark.net/cpu.php?cp ... Hz&id=2565 Here's Mel's/Para's: https://www.cpubenchmark.net/cpu.php?cp ... 50GHz&id=2 Mel's is overclocked a bit, so it's not a direct comparison, but as you can see, the 6700k outperforms it by a significant margin. Also with how BYOND reads and writes variables, it's VERY memory dependent in terms of performance; TG's previous processor was about as good as Mel's is, but yet when they updated to the 6700k, they got an 80% increase in performance for LINDA---reason why is because of DDR4 and its dramatically increased speed. Another reason is what Tigercat touched on; TG's subsystems are, from what I've gathered, superior to the process scehduler. How the process scheduler works: it kinda breaks apart individual controllers so that if one is hung up, it doesn't impact the others; you know the times you get spammed with "obj processing hung, and was killed at XX:XX"--note how youd could still move, walk talk, and do things---with our previous controller, if this happened, the entire game would lock up. Another feature of it is a thing called "SCHECK". Scheck is a command that references and external .dll called 'btime'. BYOND has no way of determining how far into a tick the server is nor does it have an accurate way of measuring CPU (the CPU displayed in game is an average over the past few ticks...). What scheck does is after every so many things in a loop (ie: every 50 mobs) it'll check this external .dll and see if it *thinks* the current tick *may* be driven into overtime. If it looks like it may, it'll sleep for 1 tick and defer the rest of the calculations for that loop to the next server tick (this is also why it's kinda pointless to break a loop up into quarters). Oh, that reminds me, referencing and checking btime.dll is hyper expensive. That said, we don't live in a perfect world; it's still not 100% possible to determine if a tick really is going to go into overtime andddd sometimes scheck is a bit too aggressive and will defer when it doesn't really need to (thus wasting CPU). If everything in SS13 were perfectly coded, the scheduler would actually be a net drain on performance and incur a loss from scheck. TG's subsystems don't have btime and they handle adjusting their systems in a (I think--though I could be wrong) more optimized way in calculating costs and adjusting things (on the fly) internally; LINDA, for example, will actually end up running slower than our implementation if their CPU load is very high (it just runs at every 5 decisecodns by default). When we were initially going with the scheduler, I had a discussion with some of the TG station devs and why they weren't going with it--ultimately, in a perfect world, the scheduler is dead weight--and thus why they viewed their subsystems as superior (and this was before they made major strides into internal system adjustments for controllers). I do believe there's aspects of the scheduler that are superior, but on the whole, the subsystems appear to handle lag better. Performance is a constant battle on Paradise as we don't have huge margins to work with, unfortunately; for example, when I was porting the Tesla engine, I was constantly keeping an eye on how costly the orbiting energy balls were---I even ran the server for 2 hour durations (multiple times) to see what performance impact was likew ith tons of balls orbiting it---this all went in mind before I decided if it was actually an "ok" thing or not.

Compressed were far worse, actually, Plotron. You scanned the item, it went into the implant; if the implant were removed, it would be in the implant, permanently; you couldn't remove it from the implant because there wasn't a way to get the implant back inside someone---someone who used compressed with a traitor item? You're never getting the item back unless they want you to. Storage? If you do remove the implant it's going to eject all of its items.

A lot of things cease to function, too, on unsimulated. Blood, vomit, overlays, some effects, etc. A big one: simple animals out and out die.

You cannot put posters on boxes; that was never added.

For clarity, regardless of the outcome of whether or not implants show up on scanners or not, implants aren't going to be stored inside bodyparts anymore; just in the mob, generically.

There's really nothing more I can say--you're obviously going to ignore every point or suggestion or statement I make, so please feel free to continue posting as you currently are, because you're going to do that anyway.

You'd still be able to do an exploratory surgery to see if someone had an implant or not; that would still be a "check" and it would be relatively time consuming/"costly" enough that sec won't feel the need to build their own scanner and slam every suspect they come across into it. My main problem with them being easily detectable: - The general trend has been towards less antag checks, not more (cultists can counteract holy water, vamps are immune to things at full power, ling blood test removed, agent IDs that only the original person can use, etc). - Vamps/Changelings have a wide array of very powerful abilities at their disposal; sec can't just throw them into a scanner to confirm this or not or see if a ling has night-vision or not. - Uplink implants come at a premium and are TC inefficient (14 TC for 10 TC) specifically because they are supposed to be difficult to detect - with the exception of the new storage implant, the only reason sec really has to remove an implant is so they can re-use it for themselves (which is illegal under space law anyway) - Traitors can already pretty easily store things in undiscoverable location with the flatpack satchel if they want to.

And apparently we, as maintainers and coders can't be clear enough to you in a nice way, so I'm going to word this very bluntly: We don't want your PR if it's anything remotely like the last one. We told you the criterion something will have to meet to alter LINDA, and from what you've already described, your hypothetical PR would not meet that criterion. Again, if you're hellbent on making changes to LINDA, I highly recommend you get it past LINDA's original coder and creator, over at TG, first (and even then, there's no guarantee will backport it).

There's no point in continuing this argument or discussion if you're going to completely ignore points I've made or evidence I've presented that have been born out to be for the live server (and multiple coders and maintainers can back me up on that); if you're not willing to accept that a true or as to the way things are, there's...not much I can really do or say to change your mind or convince you one way or another....not to mention you completely ignored a few other points that I and other have made, too.

Just throwing this out there as there's a lot of misconception and incorrect information here: - We, the maintainers, and Tiger (who ported LINDA and largely looks after it), specifically stated that (1) we wanted to have parity with TG (2)That we didn't want a system that increased the overall cost of the air system (3)That for something to be accepted, it would have to keep LINDA largely intact while reducing overall CPU cycles. - Jey's PR was tested: under roughly identical sitautions, it more than doubled the cost of LINDA - LINDA is one of the biggest costs on the server, especially come mid to late round---there's a LOT of stuff that goes on atmospherically that you're not going to see in localized testing, such as: disposals, accidental window breaks, explosive testing, breaches to space on the asteroid, people forcing doors to space (and leaving them open), improperly mapped turfs on away missions, etc. You don't see this stuff during the first 15 or even 20 minutes of testing--it takes time for things to build up. - Yes, we've done tests of running LINDA at 4x the speed--and guess what, it caused some significant performance issues, which is why we haven't even remotely considered turning it up, in general---yes, there's been times that we've announced it to players, but there's also been quite a few times we haven't---turning it up during times of high depressurization crushed the server and the speed had to be lowered. - Some of the things that have been proposed or suggested to "alleviate lag" won't work, due to how or process scheduler handles the big controller loops - Specifically to Jey: If you're proposing big sweeping changes to LINDA, I highly recommend you get it past TG and Arancalnos, first. (LINDA's designer and coder). Your statements are now bordering on intentional disinformation; we stated multiple times here, and in the PR exactly why it got denied, and yet you make a statement like this. If you're going to argue a point with fact, that's fine, but twisting those facts to suit your purposes or to stir things up is blatantly dishonest.

I see what you did there with his name. Very clever.

Um, what? No. It's never been added...

This--or the bodies can be spaced or incinerated or put in the chaplain's morgue...orrr just left in the regular morgue for RP/second chances/etc. Sec can already veryyyy easily take people out of the round permanently if they want to.

This, so much; I actually really like it for most hats/helmets, because the ears still properly show up through them; while this does lead to a few silly things, for the most part, it actually makes things look better, IMO.

Having your taser on your armor is not an SoP violation as far as I know; as far as I know, that refers purely to running around with your taser out.

Hue. What I said was entirely in reference to the file: "Unbalanced text file" and "empty processes". There's no way I'd support removal of organs, especially when I'm one of the biggest supporters of Fethas' organ overhaul. While I realize that not everyone is a coder--it does help to take note of what files have changed =p Ya got tricked by the fox.

Also worth pointing out we'd have to dramatically increase the standards for mentors (and there would end up being less of them) if they were to have additional features like this.

with the way Bay's wound system is (an absolute nightmare), I'll be honest, I'm really not sure how easy it would be to differentiate between the two; all I know is, wounds by fire and brute, both, sharp or not can become infected if they're not bandaged. Reason why most people get infections is they get the damaged treated, go back to doing things, then wind up with an infection because the wound was "open". In any event, maybe I should clarify what I mean by "nerfing brute". I'm not suggesting reduce brute damage *amounts* so much as the side-effects of brute damage (like breaking bones/projectile embedding/bones moving in your chest/internal organ damage via brute/etc).

Explosion patterns being altered in such a way that they behave very similar to recursive explosions is a nerf, no matter how much you slice it--any long time player (who uses explosives) will tell you that recursive has an inferior/less predictable blast pattern than non-recursive. Again, I have zero problems with optimizations to the code; I welcome them any day of the week, I'm just saying it would be better if they were slotted into our current explosion mechanics rather than making them iterate the way recurisve explosions did---again, our explosions already do factor walls and doors into play:

They also have unique drawbacks that energy guns don't have, as well; namely having a chance of irradiating their user to hell and back if they malfunction.

It has an increased capacity and self-recharges---all for something that can be mass-produced--ittt kindaaa needs a drawback.

Tea is relatively easy to acquire. You can fix burn and tox with simple medicine, but even moderate brute trauma may require a surgical intervention. Moving bones are the worst, especially in the head and chest. This is ultimately what I"m getting at that Plotron is touching upon. Brute is, by far, the most common damage type, yet it is also the most detrimental to a person, for a number of reasons--primarily that it leads to a LOT of extra damage that very difficult to correct for: bone breaking, internal bleeding, blood loss, internal organ damage (which can lead to a bunch of other damage types), and permanent disabling of limbs. Take, for example broken hands; with a mere 30 damage dealt, someone is literally permanently taken out of a fight except for using unarmed melee attacks. This contrasts sharply with every single other damage type, which requires ~100-150 damage to incapacitate someone with. I don't personally feel massively buffing the other damage types is a good way to go about it; there's nothing fun about taking a tiny amount of damage and being permanently taken out of a fight because of it.

I'm really not terribly interested in going to anything remotely similar to recursive explosions--it's a gigantic nerf to explosions and results in extremely weird patterns when the bomb actually goes off---furthermore, we already have something that's *similar* to recursives, but isn't resources intensive----called "reactionary explosions" (Keep in mind, you have to have these turned on in the config). I would definitely be interested in seeing what you've done to increase performance though; that is always welcome.

It's meant to be an zero access door so that even people without access can utilize it; it's fully intentional the door is green.