Accelerate the atmospheric spread

[Plotron]

 

Now that solution was closed / refused by the coders so im all hear as to an alternate solution that could be used all the while keeping the maintainers / coders happy.

That solution does not exist; It's probably the equivalent of perpetual motion machine: unnatainable.

 

So far I'm seeing a few arguments.

 

1. It modifies LINDA code, we want parity 'n shit.

A response has been presented: the modification was designed with the above in mind; the PR-maker claims it's just two lines of hook code.

 

Unless the other side refutes that and proves Jey to be wrong, this argument should not be included in this discussion.

 

2. Lag.

Response: apples to oranges unless tested in a live situation (CPU load vs load spikes vs perceptible lag).

The other side closed the PR and refused to test it in a live situation.

 

We should probably check if our testing methodology is correct.

 

 

I'm certainly a little bit biased here, but I feel like Jey is being treated with excessive skepticism.

 

[Regen]

 

While it is an interesting topic I am going to have to set my foot down.

Baseless accusations of "OH THE CODERS FUCKING LOVE THIS" is not only very rude, but also plain out wrong. It doesn't have to be "loved" it is simply just the best option. I enjoyed ZAS more than I enjoy LINDA, but I know that ZAS also killed our entire server as soon as someone did plasma canister + welding tool.

 

Keep the discussion on topic or this thread will be locked, it's pretty obvious that this is a giant salt mine for many, but understand that we, as a team running our server are not able to flick a wrist and make code happen. Our coders aren't paid programming graduates, most of them are self taught and do this as a hobby. Asking for something way beyond their abilities, then get angry because something is outside of the coders can't do it, is downright selfish and has no place here.

 

[Tauka Usanake]

Is it not possible to get a sort of hybrid solution made? Something that acts like both LINDA and ZAS, tiles and areas? For gas removal in a like area it goes by the LINDA tile system but when two different areas meet it goes full on ZAS and sucks everything in until a uniform pressure is met in the two areas. I know why coders don't like ZAS as much as LINDA but would something like this work maybe?

[Regen]

 

Is it not possible to get a sort of hybrid solution made? Something that acts like both LINDA and ZAS, tiles and areas? For gas removal in a like area it goes by the LINDA tile system but when two different areas meet it goes full on ZAS and sucks everything in until a uniform pressure is met in the two areas. I know why coders don't like ZAS as much as LINDA but would something like this work maybe?

 

From my original post.

 

Yes it is possible.

 

BUT

 

The real bottleneck is, are we capable? Again coders do this as a hobby, this is nowhere a job or obligation to them. This might be a huge project that nobody is willing to commit to.

 

[BiberDark]

 

As far as i read the addon to Linda, was only a little code, not changing the main at all. It would have speed up L-I-N-D-A 4 times for only 50 % increase in cpu.

It it is impossible to argue about Linda at this server. It gets locked closed or deleted. Linda is good for cpu and the rest of it is trash. You could remove it completly.

Thats Linda -_> http://www.allfunnies.com/wp-content/bl ... 50x600.jpg

 

[Jey123456]

 

Is it not possible to get a sort of hybrid solution made? Something that acts like both LINDA and ZAS, tiles and areas? For gas removal in a like area it goes by the LINDA tile system but when two different areas meet it goes full on ZAS and sucks everything in until a uniform pressure is met in the two areas. I know why coders don't like ZAS as much as LINDA but would something like this work maybe?

 

Its not really possible since they are 2 opposing concepts (ZAS is a room based atmospheric, LINDA is tile based), the closest to a hybrid solution i can think off, is exactly what i wrote and did a pull request about (LINDA for the short distance tile by tile atmospheric, air currents for the multitiles long distance atmospherics).

 

If you can think of an algorithm that can efficiently generate rooms dynamically (one of the biggest problem on ZAS was updating rooms) then please elaborate, you do not need to know coding to propose suggestions on this thread. Just understand basic cycle and logic. I can handle the coding if the idea is good. Just keep in mind that the reason why the air currents was not over the whole room was performance. Determining the constraint of a room require a lot of cycle every update, this is why i went with a compromise of determining the optimal air path in the room instead.

 

As far as coding knowledge / experience goes. Offcourse there's no class in byond that i know off, but ive been programming extensively in C++ for a little over 21 years now and am a university graduate in video game conception / programming. C++ is my main language obviously, but i am able to use a little over 10 programming languages without any problems (and i have yet to meet a language i could not learn in a matter of hour). Now for byond its a little different, its not the language im lacking in, its the standards expected by the paradise station maintainers. For that I'm counting on them to enlighten me since the requirements they generally complain about are not written down anywhere that i know off.

 

I don't have much free time i can dedicate to coding for paradise, but i enjoy the simplicity of byond language as a distraction so i do not mind spending a few hours every now and then on it so long as its on something that i find interesting (atmospherics for instance).

 

I do mind spending time only to be shutdown by the maintainers which is part of why this topic is here. It's partly to ask the playerbase what they want, but mostly to ask the maintainers what it is they expect of an atmospheric system.

 

I know that in the PR tiger said LINDA is working exactly how he wants it to be, but well, unless me and tiger have majorly different expectation of the atmospheric system (any slower/less dangerous than what we have would be no atmospheric system) i refuse to believe it really is what the maintainers believe.

 

[alexpkeaton]

 

I just want to take a moment to thank the coders.

 

You guys rock.

 

I'm a little sickened by this thread. Show some class. And don't speak for anyone other than yourself. As a player I don't give a shit about atmos other than not wanting it to lag my game. And I have a feeling I'm not alone there, but I won't speak for others.

 

And decisions are made by those who show up. No more faux math about deathmap disenfrachisement.

 

Coders are awesome.

 

[Shadeykins]

 

Is it not possible to get a sort of hybrid solution made? Something that acts like both LINDA and ZAS, tiles and areas? For gas removal in a like area it goes by the LINDA tile system but when two different areas meet it goes full on ZAS and sucks everything in until a uniform pressure is met in the two areas. I know why coders don't like ZAS as much as LINDA but would something like this work maybe?

 

From my original post.

 

Yes it is possible.

 

BUT

 

The real bottleneck is, are we capable? Again coders do this as a hobby, this is nowhere a job or obligation to them. This might be a huge project that nobody is willing to commit to.

 

I'm pretty sure what Jey wrote extends the reach of LINDA with no impact on latency and actually reduces bottlenecks, but it was outright denied by the maintainers.

 

This is not about people being unwilling/lacking the time to write atmospherics code,.

 

The primary issue here is that the proposed PR is "not up to standards" but no standards are being provided.

 

People can't work on atmospherics if their contributions to it won't even be humoured/tested.

 

Jey wants to address inefficiencies in LINDA and add functionality to it, but is being declined and then provided with no guidelines to work with.

 

That's pretty much what I'm getting out of this.

 

[Plotron]

 

I'm a little sickened by this thread. Show some class. And don't speak for anyone other than yourself.

Arguably Shadey went a bit overboard with the calculations.

 

That's pretty much what I'm getting out of this.

Yes, you summed it up well in your last post.

 

[BiberDark]

 

@ at Jay would it be possible to reduce cpu use if this tiles would be bigger. Instead 1*1 --> 2*2 or 3*3. This would reduce calculation by 75 % (only one instead of 4 times in a 2*2 room). To contribute to walls a filter that says tiles with walls always have a stable value of maybe 1 . So that they are filtered out in atmospheric calculations, i dont know how walls are handled at the moment to block air.

 

If this somehow works you could speed up the whole process 4 times and it would be equal to now.

 

The difference would be not the whole room is calculated like zaz , only a "sector" wich expands in each possible direction.

 

 

PS: Sorry i have no clue of coding

 

[necaladun]

 

Roughly two years ago, when I was an admin on bRP, I had a massive go at a player for starting fires due to the lag they caused. A discussion with this player about how that shouldn't be the case caused me to gain an interest in his code. This was back when ZAS was the only real game in town, and back then a simple fire could bring the server to a halt.

 

Now, atmos is easily in the best place it has ever been. Whats capable now without bringing the server to a grinding halt is amazing compared to only two years ago. It's obviously far from perfect, but for sheer playability, it is utterly amazing. Breaking a window in escape doesn't lag everyone, and firing a dragonsbreath round doesn't kill everyone in the room.

 

Optimizations and improvements are an ongoing thing, and there will always be a balance between function and CPU-Cycles - something which the players very rarely see, but the admin are all too aware of. The most functional and realistic atmospheric system is not the best, nor is the most optimized. It's up to the admin team to try to choose a balance between the two. And what we have now is lightyears ahead of what existed when we started.

 

It seems to me here that there is a lot of argument between the theory and the practical side of things. There is a huge difference between test servers and running a live server when it comes to CPU usage and lag. The maintainers are the most experienced with running a live server here, and are doing what they can to get the best solution.

 

Atmospheric code does not exist in a vacuum. (huehuehue). The CPU cost has to be balanced with the CPU costs of -everything- else, and this is something the maintainers have in mind. They're thinking of it balanced with everything else in not just the game, but the server itself. And as I said, they're people with years of experience in running and optimizing the code of Paradise.

 

 

 

Now, as I have the opportunity to speak as a player and member of the community rather than the admin team for once, I'll do it.

 

It'd go a long way to show a little bit of respect to the people who have spent literally years optimizing the code to the point where a small fire doesn't lag the entire server to oblivion. And maybe listen to them because they know what they're talking about, instead of the passive-aggressive bullshit I've seen here.

 

[Professor Cupcake]

 

Huh, this thread is still going. Well, guess I'll drop an observation here.

listen

It looks to me like everyone's listening, it's just nobody's talking. At least, not about the thing that they are listening for. It's just a lot of prattle around the subject, not about it.

As I see it, there are three questions asked multiple times here that have yet to be answered:

 

1. What are the "standards" that the maintainers expect from the code? Even if the answer is that it's unexplainable, an answer would be nice.

2. Has anybody other than the creator tested this? If no, why not? If yes, what were the results, and what do they mean for it?

Just what exactly is the argument? Are we negotiating a compromise of this? Are we arguing a straight yes/no? Most of the arguments I've seen so far are about the related topic of CPU cycles, which is not the subject here.

 

There have been times when the discussion has gotten frustratingly close to addressing these, but has yet to do so.

So enough ranting about whether ZAS or LINDA is your favourite pony, and enough about the difference between CPU load and frames. Back to the subject, which, IIRC, was about increasing the speed of long-range atmospheric spread, and the suggestion of an additional piece of code to attempt to do so.

 

[Jey123456]

 

@ at Jay would it be possible to reduce cpu use if this tiles would be bigger. Instead 1*1 --> 2*2 or 3*3. This would reduce calculation by 75 % (only one instead of 4 times in a 2*2 room). To contribute to walls a filter that says tiles with walls always have a stable value of maybe 1 . So that they are filtered out in atmospheric calculations, i dont know how walls are handled at the moment to block air.

 

If this somehow works you could speed up the whole process 4 times and it would be equal to now.

 

The difference would be not the whole room is calculated like zaz , only a "sector" wich expands in each possible direction.

 

 

PS: Sorry i have no clue of coding

 

It's Jey, and , to answer your question, it would not. First thing first, it would require much larger changes to LINDA (which are a big no-no from what i could gather from the maintainers). But on top of this, would not really change the actual calculations since the heaviest part of the calculations is to determine which tiles to work on (changing it to 2x2 or 3x3 would reduce the share_air part of the deal, but would increase exponentially on the air group generations and canatmopass tests along others).

 

Plus it would not really address the largest problem on linda, which is an exponential slowdown of air movement by distance (instead of by volume). A small 10x1 corridor with a breach at one end would only see 0.09kpa drain from the other end and would very slowly increase as the first tiles finally empty out. Changing it to a 2x2 or 3x3 square would indeed divide the issue, but the actual problem would remain just on 2-3 larger dist.

 

Now offcourse if someone can think of a way to handle those 3x3groups with no changes to LINDA and less than 3times the cpu cost, it would be a step in the right direction.

 

[Plotron]

 

 

• Has anybody other than the creator tested this? If no, why not? If yes, what were the results, and what do they mean for it?

• Just what exactly is the argument? Are we negotiating a compromise of this? Are we arguing a straight yes/no? Most of the arguments I've seen so far are about the related topic of CPU cycles, which is not the subject here.

 

There have been times when the discussion has gotten frustratingly close to addressing these, but has yet to do so.

So enough ranting about whether ZAS or LINDA is your favourite pony, and enough about the difference between CPU load and frames.

2. It has been tested on a few configurations. Independent tests on weaker configurations reported a higher CPU load. A question arose whether this is a fair comparison at all - and especially - how these results would translate into real-world situation perceptible lag.

3. CPU cycles are relevant here, because point 2. depends on it. We want to know what the perceptible lag would feel like, but it hasn't been tested. The PR was rejected on [standard] theoretical grounds that are being debated to this day in the form of CPU load, cycles and spikes.

 

Granted, empirically speaking it'd be optimal to conduct a proper experiment that would account for all the variables. It's not going to happen, though.

 

[Jey123456]

 

so after giving it some more thought, i had an idea on how to tweak my PR that should satisfy the cpu worries (altho i still firmly believe they are unfounded, but well, its not like the maintainers seem to particularly want a faster atmospherics so i guess ill put all the chances on my side )

 

I'm thinking about removing the wind effect from LINDA all together and slow it down to 10 second per cycle split in 20 0.5s cycle (essentially drop the cpu usage from linda by a factor of 5 and split it over a lot of small increments to camouflage the very long interval and reduce risk of lag spikes from them). This obviously would mean that LINDA would not be fast enough to handle anything but very short range / low pressure equalization but thats all i need it to do for my plan to work out.

 

To that, i would add a special independent call in the airmaster to do a turf as soon as possible (next 0.5 interval) that would be added to doors state change and wall destruction (everything that would create an instant air state change, creating a wall change the air paths but does not actually create any new path so theres no need to instant refresh here)

 

With LINDA cpu usage essentially out of the way, i could tweak the air currents system to run at a much faster rate (hell, even every 0.5 sec would be possible), since the air currents system by itself is much lighter than LINDA due to it not operating with the same kind of precision, it means that we can use it to greatly accelerate the large air equalisation (anything above the treshold) pretty quickly, and then let LINDA do the finishing touch slowly for the last few spots that have a small pressure / temperature difference.

 

 

I did not try it out yet, its only something i thought off while taking my walk, but im confident that i could end up with a system that is faster than LINDA for high pressure differencial equalisation over a room, faster on atmospheric spread, more realistic winds (no wind pushing you back and forth on the same 2 tiles). At the cost of less cpu usage than LINDA currently use in similar scenario and slower low pressure difference equalization.

 

What it would mean is that the cost of reducing the cpu for LINDA while accelerating the important / large spreads would be that rooms with 106kpa on one side and 102 kpa on the other would equalise about 5 times slower than right now, but room with 100kpa on one side and 50kpa on the other would equalize much faster than now.

 

I believe it would be a good compromise since small pressure / temperature difference do not matter nearly as much as big ones, but before i go out of my way and spend another few hours on that, id like some kind of confirmations that it would at least be properly considered once i do the pull request for it. If possible id also like some thought from the maintainer as to what to keep an eye out as far as the mythical standards goes. I know tiger mentioned having the define in air_define but im sure theres a lot of other things out there that aren't really mentioned anywhere and yet expected of PR

 

[Crazylemon]

 

I got off my butt and did the thing

It's not nearly complete, but it should do the trick I hope.

 

[Jey123456]

 

I got off my butt and did the thing

It's not nearly complete, but it should do the trick I hope.

 

its a start at least. Hopefully maintainers will add to it.

 

[Fox McCloud]

 

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).

 

The primary issue here is that the proposed PR is "not up to standards" but no standards are being provided.

 

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.

 

[Jey123456]

 

The test you did was invalid as far as cpu usage comparison goes , since in one test your cpu was not overloaded and the other was (which meant a lot of extra cycles wasted trying to catch up/ thread context switch in the os etc). If you want to do a proper comparison test, do it on a machine that can actually support it (not saying it shouldnt run on your machine, the latest version should be just fine for said test since i fixed the long duration execution block issue). If you use identical test scenario youll see that its not more than twice the cpu, its around 180%.

 

The lag from the cpu increase was already contested more than once for the very simple reason that even under extremely heavy atmospheric load on live, cpu is not used anywhere near full capacity. The version of the PR just before it was closed already included a fix that is very likely to reduce the lag not increase it (increase cpu yes, but spread over multiple execution blocks.

 

But anyway this topic is not about the PR itself, its about what is wanted for an atmospheric related PR to be considered more than just run once on some machine that could not be further away from live spec.

 

Increasing the rate of LINDA to 0.5 sec would be stupid, it would not fix the problem, it would still be exponentially slow according to the distance instead of volume. The only part where the 4x speed would really matter from switching that, is short distance (< 10 tiles). Wind speed (amount of air that pass by a tile) does not depend on how far it is to the low pressure point, it depend on how much volume there is in between (ok its more complicated than that once you go into fluid dynamics but for the sake of keeping it simple lets not)

 

Not to mention why would switching linda to 4x be even mentioned (400% cpu) when 180% cpu for 4x spread speed (and nearly linear speed over distance and instead affected by room dimensions) was shut down for lag reason ?

 

As for what i had in mind for my next PR (the one im still waiting for some kind of approval on the concept before i actually take the time off my free time to do it, see page 4 last post). There is no changes directly to linda except the same exact 2 lines to hook in from the PR that was closed. The only changes to the current atmospherics would happen in the air_process to slow it down even further

 

A quick tldr in case you dont feel like reading it, the result would be lower cpu cost across the board, slower low pressure difference equalization and faster high pressure difference equalization.

 

The slower low pressure difference equalization (say 106 to 102kpa in a room) is the price that would be paid for the lower cpu and radical increase in high pressure difference (say 100kpa to 50kpa in a room)

 

Edited January 18, 2016 by Guest

[Fox McCloud]

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.

[Jey123456]

 

I am indeed not willing to accept as true that you tested the last commit before you closed the PR under a lag scenario on both current version and the PR (cpu time is only meaningfull if its either too long per execution block, or the total represent 100% of the realtime). I'm willing to bet that if given an half decent computer (a third of live core speed is enough) my PR would actually lag less under heavy atmospheric work than the current version. I have yet to see live atmospheric code go above 12% cpu and any lag that come from it is not from too much cpu usage, but too much at once. Anyway i disgress

 

The discussion is not about my old PR but my next one. I made this topic in the first place to gather idea on various approach (didnt pan out much on that side) and a general feel of what people wanted / if it was wanted.

 

 

Read the concept at the bottom of page 4, this is the one i want us to discuss before i actually go and take hours off my free time for it.

 

[Fox McCloud]

 

he discussion is not about my old PR but my next one. I made this topic in the first place to gather idea on various approach (didnt pan out much on that side) and a general feel of what people wanted / if it was wanted.

 

 

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).

 

[Jey123456]

 

he discussion is not about my old PR but my next one. I made this topic in the first place to gather idea on various approach (didnt pan out much on that side) and a general feel of what people wanted / if it was wanted.

 

 

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).

 

What part of no changes to LINDA are you misreading ? as far as i know, the air_process call is not part of LINDA but paradise's (obviously LINDA has its own version since it kinda need a process manager) and its the only actual file that would get more than the 2 hook insertions in that PR.

 

 

My suggested PR is indeed similar to my old one in the sense that it reuse the same principle with very different settings inside to result in a lower cpu usage all across the board (at the cost of slower low pressure difference equalisation) To match your complain about CPU usage. I'm pretty confident i can both increase the rate at which most of the air equalize and drop the actual cpu usage of the whole atmospheric system down to 80% of what linda currently use (maybe even less). No modifications to LINDA are required for that, merely a slowdown in the airprocess so that my air currents code can handle the heavy lifting and leave the fine tuning to LINDA

 

[Fox McCloud]

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.

[Jey123456]

 

please show me where those large changes to LINDA are, i can link you the diff clearly showing only 2 line change in linda.

https://github.com/ParadiseSS13/Paradis ... 3214/files

see the LINDA folder changes,

1 line insertion in LINDA_system.dm

1 line insertion in LINDA_turf_tile.dm

 

Those 2 lines are the only changes to LINDA in that commit, beyond that, its in Processes/air.dm . Now if you want to call it part of linda, then fair enough, but there is no functional change to the air process either, merely splitting calls.

 

Its not like the data is not out here. 99% of my changes are internal to the aircurrents.dm file exactly to avoid maintainers complaining about lots of LINDA modifications. This code does not modify LINDA in anyway, it modify the air process and add aircurrents.

 

The one and only real argument you have that i have no problem acknowledging. Is that it use more cpu, yes it does, 180% the cpu for 400% the speed, I still wont agree that it correlate with more lag but this is obviously too high for you, hence why i brought up an alternate way to achieve my goal with 80% or less cpu usage compared to the current LINDA and still atmospheric spread acceleration.