Glowcaps are red mutant glowshrooms. They can be used in all the same ways normal glowshrooms can, but they also boast a special feature.
When you finish eating a glowcap, the batteries of any electronics you have on/in you are recharged up to potency%.
Works pretty well. If it can't GC something, it'll just del() it and be done.
Speed is amazing, holy shit.
New procs you should be aware of:
qdel(atom/movable) - sets up an object for garbage collection. Call this rather than del(atom/movable).
atom/movable/Destroy() - called right before the object is GC'd, so it still has a loc. Also called if the object is del()'d.
new controller - garbage.dm has all the details on this. Basically it nulls all references on GC'd objects and force del() them if necessary.
Generally speaking, objects should use Destroy() for behavior prior to deletion rather than Del(). You should also always call the parent so the object gets the right gc_destroyed var set.
ISSUES:
Tries to GC mobs atm. This actually works for new players, not so much for humans/monkies/simple_animals/anything. I'm guessing it needs to clear out their mind and HUD and maybe other things.
Gibbing is really bugged. It works, but the overlays just sit there for awhile and ugh. I'm very tempted just to del() mob/living and mob/camera and call it a day.
qdel() equipment doesn't unequip the item.
Pipes don't generally GC correctly. Debugging suggests they get referenced in many pipenets and that isn't cleared properly. However some do work fine. Need assistance here.
Bots don't GC, probably in the radio controller.
Lots of other shit doesn't GC but it's hard to find them because of the pipe spam.
I think I'm calling Destroy() twice by accident.
Testing has revealed that it reduces the sluggishness of the game, though it will spike from lag when the singularity is loose. Thanks to ChuckTheSheep for suggesting it.
Server owners who want to keep set background enabled can do so by changing the define.
Fixes the bug with effects/glowshroom not glowing when placed.
They don't spread infinitely: The odds of a shroom spreading decreases with each generation. Because they're sane now and not virally-spreading fungal horrors, they've been changed to spread on normal station floors and not just the asteroid.
The spreading glowshrooms acquire the parent's stats, with some mutations.
The delay variable is now based off of production, and goes DOWN with better stats instead of GOING UP.
-Removes unnecessary (copy-pasted) code bits in walking mushroom/killer tomato code in grown.dm
Comments for lighting:
Like sd_DAL (what we used to use), it changes the shading overlays of areas by splitting each type of area into sub-areas
by using the var/tag variable and moving turfs into the contents list of the correct sub-area.
Unlike sd_DAL however it uses a queueing system. Everytime we call a change to opacity or luminosity
(through SetOpacity() or SetLuminosity()) we are simply updating variables and scheduling certain lights/turfs for an
update. Actual updates are handled periodically by the lighting_controller. This carries additional overheads, however it
means that each thing is changed only once per lighting_controller.processing_interval ticks. Allowing for greater control
over how much priority we'd like lighting updates to have. It also makes it possible for us to simply delay updates by
setting lighting_controller.processing = 0 at say, the start of a large explosion, waiting for it to finish, and then
turning it back on with lighting_controller.processing = 1.
Unlike our old system there is a hardcoded maximum luminosity. This is to discourage coders using large luminosity values
for dynamic lighting, as the cost of lighting grows rapidly at large luminosity levels (especially when changing opacity
at runtime)
Also, in order for the queueing system to work, each light remembers the effect it casts on each turf. This is going to
have larger memory requirements than our previous system but hopefully it's worth the hassle for the greater control we
gain. Besides, there are far far worse uses of needless lists in the game, it'd be worth pruning some of them to offset
costs.
Known Issues/TODO:
admin-spawned turfs will have broken lumcounts. Not willing to fix it at this moment
mob luminosity will be lower than expected when one of multiple light sources is dropped after exceeding the maximum luminosity
Shuttles still do not have support for dynamic lighting (I hope to fix this at some point)
No directional lighting support. Fairly easy to add this and the code is ready.
When opening airlocks etc, lighting does not always update to account for the change in opacity.
Explosions now cause lighting to cease processing temporarily.
Moved controller datums to the code/controllers directory. I plan on standardising them.
"Master","Ticker","Lighting","Air","Jobs","Sun","Radio","Supply Shuttle","Emergency Shuttle","Configuration","pAI" controller datums can be accessed via the debug controller verb (used to be the debug master controller verb)
Supply shuttle now uses a controller datum. Shuttles tend to arrive up to 30 seconds late, this is not a bug.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@4537 316c924e-a436-60f5-8080-3fe189b3f50e
Committing this early to allow pete to commit something involving the .dme file which would probably conflict otherwise.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@4514 316c924e-a436-60f5-8080-3fe189b3f50e
Incoming
bear1ake
Firecage
Remie Richards
Razharas
MrPerson
Giacomand
Cheridan
elly1989@rocketmail.com
johnsonmt88@gmail.com