Mostly ports /tg/'s method of seeding submaps into specific z-levels.
Due to the low number of submaps present, all of the PoIs are guaranteed to spawn. As more are added, this should fix itself.
Also fixes various bugs with surface tiles, hopefully.
Adds some documentation to the map file system.
Adds a new 'plane' map, ideal for testing PoIs by loading them manually.
Makes space heaters glow orange.
Adds a new grille type for fancy surface windows.
Adds self planting hydro trays/dirts if a seed is on top of them when the map is loaded.
New lighting system is needed to handle updating literally 14k+ tiles whenever the sun moves. The straight port seems to have had no adverse effects from what I could see. Don't know if it's more performant but it doesn't seem to be less.
I didn't expect the latter would be needed for the former.
As requested by a few staff members, this serves to keep the staffwho list more representative of who is actually available to help.
The current inactivity timer is rather generous so hopefully this won't impede admins who are actually there.
* No changes to lighting logic at all, it still processes sources, corners, and overlays in that order.
* Also optimized the initial creation of lighting overlays, and made it include CHECK_TICKs
* Removed the statistics gathering, at least for now.
In addition to fixing the problem, it makes sense. The observer pattern is overkill for an object type we own; doing it directly in Destroy() is more efficient.
In addition to fixing the problem, it makes sense. The observer pattern is overkill for an object type we own; doing it directly in Destroy() is more efficient.
* Hooks up informing Master the gameticker actually starts and stops the round subsystems will actually fire! What ho!
* We should convert the gameticker as an MC subsystem someday, and probably completely rewrite it while we are at it becuase it is crazy. But this should bridge the gap until then.
* Optimized garbage collection of radiation sources until we get qdel() hints.
* Made the RADIATION_LOWER_LIMIT configurable (option for people to save some cpu time)
* Added some comments and broke the proccessor into separate procs for profiling purposes
* Added a changelog.
* The performance of the radiation controller as-is was not fast enough for inclusion in production servers, but it has some nice featuers, so rewrote it to be more performant.
* Instead of storing the radiation strength for every turf, we only store the sources of radiation, and calculate the strength only for mobs who might be in range.
* Old method was ray-tracing to every turf in range whether anything was there to be irradiated or not. Could be hundreds of turfs. New method only lazily calcualtes strength at a turf if we actually need to know it. Often times this is zero turfs if nobody is standing in engineering.
* Removed the automatic processing of objects with "rad_power" set. Objects are responsible for calling the repository to create/update their radiation sources. Saves some extra overhead that in practice was redundant with other process controllers.
* Also tweaked to be more respectful of qdel'd objects and added some comments.
* Creating new objects is cheap, in fact comparable to the cost of getting it out of the pool, so it doesn't help there.
* Placing items in the pool is far more expensive than letting them garbage collect due to the resetting of vars and such.
Controller with deferrals and SCHECKs to be specific. Won't lag while updating the sun, weather, or temperature.
Also moved some vars around. Namely the planet walls are stored on the planet, not in the weather_holder.
Planets now have their own turfs, the controller 'gives' them to the planets each cycle if there are any unallocated turfs in the global lists, to avoid iterating over other planets' turfs if you have more than one, then cuts the lists if you were crazy and some turf added some invalid type. This saves us type-checking in the for() loops later to make them crunch faster. The former operation should only happen once at the start of the game (and maybe very rarely when turfs are added/removed from a map during the game).
With regards to the temperature updates, rebuilding the zone entirely is an intensive operation. Instead we can use this new cheaty proc to do it from over here. ZAS code outside ZAS oh noooo. Well, the option is to snowflake this case into ZAS which is maybe worse?
Only downside to all this is that if you manually set weather and time it might take between 1-60 seconds for the controller to get around to checking if you wanted to update it. That's not that big a deal. If you really want you can now debug that controller and call doWork on it.
* If the "scheduler" controller is restarted by the process scheduler for
any reason, it will start throwing runtimes every status panel update
because the new replacement instance doesn't initialize its list of
schedule tasks.
* Fix that by copying over the unfinished list from the old instance, but
doing some safety checks to make sure it doesn't copy over bad stuff.
* Any nulls present in the mob_list would cause a runtime when checked if they are gcDestroyed. Add a null check.
* Noticed that the object controller has the same bug, might as well fix now too.
Adds what I hope to be able to make a sort of intelligent system that in the future will be able to decide what event would be the best to choose at any given moment. A lot of this will probably get rewritten later.
You can use the new debug verb Show GM Status to have it show some data about itself, such as player activity across the whole server.
Currently, the system cannot actually run any events, as they don't exist and it's been disabled. The plan is to have the events themselves do most of the heavy lifting for stuff like set-up and weights.
When the overarching system is more refined, a lot of new events will be madem and most of our old ones will be ported, and improved upon too.
For now, adding this lets me see what the system thinks about a round that has people playing on it and not just me on a test server.
``/mob/dead/observer`` -> ``/mob/observer/dead``
``/mob/eye`` -> ``/mob/observer/eye``
Reason being that they are similar in that they both don't interact with
the world in any way. Some procs were shared, some checks as well, and
it overall makes more sense this way. Plus, there were no ``/mob/dead``
mobs.
- Better implementation of #10714
- This fix corrects the issue by merging pipenet process to machinery process to ensure order of execution doesn't change randomly. This shouldn't have any performance effect as pipenet process doesn't have much work anyway (not to be confused with air process that runs ZAS, this one only called process() on each pipenet). Screenshot of profiler (pipenet process highlighted, idle server with one player, engine set up) http://i.imgur.com/ecCg6rS.png
- Unlike previous fix, this does not come with various game-affecting side effects, players shouldn't see a change (except for the fact that odd fluctuations introduced by devmerge disappear). Previous fix buffed engine output as side effect, and caused one TEG to generate considerably more than second TEG, which caused TEGs to begin sparking despite overall output being below 1MW.
