What is the most efficiant way of making an air system that lags as little as possible?
1. Looping though every relavent turf using a simple calculation to work out where it should spread. (Tried. Lagged.)
2. Looping though every relavent turf and evenly spreading it's contents to the turfs around it and itself. (Tried. Lagged.)
3. Somehow making the program have a list of all the relavent turfs in the room and all objects effecting the room (ie airtight walls), and running some code to reworkout the air (speard it evenly) in the room or rooms (can join and spit). (I'd need help with this).
4. Making individual objects for every particle and having them run a looping... Actualy, never mind. (Tryed. Locked up. Crashed.)
5. Something else. Help. Please.
The best option is, of course, magical fairy dust, but I seem to have ran out, so I didn't lis it.
Someone help me please?
ID:163326
 Sep 9 2007, 11:12 am
|
|
I have no clue what that first statment is meant to mean.
You chose option 3. I've been thinking about option 3 for a while (a while being about 4 minutes and 12 seconds before I posted it) and I'm not so sure I know the most efficient way of checking for rooms is. Once I get that room dividing thing working I'll be able to do exaclty what I want, however I still don't know HOW to check for rooms. Once I do work out how It'd need to be called every time the map changes the rooms involved. What makes you think I'm a novice? | |
Atomixkid wrote:
I have no clue what that first statment is meant to mean. Maybe it's because you rely on magical fairy dust :P | |
Atomixkid wrote:
What makes you think I'm a novice? The fact that you tried all the ones you knew would lag the game out, instead of choosing the only two obvious ways. | |
Idea: Use path finding to see if the walls can be followed untill the start wall is reached.
Problem: I wouldn't be able to list al the areas inside it. Any ideas on how to solve this problem? | |
Here's something you could try.
Each tick, pick a small *random* subset of the total available turfs and put them in an "important" list. Each tick you look at N turfs; thus, in a second you look at 10N turfs, in 10 seconds 100N turfs. But also, if something relevant happens -- like a wall is breached or sealed -- then you add *that* turf to the "important" list too. When you start processing the "important" list for a given tick, you change it to the "processing" list (which will remain fixed while you process it) and clear the "important" list (which will accept any new "important" turfs for the next round of processing). As you are evaluating the "processing" list, if a turf has a major effect on the turfs around it (say, oxygen level changes by 10% or more), add them to the new "important" list. During processing, you update turfs to have accurate oxygen/pressure/flow/whatever, according to their surrounding turfs. There is some chance that this could cause lag if the list gets too long, but since you are always working with two lists -- the fixed "processing" list, and the varying "important" list, it's okay to sleep a tick after processing every N items in the fixed list. This would slow down the overall propagation of atmospheric effects, but depending on your goals for the game, that might be acceptable. By combining random updates with forced updates of the turfs that you know need special attention, you can possibly get a reasonably realistic simulation, while still only looking at a small fraction of the total turfs in the world. It's something to consider, anyway. | |
Ter13 wrote:
Heh. You can't think atomically. You have to think Datumically. Right. You know what the problem is with them goddamn datums? You create one, and suddenly you're all hooked to it. You create a datum to realistically handle the calculations behind the area's air flow, but oh, wait- you also need to calculate the oxygen level! So you create a datum for that too. But then you just remembered- you need to find a way to handle the outcome of breathing! And suddenly you have over forty datums operating at once. Bah! P.S. Did I mention the datums for dying, eating, sleeping, laving, and the ever-forgotten datum of the third law of thermodynamics? | |
DivineO'peanut wrote:
And suddenly you have over forty datums operating at once. Bah! You can assign multiple procs to one datum, so your single datum can control all of these functions at once. Sorry. -- Data | |
So... Datums are like crack? Hang on... gotta get my fix...
Anyway, that's just spaghetti code. Nothing to do with using datums. Datums are one of the most useful parts of BYOND. They basically make complex functions much easier to manage than creating a bunch of procs all over the place. I use lots of them. I use them for anything that manages both data and a function that is inconvenient or too heavy to encapsulate in the default atoms. For instance, I actually made a movement engine that uses datums to define rules for movement, and acts as an interface between mobs and clients. The cool part about this datum is that you can plug AI into it as well, and it will function the same way on a /mob as if a client were controlling it. Essentially, this saves me time and makes the game much more efficient and logical than just defining AI for NPC characters inside of the mob. This also makes taking over an NPC's control possible. =P | |
Ter13 wrote:
... See, that's exactly the problem here. Datums are great for AI interface, I agree, since you often need to override procedures and the flow of events, but movement? As complex and dynamic as it may be, movement should be handled with a few variables manipulating it, rather than a datum. If you need to override more than a variable or two to change the way something moves, I argue your movement system is terribly designed. | |
When the game starts, divide up the rooms into airflow regions. These regions are actually datums that contain a list of turfs. These Airflow Regions should also have a list of "breaches", or areas that link to other areas. Only small openings should be counted as a breach, unless the current area is a corridor, or a ventilation shaft.
Doors can also link to breaches, and actually close and open the breach as they open and close. When the airflow region is breached to an area of lesser pressure, the pressure will try to equalize. If the pressure is low enough, the area will actually suck objects toward it. Remember that the air can only flow at a certain speed due to the size of the breach.
This is all easily done, but you really gotta work at it to get it right.
It's not to be attempted by novices. I've only seen three or four people get it right in the last few years. Gughunter and Exadv1 cheated. They didn't use actual airflow mechanics. Guggems used pathfinding, and Exadv1 used line of sight and turf-based gas pressure. Gug's is better than Ex's, and Ex's was crap. Mine's no better than Gug's, but I don't think his supported changeable maps.