From 78db65f13f5bfea14f8910977b8919d6b2fdc0da Mon Sep 17 00:00:00 2001 From: spookerton Date: Fri, 15 Apr 2022 13:09:48 +0100 Subject: [PATCH] move some readme files in .dm sources into .md --- code/ZAS/README.md | 32 ++++++ code/ZAS/_docs.dm | 28 ----- code/modules/ai/{__readme.dm => README.md} | 21 ++-- .../{__lighting_docs.dm => README.md} | 16 +-- .../mob/freelook/{read_me.dm => README.md} | 100 +++++++++--------- .../{_description.dm => README.md} | 0 code/modules/overmap/{README.dm => README.md} | 0 .../research/{rd-readme.dm => README.md} | 62 +++++------ .../{sort_string_readme.dm => README.md} | 0 maps/{_map_system_readme.dm => README.md} | 0 maps/submaps/{_readme.dm => README.md} | 0 polaris.dme | 1 - 12 files changed, 127 insertions(+), 133 deletions(-) create mode 100644 code/ZAS/README.md delete mode 100644 code/ZAS/_docs.dm rename code/modules/ai/{__readme.dm => README.md} (98%) rename code/modules/lighting/{__lighting_docs.dm => README.md} (93%) rename code/modules/mob/freelook/{read_me.dm => README.md} (98%) rename code/modules/modular_computers/{_description.dm => README.md} (100%) rename code/modules/overmap/{README.dm => README.md} (100%) rename code/modules/research/{rd-readme.dm => README.md} (98%) rename code/modules/research/designs/{sort_string_readme.dm => README.md} (100%) rename maps/{_map_system_readme.dm => README.md} (100%) rename maps/submaps/{_readme.dm => README.md} (100%) diff --git a/code/ZAS/README.md b/code/ZAS/README.md new file mode 100644 index 0000000000..e6db231e3a --- /dev/null +++ b/code/ZAS/README.md @@ -0,0 +1,32 @@ +# Zone Air System + +This air system divides the station into impermeable areas called zones. + +When something happens, i.e. a door opening or a wall being taken down, zones equalize and eventually merge. + +Making an airtight area closes the connection again. + +## Control Flow + +**Every air tick**: + +- Marked turfs are updated with update_air_properties(), followed by post_update_air_properties(). +- Edges, including those generated by connections in the previous step, are processed. This is where gas is exchanged. +- Fire is processed. +- Marked zones have their air archived. + +## Important Functions + +**air_master.mark_for_update(turf)** +- When stuff happens, call this. It works on everything. You basically don't need to worry about any other functions besides CanPass(). + +## Notes for people who used ZAS before + +- There is no connected_zones anymore. + +- To get the zones that are connected to a zone, use this loop: + +``` + for(var/connection_edge/zone/edge in zone.edges) + var/zone/connected_zone = edge.get_connected_zone(zone) +``` diff --git a/code/ZAS/_docs.dm b/code/ZAS/_docs.dm deleted file mode 100644 index 382f1f0abb..0000000000 --- a/code/ZAS/_docs.dm +++ /dev/null @@ -1,28 +0,0 @@ -/* - -Zone Air System: - -This air system divides the station into impermeable areas called zones. -When something happens, i.e. a door opening or a wall being taken down, -zones equalize and eventually merge. Making an airtight area closes the connection again. - -Control Flow: -Every air tick: - Marked turfs are updated with update_air_properties(), followed by post_update_air_properties(). - Edges, including those generated by connections in the previous step, are processed. This is where gas is exchanged. - Fire is processed. - Marked zones have their air archived. - -Important Functions: - -air_master.mark_for_update(turf) - When stuff happens, call this. It works on everything. You basically don't need to worry about any other - functions besides CanPass(). - -Notes for people who used ZAS before: - There is no connected_zones anymore. - To get the zones that are connected to a zone, use this loop: - for(var/connection_edge/zone/edge in zone.edges) - var/zone/connected_zone = edge.get_connected_zone(zone) - -*/ diff --git a/code/modules/ai/__readme.dm b/code/modules/ai/README.md similarity index 98% rename from code/modules/ai/__readme.dm rename to code/modules/ai/README.md index 85b49ec6cb..55eb059d97 100644 --- a/code/modules/ai/__readme.dm +++ b/code/modules/ai/README.md @@ -1,5 +1,5 @@ -/* -[Summary] + +# Summary This module contains an AI implementation designed to be (at the base level) mobtype-agnostic, by being held inside a datum instead of being written into the mob directly. More specialized @@ -11,7 +11,7 @@ When designing a new mob, all that is needed to give a mob an AI is to set its 'ai_holder_type' variable to the path of the AI that is desired. -[Seperation] +## Seperation In previous iterations of AI systems, the AI is generally written into the mob's code directly, which has some advantages, but often makes the code rigid, and also tied the speed of the AI @@ -46,7 +46,7 @@ in the future. delay, as the ai_holder might not exist yet. -[Flow of Processing] +## Flow of Processing Terrible visual representation here; AI Subsystem -> Every 0.5s -> /datum/ai_holder/handle_tactics() -> switch(stance)... @@ -92,7 +92,7 @@ with each other, as opposed to having individual tick counters inside all of the ai_holder instances. It should be noted that handle_tactics() is always called first, before handle_strategicals() every two seconds. -[Process Skipping] +## Process Skipping An ai_holder object can choose to enter a 'busy' state, or a 'sleep' state, in order to avoid processing. @@ -117,7 +117,7 @@ from processing the other ai_holders until the sleep() finishes. Delays on the mob typically have set waitfor = FALSE, or spawn() is used. -[Stances] +## Stances The AI has a large number of states that it can be in, called stances. The AI will act in a specific way depending on which stance it is in, @@ -138,7 +138,7 @@ module folder and are mostly self contained, however some files instead deal with general things that other stances may require, such as targeting or movement. -[Interfaces] +## Interfaces Interfaces are a concept that is used to help bridge the gap between the ai_holder, and its mob. Because the (base) ai_holder is explicitly @@ -168,7 +168,7 @@ ranged attack. For simple_mobs, they can if a ranged projectile type was set, where as for a human mob, it could check if a gun is in a hand. For a borg, it could check if a gun is inside their current module. -[Say List] +## Say List A /datum/say_list is a very light datum that holds a list of strings for the AI to have their mob say based on certain conditions, such as when threatening @@ -181,7 +181,7 @@ mercenaries and fake piloted mecha mobs. The say_list datum is applied to the mob itself and not held inside the AI datum. -[Subtypes] +## Subtypes Some subtypes of ai_holder are more specialized, but remain compatible with most mob types. There are many different subtypes that make the AI act different @@ -196,6 +196,3 @@ To use a specific subtype on a mob, all that is needed is setting the mob's ai_holder_type to the subtype desired, and it will create that subtype when the mob is initialize()d. Switching to a subtype 'live' will require additional effort on the coder. - - -*/ \ No newline at end of file diff --git a/code/modules/lighting/__lighting_docs.dm b/code/modules/lighting/README.md similarity index 93% rename from code/modules/lighting/__lighting_docs.dm rename to code/modules/lighting/README.md index 049bfe6c88..8e7569fc5b 100644 --- a/code/modules/lighting/__lighting_docs.dm +++ b/code/modules/lighting/README.md @@ -1,8 +1,5 @@ -/* -BS12 object based lighting system -*/ +# BS12 object based lighting system -/* Changes from tg DAL: - Lighting is done using objects instead of subareas. - Animated transitions. (newer tg DAL has this) @@ -20,12 +17,10 @@ Changes from tg DAL: - Areas have luminosity set to 1 permanently, no hard-lighting. - Objects inside other objects can have lights and they properly affect the turf. (flashlights) - area/master and area/list/related have been eviscerated since subareas aren't needed. -*/ -/* -Relevant vars/procs: +## Relevant vars/procs -atom: (lighting_atom.dm) +### atom: (lighting_atom.dm) - var/light_range; range in tiles of the light, used for calculating falloff - var/light_power; multiplier for the brightness of lights - var/light_color; hex string representing the RGB colour of the light @@ -42,7 +37,7 @@ atom: (lighting_atom.dm) - Updates the light var on this atom, deleting or creating as needed and calling .update() -turf: (lighting_turf.dm) +### turf: (lighting_turf.dm) - var/list/affecting_lights; list of light sources that are shining onto this turf - proc/reconsider_lights(): @@ -54,7 +49,7 @@ turf: (lighting_turf.dm) - Create lighting overlays for this turf -/atom/movable/lighting_overlay: (lighting_overlay.dm) +### /atom/movable/lighting_overlay: (lighting_overlay.dm) - var/lum_r, var/lum_g, var/lum_b; lumcounts of each colour - var/needs_update; set on update_lumcount, checked by lighting process @@ -64,4 +59,3 @@ turf: (lighting_turf.dm) - Change the lumcount vars and queue the overlay for update - proc/update_overlay() - Called by the lighting process to update the color of the overlay -*/ \ No newline at end of file diff --git a/code/modules/mob/freelook/read_me.dm b/code/modules/mob/freelook/README.md similarity index 98% rename from code/modules/mob/freelook/read_me.dm rename to code/modules/mob/freelook/README.md index 8ddb068940..380a3e0171 100644 --- a/code/modules/mob/freelook/read_me.dm +++ b/code/modules/mob/freelook/README.md @@ -1,51 +1,51 @@ -// CREDITS -/* - Initial code credit for this goes to Uristqwerty. - Debugging, functionality, all comments and porting by Giacom. - - Everything about freelook (or what we can put in here) will be stored here. - - - WHAT IS THIS? - - This is a replacement for the current camera movement system, of the AI. Before this, the AI had to move between cameras and could - only see what the cameras could see. Not only this but the cameras could see through walls, which created problems. - With this, the AI controls an "AI Eye" mob, which moves just like a ghost; such as moving through walls and being invisible to players. - The AI's eye is set to this mob and then we use a system (explained below) to determine what the cameras around the AI Eye can and - cannot see. If the camera cannot see a turf, it will black it out, otherwise it won't and the AI will be able to see it. - This creates several features, such as.. no more see-through-wall cameras, easier to control camera movement, easier tracking, - the AI only being able to track mobs which are visible to a camera, only trackable mobs appearing on the mob list and many more. - - - HOW IT WORKS - - It works by first creating a camera network datum. Inside of this camera network are "chunks" (which will be - explained later) and "cameras". The cameras list is kept up to date by obj/machinery/camera/New() and Destroy(). - - Next the camera network has chunks. These chunks are a 16x16 tile block of turfs and cameras contained inside the chunk. - These turfs are then sorted out based on what the cameras can and cannot see. If none of the cameras can see the turf, inside - the 16x16 block, it is listed as an "obscured" turf. Meaning the AI won't be able to see it. - - - HOW IT UPDATES - - The camera network uses a streaming method in order to effeciently update chunks. Since the server will have doors opening, doors closing, - turf being destroyed and other lag inducing stuff, we want to update it under certain conditions and not every tick. - - The chunks are not created straight away, only when an AI eye moves into it's area is when it gets created. - One a chunk is created, when a non glass door opens/closes or an opacity turf is destroyed, we check to see if an AI Eye is looking in the area. - We do this with the "seenby" list, which updates everytime an AI is near a chunk. If there is an AI eye inside the area, we update the chunk - that the changed atom is inside and all surrounding chunks, since a camera's vision could leak onto another chunk. If there is no AI Eye, we instead - flag the chunk to update whenever it is loaded by an AI Eye. This is basically how the chunks update and keep it in sync. We then add some lag reducing - measures, such as an UPDATE_BUFFER which stops a chunk from updating too many times in a certain time-frame, only updating if the changed atom was blocking - sight; for example, we don't update glass airlocks or floors. - - - WHERE IS EVERYTHING? - - cameranet.dm = Everything about the cameranet datum. - chunk.dm = Everything about the chunk datum. - eye.dm = Everything about the AI and the AIEye. - updating.dm = Everything about triggers that will update chunks. - +// CREDITS +/* + Initial code credit for this goes to Uristqwerty. + Debugging, functionality, all comments and porting by Giacom. + + Everything about freelook (or what we can put in here) will be stored here. + + + WHAT IS THIS? + + This is a replacement for the current camera movement system, of the AI. Before this, the AI had to move between cameras and could + only see what the cameras could see. Not only this but the cameras could see through walls, which created problems. + With this, the AI controls an "AI Eye" mob, which moves just like a ghost; such as moving through walls and being invisible to players. + The AI's eye is set to this mob and then we use a system (explained below) to determine what the cameras around the AI Eye can and + cannot see. If the camera cannot see a turf, it will black it out, otherwise it won't and the AI will be able to see it. + This creates several features, such as.. no more see-through-wall cameras, easier to control camera movement, easier tracking, + the AI only being able to track mobs which are visible to a camera, only trackable mobs appearing on the mob list and many more. + + + HOW IT WORKS + + It works by first creating a camera network datum. Inside of this camera network are "chunks" (which will be + explained later) and "cameras". The cameras list is kept up to date by obj/machinery/camera/New() and Destroy(). + + Next the camera network has chunks. These chunks are a 16x16 tile block of turfs and cameras contained inside the chunk. + These turfs are then sorted out based on what the cameras can and cannot see. If none of the cameras can see the turf, inside + the 16x16 block, it is listed as an "obscured" turf. Meaning the AI won't be able to see it. + + + HOW IT UPDATES + + The camera network uses a streaming method in order to effeciently update chunks. Since the server will have doors opening, doors closing, + turf being destroyed and other lag inducing stuff, we want to update it under certain conditions and not every tick. + + The chunks are not created straight away, only when an AI eye moves into it's area is when it gets created. + One a chunk is created, when a non glass door opens/closes or an opacity turf is destroyed, we check to see if an AI Eye is looking in the area. + We do this with the "seenby" list, which updates everytime an AI is near a chunk. If there is an AI eye inside the area, we update the chunk + that the changed atom is inside and all surrounding chunks, since a camera's vision could leak onto another chunk. If there is no AI Eye, we instead + flag the chunk to update whenever it is loaded by an AI Eye. This is basically how the chunks update and keep it in sync. We then add some lag reducing + measures, such as an UPDATE_BUFFER which stops a chunk from updating too many times in a certain time-frame, only updating if the changed atom was blocking + sight; for example, we don't update glass airlocks or floors. + + + WHERE IS EVERYTHING? + + cameranet.dm = Everything about the cameranet datum. + chunk.dm = Everything about the chunk datum. + eye.dm = Everything about the AI and the AIEye. + updating.dm = Everything about triggers that will update chunks. + */ \ No newline at end of file diff --git a/code/modules/modular_computers/_description.dm b/code/modules/modular_computers/README.md similarity index 100% rename from code/modules/modular_computers/_description.dm rename to code/modules/modular_computers/README.md diff --git a/code/modules/overmap/README.dm b/code/modules/overmap/README.md similarity index 100% rename from code/modules/overmap/README.dm rename to code/modules/overmap/README.md diff --git a/code/modules/research/rd-readme.dm b/code/modules/research/README.md similarity index 98% rename from code/modules/research/rd-readme.dm rename to code/modules/research/README.md index 0f98395145..4d64a6bf82 100644 --- a/code/modules/research/rd-readme.dm +++ b/code/modules/research/README.md @@ -1,32 +1,32 @@ -/* -Research and Development System. (Designed specifically for the /tg/station 13 (Space Station 13) open source project) - -///////////////Overview/////////////////// -This system is a "tech tree" research and development system designed for SS13. It allows a "researcher" job (this document assumes -the "scientist" job is given this role) the tools necessary to research new and better technologies. In general, the system works -by breaking existing technology and using what you learn from to advance your knowledge of SCIENCE! As your knowledge progresses, -you can build newer (and better?) devices (which you can also, eventually, deconstruct to advance your knowledge). - -A brief overview is below. For more details, see the related files. - -////////////Game Use///////////// -The major research and development is performed using a combination of four machines: -- R&D Console: A computer console that allows you to manipulate the other devices that are linked to it and view/manipulate the -technologies you have researched so far. -- Protolathe: Used to make new hand-held devices and parts for larger devices. All metals and reagents as raw materials. -- Destructive Analyzer: You can put hand-held objects into it and it'll analyze them for technological advancements but it destroys -them in the process. Destroyed items will send their raw materials to a linked Protolathe (if any) -- Circuit Imprinter: Similar to the Protolathe, it allows for the construction of circuit boards. Uses glass and acid as the raw -materials. - -While researching you are dealing with two different types of information: Technology Paths and Device Designs. Technology Paths -are the "Tech Trees" of the game. You start out with a number of them at the game start and they are improved by using the -Destructive Analyzer. By themselves, they don't do a whole lot. However, they unlock Device Designs. This is the information used -by the circuit imprinter and the protolathe to produce objects. It also tracks the current reliability of that particular design. - -//EXISTING TECH -Each tech path should have at LEAST one item at every level (levels 1 - 20). This is to allow for a more fluid progression of the -researching. Existing tech (ie, anything you can find on the station or get from the quartermaster) shouldn't go higher then -level 5 or 7. Everything past that should be stuff you research. - +/* +Research and Development System. (Designed specifically for the /tg/station 13 (Space Station 13) open source project) + +///////////////Overview/////////////////// +This system is a "tech tree" research and development system designed for SS13. It allows a "researcher" job (this document assumes +the "scientist" job is given this role) the tools necessary to research new and better technologies. In general, the system works +by breaking existing technology and using what you learn from to advance your knowledge of SCIENCE! As your knowledge progresses, +you can build newer (and better?) devices (which you can also, eventually, deconstruct to advance your knowledge). + +A brief overview is below. For more details, see the related files. + +////////////Game Use///////////// +The major research and development is performed using a combination of four machines: +- R&D Console: A computer console that allows you to manipulate the other devices that are linked to it and view/manipulate the +technologies you have researched so far. +- Protolathe: Used to make new hand-held devices and parts for larger devices. All metals and reagents as raw materials. +- Destructive Analyzer: You can put hand-held objects into it and it'll analyze them for technological advancements but it destroys +them in the process. Destroyed items will send their raw materials to a linked Protolathe (if any) +- Circuit Imprinter: Similar to the Protolathe, it allows for the construction of circuit boards. Uses glass and acid as the raw +materials. + +While researching you are dealing with two different types of information: Technology Paths and Device Designs. Technology Paths +are the "Tech Trees" of the game. You start out with a number of them at the game start and they are improved by using the +Destructive Analyzer. By themselves, they don't do a whole lot. However, they unlock Device Designs. This is the information used +by the circuit imprinter and the protolathe to produce objects. It also tracks the current reliability of that particular design. + +//EXISTING TECH +Each tech path should have at LEAST one item at every level (levels 1 - 20). This is to allow for a more fluid progression of the +researching. Existing tech (ie, anything you can find on the station or get from the quartermaster) shouldn't go higher then +level 5 or 7. Everything past that should be stuff you research. + */ \ No newline at end of file diff --git a/code/modules/research/designs/sort_string_readme.dm b/code/modules/research/designs/README.md similarity index 100% rename from code/modules/research/designs/sort_string_readme.dm rename to code/modules/research/designs/README.md diff --git a/maps/_map_system_readme.dm b/maps/README.md similarity index 100% rename from maps/_map_system_readme.dm rename to maps/README.md diff --git a/maps/submaps/_readme.dm b/maps/submaps/README.md similarity index 100% rename from maps/submaps/_readme.dm rename to maps/submaps/README.md diff --git a/polaris.dme b/polaris.dme index ea7ed602cf..9a798bfbca 100644 --- a/polaris.dme +++ b/polaris.dme @@ -2962,7 +2962,6 @@ #include "code\modules\research\message_server.dm" #include "code\modules\research\prosfab_designs.dm" #include "code\modules\research\protolathe.dm" -#include "code\modules\research\rd-readme.dm" #include "code\modules\research\rdconsole.dm" #include "code\modules\research\rdmachines.dm" #include "code\modules\research\research.dm"