-
Posts
723 -
Joined
-
Last visited
Everything posted by tigercat2000
-
https://github.com/ParadiseSS13/Paradise/pull/2220
-
I can see about this, it's pretty simple how the system works. I'll add $race; Any other ideas? edit: A list of them would be nice.
-
redundant if https://github.com/ParadiseSS13/Paradise/pull/2217 goes through
-
I would actually rather let people give karma to admins, even if they can't use it, because muhstats
-
I am in fact proficient with C, C++, VB/Basic and have dabbled with LUA. I am a coder. I get the whole efficiency motivation behind installing LINDA, but I'm just looking at it from a features perspective. I feel like it would been worth the effort and resources to buy some professional, stress-testing software and put ZAS through as many hurdles as you can and find it's weaknesses and where any potential memory leaks or other such nonsense might be occurring, rather than culling the features in favour of efficiency. What I get caught up on with this whole "LINDA is tied into everything" thing is, either that means the Atmos code isn't wholly contained within one area (which it should be), or you're simply stating that it has a lot of function calls. To me, if it's written all over the place it's sloppy, and if it's just function calling that's not difficult to change (But is certainly time consuming). In the instance of function calling, you can simply refrain from changing the name of the functions, and just tweak or thoroughly modify the programming contained within to implement changes. My statement was, "Yes, there's been 1000PR's since then, but not all of them touch on atmos, in fact most of them probably don't.". I didn't mean to make the task sound any less daunting than it was, I'm just thoroughly of the camp that sometimes it's better to toss your work and start from scratch if it's not turning out in your favour. I ultimately feel like if LINDA was such a monumental effort to install, such efforts may have been better used in building an atmos system from the ground up - this would have provided a modular and easily understood framework that could be tweaked, changed and bugfixed without losing a large amount of sanity. This could also be a bit of "Lost in translation". For instance, if BYOND doesn't allow function calling on certain levels for god knows why, and rewriting code in segments is a requirement. I'm so glad you know other languages, but that doesn't change that you aren't the one that has to deal with SS13's insane mess of code every day. It would be absolutely fucking insanely difficult to yank out LINDA now. You couldn't just revert the commit, that's not how git works, you would have to revert every single little thing that touches anywhere near atmos, and that would ABSOLUTELY create merge conflicts. A lot of shit has been added; This new shit has ties to LINDA where appropriate, whether it's from the different use of CanPass or the new procs for creating fire. Yeah, LINDA was a pain in the ass to get working, because -tg-'s code is so so so much different than ours. It was still 1000 times easier than writing an atmos system from the ground up, which would involve having to understand how atmospheric models work, as well as months of testing, when LINDA is already tested and we know exactly how it is supposed to function. And, no, LINDA isn't contained to it's one file. It's original PR, which was just a barely-working implementation of it, touched 126 files, with 8000 line changes. Actually getting it to function properly touches more than that. Atmospherics is tied into everything; Mob movement, turfs, objects, collision detection, fire, chemistry, space, EVERYTHING. Should it be like that? Probably not. But you have to work within the bounds of an absolutely horrible engine which can barely support such a huge game. At this point in time, yeah, no, we aren't going to fucking remove it, and if you want it gone, I absolutely welcome you to spend months trying to get ZAS to work again. Even our entire pipe system no longer is compatible with ZAS. This is not a good reason to continue with Linda, because it will only get more difficult to remove it. It's absolutely a good reason, none of the coders want it gone, and definitely don't want to put in a huge effort to get rid of it. Point two is very vague and linda has it's issues too. This is an administration issue and hardly reason enough to butcher the entirety of one of the most important parts of the game. Because having literally no easy way to stop a plasma fire as admins is definately better. If LINDA has bugs, report them. I absolutely do. ZAS was bullshit on every level. Even small fires damn near crashed the server. And, there is no "we don't undo LINDA now", would you like to put in the effort to revert it, make sure every single little thing is functional, then reimplement the latest ZAS on top? If you do, please, I welcome you to try it.
-
Reimpliment passive vents for atmosia.
tigercat2000 replied to GelatinousGlob's topic in Suggestions
resolved by https://github.com/ParadiseSS13/Paradise/pull/2205 -
Keep this damn discussion about the bouts of LINDA. Not everyone hates it. I personally love it, and I know others feel the same. You think LINDA is bad with pipes flying everywhere? Try dealing with ZAS stunlocking you against a wall and killing you with the pipes being thrown around. Infact, the entire second half would only get WAY worse with ZAS. And, at this point, yeah, it's tied into way too fucking much to remove. There have been over 1000 PR's in the time between when it was first implemented and now. Sure, it's not going to get easier the longer it stays in, but given that it's absolutely "this is not possible" territory right now, it can't get that much worse.
-
Actually, revolution has since been entirely removed from the rotation. It was just broken for a while, then removed.
-
Allow IPC's to change their body color.
tigercat2000 replied to Spacemanspark's topic in Suggestions
Well, call me a liar or whatever, but after fucking with the organ system for hours to get something else to work, I got this to work. https://github.com/ParadiseSS13/Paradise/pull/2194 -
what 1. That's not true at all. 2. ... your point? 3. I think you are just contradicting yourself at this point
-
Allow IPC's to change their body color.
tigercat2000 replied to Spacemanspark's topic in Suggestions
It's definitely not that simple. I spent about an hour looking into this, and yes, I did try to just enable the has_body_color flag; It doesn't work. Why don't I just give a detailed explanation of why it doesn't work? So, first off- the HAS_BODY_COLOR flag does not actually control if you see the body color preference; it's snowflaked into races checks. But that's a simple solution. So, moving on. You select a body color; When your character is made, their r_skin, b_skin, and g_skin variables are set according to the color you selected. From there, it moves to the icon generating phase. Human base icons are now generated at the organ level; https://github.com/ParadiseSS13/Paradis ... an_icon.dm When humans want to make a new icon, first they check if anything has changed, or if they can use a cached icon that was already made. https://github.com/ParadiseSS13/Paradis ... #L231-L347 The specific part of this check that handles the actual base body, their arms, chest, head, so on, is here: https://github.com/ParadiseSS13/Paradis ... #L278-L297 That code calls organ.get_icon, which is here; https://github.com/ParadiseSS13/Paradis ... m#L72-L113 Colored parts are handled in organ.get_icon, specifically, right here; https://github.com/ParadiseSS13/Paradis ... on.dm#L108 If you notice, that part is behind an else; First, it has an if(skeletal), which means it returns the skeleton icon if that mob is supposed to be a skeleton. Then, second, it has an else if (status & ORGAN_ROBOT), which returns just the robot icon, without ever calling the part that blends skin tone. In order to fix this, we would have to add a color blend behind the else if (status & ORGAN_ROBOT) check; But, we can't do that. If we did, tajara and everything else with a skin color would color robotic limbs, which isn't desired. Is that a good enough explanation of why this isn't feasible? -
There is a quick way to solve this, you know. Just turn on antaghud. It prevents almost every method of respawn.
-
Allow IPC's to change their body color.
tigercat2000 replied to Spacemanspark's topic in Suggestions
Unbound/BestRP code is massively out of date with baydev, if I recall correctly. This would have been easy-- before the whole organ overhaul. -
Allow IPC's to change their body color.
tigercat2000 replied to Spacemanspark's topic in Suggestions
Uh, Bay doesn't have colorable IPC's, last I checked. I don't think this is even feasible; Skin color is handled at the external organ level; IPC's use robotic external organs; Robotic external organs do not get colored. -
It was a code bounty, and I will point out that only the head admins get to control where donation money is spent. In the end, it was refused.
-
It's been brought up before on tg when switching to ZAS gets dicussed, some players don't like the idea because "it means a random assistant can break a window in maintenance and space the entire station." Of course, bay had that 'issue' solved literally years ago, by placing emergency airlocks around, and it was never an actual issue in practice. Other players didn't like it because they felt like space was already too deadly - this coming from a time when you could down a cup of coffee and spacewalk even without your internals for a few minutes. And as for the PR going through - I mentioned the reasons why, earlier, when I was ranting. It goes through because a coder hasn't enough good sense to understand what he's actually doing with the changes, and because any feedback from the players is completely ignored and disregarded. Coders know best, and you don't get to disagree. Recall a long time ago, tasers used to require multiple shots to stun someone, with each shot slowing them down progressively further. It worked well, everyone was satisfied with it; fox decided it needed to change. After some voting where the playerbase said they didn't like the change, the coders gave a sort of 'who gives a shit what you think'; fox went back to the drawing board for a month or so while we were stuck with tasers we didn't want, then foisted a slightly new variation of the tasers we didn't want on us. And in playing recently, I've noticed a few other changes - emitter fields are no longer lethal, EMP's no longer damage mechanical limbs, many non-sec/non-antag weapons are extremely unrobust (including the crossbow which takes upwards of 8 shots to kill someone) that just makes the game feel horribly hugbox to me now, and that's in addition to a cowed and timid playerbase too scared of bans to actually have fun. Excuse me? What the hell are you talking about? LINDA was planned for months; There was a 500$ bounty of donation money out for anyone that ported it. All of the coders at the time, unanimously agreed that we needed and should switch to LINDA. It was priority 1, which was over -tg- mining along with a whole bunch of other things. Emitter fields haven't been touched in months. EMP's definately do damage mechanic limbs, I have no idea what you are talking about with that. Most importantly, this can't be stated enough times: This codebase is not a democracy. It is not on github for players to mob-mentality changes; It is on github for anyone to contribute to. We don't ban for no reason, we have very well established rules, and they are there for a good reason.
-
LINDA will never do that. Not without turning it to process every tick, or something ridiculous like that, which is "crash the server" territory.
-
Kevak, not that simple. We can't just swap back and forth between ZAS and LINDA; We would have to undo months of work to enable ZAS again, which isn't an accurate representation of how it would run
-
Intellicard AI's and pAI's: Hardsuit edition!
tigercat2000 replied to Spacemanspark's topic in Suggestions
This isn't feasible without porting bay's hardsuit system, and porting bay's hardsuit system would require someone willing to spend hours fucking with it, since it is so damn incompatible with everything. -
Alex is technically correct, the issues section is not just a bugtracker. But it does piss off most of the coders if you put feature requests in there, when we have a suggestions form, it gets a lot harder to sort through when there are tons of "what if"'s in there.
-
If no coders want to code it, and the person making the suggestion can't code it, nothing to do about it.
-
Most suggestions here die either because: A. No coder takes a liking to it B. It's simply not feasible with BYOND C. It's an insane idea.
-
https://github.com/ParadiseSS13/Paradise/pull/1919
-
Not quite that simple. The holopad speech code is a bit insane, iirc, and it bypasses the language systems with magic.
-
We actually could speed LINDA up fairly easily, just one value. However, the performance impact from that is extremely significant, and problems would arise as pipes stopped working as fast as atmospherics proceessed, and things like the rooms not equalizing would still be an issue. We aren't going to get ZAS-like atmospherics using LINDA, it's not designed to be that violent.