tigercat2000

/obj/machinery/computer/shuttle/pod/emag_act(mob/user as mob) /obj/machinery/computer/supplycomp/emag_act(user as mob) /obj/machinery/alarm/emag_act(mob/user) /obj/machinery/bot/emag_act(user as mob) /obj/machinery/bot/mulebot/emag_act(user as mob) /obj/machinery/clonepod/emag_act(user as mob) /obj/machinery/computer/arcade/battle/emag_act(user as mob) /obj/machinery/computer/arcade/orion_trail/emag_act(mob/user) /obj/machinery/computer/atmoscontrol/emag_act(var/remaining_carges, var/mob/user) /obj/machinery/computer/security/emag_act(user as mob) /obj/machinery/computer/communications/emag_act(user as mob) /obj/machinery/computer/HolodeckControl/emag_act(user as mob) /obj/machinery/computer/HONKputer/emag_act(user as mob) /obj/machinery/computer/message_monitor/emag_act(user as mob) /obj/machinery/computer/emergency_shuttle/emag_act(mob/user) /obj/machinery/door/emag_act(user as mob) /obj/machinery/door/window/emag_act(user as mob, weapon as obj) /obj/machinery/door_control/emag_act(user as mob) /obj/machinery/smartfridge/secure/emag_act(user as mob) /obj/machinery/mass_driver/emag_act(mob/user) /obj/machinery/poolcontroller/emag_act(user as mob) /obj/machinery/porta_turret/emag_act(user as mob) /obj/machinery/programmable/emag_act(user as mob) /obj/machinery/recycler/emag_act(mob/user) /obj/machinery/suit_cycler/emag_act(user as mob) /obj/machinery/computer/telecomms/traffic/emag_act(user as mob) /obj/machinery/computer/teleporter/emag_act(user as mob) /obj/machinery/turretid/emag_act(user as mob) /obj/machinery/vending/emag_act(user as mob) /obj/mecha/emag_act(user as mob) /obj/item/device/lightreplacer/emag_act(user as mob) /obj/item/device/megaphone/emag_act(user as mob) /obj/item/device/radio/beacon/emag_act(user as mob) /obj/item/device/hailer/emag_act(user as mob) /obj/item/weapon/defibrillator/emag_act(user as mob) /obj/item/weapon/storage/lockbox/emag_act(user as mob) /obj/structure/sign/barsign/emag_act(mob/user) /obj/structure/closet/secure_closet/emag_act(user as mob) /obj/structure/closet/crate/secure/emag_act(user as mob) /obj/item/clothing/mask/gas/sechailer/emag_act(mob/user as mob) /obj/item/weapon/rig/emag_act(var/remaining_charges, var/mob/user) /obj/item/clothing/accessory/holobadge/emag_act(user as mob) /obj/machinery/librarycomp/emag_act(user as mob) /obj/machinery/mineral/labor_claim_console/emag_act(user as mob) /mob/living/carbon/human/emag_act(user as mob, var/obj/item/organ/external/affecting) /mob/living/silicon/robot/drone/emag_act(user as mob) /mob/living/silicon/robot/emag_act(user as mob) /mob/living/simple_animal/pet/corgi/Ian/borgi/emag_act(user as mob) /mob/living/simple_animal/spiderbot/emag_act(user as mob) /obj/machinery/photocopier/faxmachine/emag_act(user as mob) /obj/machinery/power/apc/emag_act(user as mob) /obj/machinery/power/port_gen/pacman/emag_act(var/remaining_charges, var/mob/user) /obj/machinery/power/emitter/emag_act(var/mob/living/user as mob) /obj/machinery/computer/rdconsole/emag_act(user as mob) /obj/machinery/computer/rdservercontrol/emag_act(user as mob) /obj/machinery/computer/shuttle/emag_act(mob/user) /obj/item/weapon/rcs/emag_act(user as mob) /obj/machinery/computer/telescience/emag_act(user as mob) /obj/vehicle/emag_act(user as mob)

this legit hurts my brain to look at but i'll probably do this in a few days, i haven't been doing my job of porting cute things lately

don't personally like this but it does bring up a fair point 509 is "stable" and has been for a while, we probably should be doing stuff with the client.color and appearance_flag systems

https://github.com/ParadiseSS13/Paradise/pull/3330

-tg- actually has major performance impacts from their decision to run LINDA at 4x- If you were to run their codebase with LINDA turned back down to 20 deciseconds, it would run even more smoothly. The reason that -tg- runs so smoothly compared to us is for a few reasons: 1) They do have a better computer running their servers. Mel's hardware is awesome- but there are a few bottlenecks that -tg- has gotten around, mainly in terms of the RAM installed (I believe they use DDR4 RAM sticks.) 2) With the huge amount of coders mentioned earlier, a lot of tiny performance impacts (for var/whatever in world) are quietly and quickly fixed. They make basically no difference on an individual level, but when you have 60 of them running at the same time, it gets a lot more noticeable. 3) Bots. Beepsky/Medibots/etc, they all use a system called "A*" for pathfinding- -tg- has made major performance enhancements to both bot code and A* on their server. We've tried to port it in the past, but it's such a mess that it's very hard to actually modify, especially while trying to keep every feature. Try spawning 50 medibots on a local server, it tends to cause things to grind to a halt as they try to pathfind their way around. 4) Their "subsystem" controller does completely outpace the scheduler. It dynamically turns subsystems on and off and can delay them indefinately while things are going on- When an explosion occurs, half of the controllers may outright not process that tick. And, it's a very good approach- however, it has it's flaws, most of which I don't know the code well enough to mention. But, our scheduler, from what I understand, is more efficient long-term, and more robust overall, especially with the technical backing of GoonStation. The big difference is SCHECK- It's a thing on our scheduler that tries to stop controllers from pushing the server too hard, thus delaying the next internal tick of byond. It supposedly can get a more accurate reading of how well the server is performing via the 'btime.dll' library.

Shadeykins, do you not understand how to take a hint of "stop making walls of text arguing with the maintainers"? Jey's original code was bad. Any amount of arguing over the fucking technicalities or "well cpu load doesn't actually equate to network latency" doesn't change that. It was a more than 30% increase to CPU costs in the profiler, and from all the details Jey has provided, he didn't actually wait for LINDA's active_turfs list to fill, which is where the huge performance loss occurs. One of the maintainers tested the modifications locally, actually bothering to check that LINDA is actually under load, and found much higher performance loss results (over 50%). We absolutely do have parity with LINDA on -tg-. They use a different central controller (-tg- subsystems as opposed to the Goon ProcessScheduler), but they work almost identically, and serve their purposes well (ticking things efficiently). They run LINDA at 4 times speed; A single variable change for either controller systems. They also run pipenets on the same controller as LINDA to make sure atmos processes in-time with the pipes. Any changes to LINDA, right now, would be very easy to apply to our code, which is the entire point of maintaining parity: They have over 20 coders working on just about everything, every day. We have 3 maintainers and 4-5~ coders, who are only sometimes even awake at the same time. We do not have enough dedicated coders to maintain a system as huge as LINDA, especially with modifications that only 1-2 of us can actually understand. The thing about "guidelines or reasonable expectations" is, we for the most part don't want to change LINDA, at all- I don't care if Jey's code is just "adding a few hooks" to LINDA's controller, it massively increases the amount of work LINDA or LINDA's controller actually has to do, which 100% will affect user experience and server performance. Figures like "Most players want LINDA changed!" are pulled directly from absolutely fucking nowhere. The majority of users don't give a fuck until LINDA ends up killing them because of spacewind or fires or whathaveyou.

it was removed because it took up an entire z-level despite having only been used maybe 10 times ever, and it was discussed thoroughly on github You mean the broken-ass hardsuit damage system? Because that was outright fucking hellish. Syringe immunity was semi-discussed, but I'll give you that one, not many people talked. What do you call the 51 comments on the PR, then? Or the multiple forum threads discussing it? It was discussed to the point where most of it's features were removed, actually. It was removed for the organ overhaul, and yeah, it didn't get discussion- mainly because it wasn't optional to keep or get rid of.

Wh.. How do you even slightly draw this conclusion? Chimera got through a non-mentioned change because we were so stupid as to go "okay fine you don't get how to use the simple mapmerge tools, we don't need mapmerge, it's the asteroid anyways", which is definitely not happening again. What he did isn't even slightly acceptable, and I'm surprised we didn't ask for github support to ban him from the repo. Wat No really, explain this to me. Do you think that the server performance doesn't matter for a game that is almost completely handled serverside, clientside code doesn't even exist for anything but UIs? Because it really does. If the server is lagging badly, chat messages are no longer sent, map data to render is no longer sent, client input can get dropped, user interfaces might 'work' but won't actually allow you to call back to the server. This PR was closed because not a single one of the coders approved of the performance impact, adding a lot of code to LINDA, and changing how atmospherics worked for the sake of a semi-sped-up simulation.

if PDA code wasn't A) nanoUI B) incredibly shitty (every single cartridge in one giant else-if list) it would be great

It's a much higher probability that no change to explosions will go through.

it does raise nutrition by an incredibly tiny amount, less than raisins

I think it was more intended towards "so the AI can't easily bolt everyone in" or at least, that was my justification for not removing it in the first place!

snek

I suggest making an issue report on the -tg-station github repo about that, Plotron. I'm not willing to make major changes to the shuttle system for the sake of keeping one of the shittier features of Bay shuttles- But being able to abuse the shuttles to stay in transit indefinitely is something I am sure the -tg- coders would like to prevent.

we do have that, it's not mapped in anywhere though, because it's shutters without the advantage of protection

It seemed about that bad to me looking over it, given that I seriously cannot comprehend the code fueling the bay version. I get the basic abuse going on in it, like the list(list()) stuff, which is required to embed a list within a list for nano's javascript to parse. But, then there is stuff like Line 391 that makes no sense to me, it has the standard list(list()) abuse, but then it has extra list()s within it containing what appears to be parameters- I have no idea how this works, as it seems like it would simply add the lists to the outer list (because list procs in byond are fucking insane). Then, it defines "command3" as a text value? All in combination, I get that it results in a few buttons for each supply pack allowing you to order and view the contents of them, but god knows how the fuck they actually come together. Replicating the same with -tg-'s slightly different supply pack system confuses me even further. Then there is stuff like this and this blocks which I have no idea how to replicate with -tg-'s supply packs. After that you have this shit which is almost completely different with -tg-'s system, and I have no idea how either one works.

I looked into readding the cargo UI, and outright, it's not going to happen. Not by my hands. If someone else decides to delve into the madness and try to sort out all of the wires to make it work, I am more than happy for it to be readded, but it's not me. Since, I know how everyone just loves the "fuck -tg-!" bus, I'll explain exactly why I'm not able to fix the UI. This, right here is the code for bay's cargo UI: https://github.com/ParadiseSS13/Paradis ... #L375-L526 Can you read that? Because I'm having trouble fucking reading any of that. And that's just from a "actually trying to read it as text" standpoint, actually trying to comprehend the fucking code is even worse. From what I can tell, it autogenerates commands within a list within a list within a list to send a list to the UI. I don't even fucking know what is going on in the Topic(). Now, let's say I spend a few hours digging through this and trying to figure out exactly what everything does, probably possible. This is the template file for the supply UI: https://github.com/ParadiseSS13/Paradis ... nsole.tmpl Now, let's take a moment trying to just list the amount of things that have to change within it. These lines have to be replaced with a single line which I don't even think works. Easily possible to fix. These all need to be replaced with the -tg- shuttle system version of calling, recalling, and canceling (don't think this a thing) shuttles. I don't have the slightest clue how this works, let alone how it is supposed to work! As far as I can tell, it lists the supply crates via magic! But only if it.. doesn't have contents? It doesn't make sense! Now, let's say I somehow figure out how to fucking get this pure insanity fucking done- OH WAIT, THIS TEMPLATE FILE HAS TO ACCOUNT FOR TWO DIFFERENT COMPUTERS! Anyone want to code this themselves, have fun.

Our cargo system wasn't compatible with -tg- shuttles.

The supply shuttle UI was removed because it would require partial rewrites of the supply template, and a full rewrite of the basic code to account for -tg-'s supply system. When I have some time, I'll try to look into re-adding it, but no guarantees.

Actually, I am pretty sure (unless someone broke it) that roundstart cyborgs have either an MMI or a Posibrain depending on the job alt title

10/10 necroposting now regens lock this thread and make them make a new one

or, maybe, you could just you know play the game enjoy the gamemode perhaps get some RP out of it from what I have heard and not throw a fit over "BUT MUH LOGIC"

This isn't likely to happen any time soon. -tg- uses their robust organ system for all of it- we have a much shittier system that would have to be heavily modified to work for this kind of thing.