tigercat2000
-
Posts
723 -
Joined
-
Last visited
Posts posted by tigercat2000
-
-
fat people that murder people as a non-antag get the same as a greytider beating someone to death
otherwise, if you eat someone that has a weapon or fucking any gear, you can't fight back and they will 90% of the time make you into a pile of lovely gibs
-
no, it's the "don't touch my shit because [wah my realism!] [moral reasons] [it's only for grief]" excuse
-
yes, xenomorphs/kidan/tajaran/fat are all part of the same system
-
why would we ever remove this
realism is a shitty excuse and you know it
it's not even coded terribly
-
-
/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)
-
Posters for these guns already exist in-game, so their implementation is already supported.
Why not?
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
-
-
-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.
-
I'll provide the removal of the syndicate station (The one reachable via teleporter) as another example then, it was removed for "not working" when the only issue with it was it was wired incorrectly so the APC drained and it became unreachable.
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
Hardsuit syringe immunity/puncture removal is another example that wasn't discussed.
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.
Vulpkanin implementation (And I do play one) was another thing that wasn't discussed.
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.
Surgery rewrites to eye surgery (which makes eye surgery far more complicated than it should be and makes medical's job even more time consuming) was never discussed.
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.
-
There's a lot of things that are slipped through in PR's that are not remotely discussed yet are pushed through because they go under the radar, a great example of this is UltimateChimera sneaking in a PR to remove the xenosuit on the outpost.
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.
CPU load does not directly correlate with latency, and rooms having greater reaction to atmospherics changes is a plus, not a negative.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 is more about atmospherics being entirely closed off and PRs being outright refused/not even being deliberated simply because they are atmospherics PRs.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!
-
Thought I'd try to sprite up a Lamia
-snip-
-snip-
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.
-
What I think would be cool is if we had Bay's 'electrochromatic glass'. It's in a few heads offices, and basically you press a button and it turns the blue reinforced into tinted black windows you can't see into. Not quite the same as what you're proposing, but a fair slight cooler than shutters. Maybe not exactly what was in mind, but something I recalled that was interesting.
Almost anything would be better than being able to awkwardly stand on the other side of two reinforced windows, a grille, behind an airlock, and still be able to hear the conversation up front. While I understand the utility, and the fact it's basically an SS13 staple and fact of the game, it feels a bit... off.
we do have that, it's not mapped in anywhere though, because it's shutters without the advantage of protection
-
Well well, there's making an overstatement and then there's that post. It really isn't as bad as it's made out to be. Clearly you haven't had the pleasure of working with associative arrays in BYOND before.
I'm not happy about the UI being ripped out in favor of having the new shuttles in as quickly as possible, so I'll re-implement it myself.
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.
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.
Remove fat people vore shit
in Suggestions
Posted
If you eat someone and get upset that you got gibbed, you can go fuck yourself, shouldn't have ate them.
It's been in place for years. Fuck off with trying to remove shit just because you don't see a use.