Участник:SpaceSmithers/guide sandbox
|
This page is currently under construction!
The following page is currently in the process of being created, is undergoing a major structural rework and/or is being moved. |
Other related guides: Understanding SS13 code, SS13 for experienced programmers, Guide to door access and Map Merger
| Файл:Notice.png | Read this!
This page is mostly port of san7890's A-Z Guide to Mapping, a HackMD document that details the mapping essentials. It is recommended that you read that document first as it is well organized, updated, and contains very useful visuals that this page may lack. |
 |
Big Chungus говорит: "Nyehehehehe I'm Big Chungus (big chungus voice). I just went through some stuff and left some comments. If you want something nice to write about the Guide to Mapping (and the Mapping Reference Collection) in those above chat bubbles, I like Goonstation ZeWaka's Prompt (inspired probably by san7890's own words), which can be found here: https://hackmd.io/@goonstation/maps#Goonstation-Mapping-Guide ." |
Getting Set Up
Setting up before doing anything is crucial to having a smooth and painless mapping experience.
Mapper's Checklist
Listed below is the software we'll be using:
- Git (Windows)
- Github Desktop (and a GitHub Account)
- You may substitute this for any Git client that you know how to use already (Bash or GitKraken). If you do not know how to use any Git client, Github Desktop remains a perfectly acceptable client for mapping changes, and I will be using it throughout this guide.
- StrongDMM Map Editor (available for Windows, Linux, and MacOS)
- If you prefer to use a web-based utility, you may use FastDMM2. Never, ever use Dream Maker to map. You will only harm yourself.
- Visual Studio Code with the Goonstation Extension Pack
- This is recommended because you will need to test your mapping changes! In the words of MMMiracles (creator of Cere, Donut, and Tram): “Knowing how to code greatly expands your mapping horizons.” You will not need to know how to code in order to map but having this set up at the very start will greatly assist your future endeavors!
- We use the Goonstation Extension Pack for easy interaction with BYOND’s Dream Maker code, it is a must-have. Don’t fret the name (because /tg/ coders made most of the stuff anyways haha).
- Python
- This is needed for Git Hooks, which are important in your mapping endeavors.
- Love
It is imperative that you use the Map Merger tools before committing any changes to a map. See here for how. Some modern programs do similar functions to what Map Merger does, but running this and getting your Git Hooks set up save you a lot of headache.
Forking the Repository
Firstly, you need a fork. A fork will be your very own copy of our repository, free do with as you
wish! Just hit the "Fork" button on https://github.com/tgstation/tgstation. Feel free to be creative with the name of your fork.
Displayed should be [GitHub username]/[name of fork], forked from tgstation/tgstation
 |
SpaceSmithers говорит: "An image embed would be good here. [[File:bruhstation.png|thumb|flavor text]]"
|
Within your fork you'll see a green button labelled "code" Code▼. In the dropdown menu, click Open with GitHub Desktop (assuming you've downloaded it). A prompt from the application will open; find a clean folder to locally copy your repository and click Clone. This may take a few minutes. Another prompt will appear asking: "How are you planning to use this fork?" You will want to select "To contribute to the parent project". This will make creating Pull Requests easier.
Branching the Fork
The final part to setting up GitHub is to make a new branch. This part is super-duper important, because you want to keep your “master” branch on your fork as clean as possible, since it’s a pain to clean out and send pull requests to.
To do this, click on the Current branch (which defaults to "master") and click on the "New branch" button next to the filter bar. For every individual project you work on and submit a Pull Request for, you want to be on a brand new branch. Feel free to name it whatever you want, can be as goofy or as organizational as you want. It’s your fork, after all.
- You may also get a screen that says “base it off the current branch” or “base it off the upstream/master”. That depends on what you want, but if you want to start fresh on a new project, always hit “base it off the upstream/master”.
Mapping
San7890's Guide to StrongDMM
Preamble
In the time of Metacide, the creator of MetaStation and the last person to make a "guide to mapping", all that you had was Dream Maker's program. Dream Maker sucks though, and we have better tools. While all of the content you see on the rest of this page and elsewhere may be lifted straight from DreamMaker, this will serve as a small "pointer" to where you can find that same functionality in StrongDMM. Everything you can do in Dream Maker, you can do about 100 times better in StrongDMM. If you've managed to grasp the bare essentials of even playing Space Station 13, then I have no doubt that getting acclimated to StrongDMM will probably be a walk-in-the-park. However, BYOND hasn't changed in how it parses maps, so that will all hold steadfast and true.
At the time of me writing this guide, StrongDMM is currently in an “alpha state” (Versions 2.0.0 and up). I will be using the alpha version since it’s the path the program is going to take in the future, but if you’re hesitant about an alpha version, feel free to downgrade to Version 1.9.1 (it has a few features 2.0.0 is missing). You can actually run both concurrently, too! Regardless, let’s start mapping!
Starting StrongDMM
Go into "File" in the top-right of your screen and hit “Open Environment”. The “environment” is how StrongDMM is able to find, collect, and parse the atoms that make up every part of every map. This is an important step, and make sure you always use the .DME (Dream Maker Environment) file on your repository to keep things as straightforward as possible. Just get tgstation.dme.
 |
Then, go back into "File" and hit "Open Map". You'll want to go into the ``_maps`` directory of your repository, and then find any map you like. I'll be using MetaStation.dmm for the purposes of this guide. Once StrongDMM loads the map of your choosing, you can use Middle-Click and the Scroll Wheel to find your way around. Soon, you should get something that looks like this: |
Beautiful! Let’s talk about those colors. Those are areas which are important for the game to understand what discrete location is what, and we use it for several things code-side. For example, the bridge is a different area than the bar, so you want to make sure everything is defined appropriately. They tend to be a bit distracting through, so you can hit Ctrl+1 to get rid of those. Do make sure you define them properly when you’re done, though.
Areas are one of four different, distinct “layers” we use in BYOND. The other three are turfs, objs (for Objects), and mob (for creatures/animals/what-have-you). Their progenitor species is the atom. You can go into the options tab or hit the respective keybind to quickly filter for those.
Editing
 |
These are your tools to edit with. From left to right, they are:
They each do their own thing, and you can hover over them in the program to see what you might want to use. Feel free to get a feel with the tools by toying around with stuff, and eventually getting to work on your own maps as you desire. |
Testing Your Map
You should always test your code, test your maps, test your sprites, test everything whenever it’s a non-trivial amount of work. There’s an incredibly simple way to do this, which I’ll reveal to you now:
The easiest/fastest way to do this is to go into Github Desktop and find the button that reads “Open in Visual Studio Code”. If it doesn’t, set your default editor to Visual Studio Code.
|
SpaceSmithers говорит: "i need to shrink this!!" |
Once inside Visual Studio Code, you'll want to hit Ctrl+F5, or just F5. This will start compiling your code, which shouldn’t take more than a few minutes. Once done, it’ll boot up BYOND’s Dream Seeker, connect you to the local server, and automatically give you the highest permissions. This is because you’re doing everything in the debugging mode, which is quite nifty. This is arguably the simplest way to do it.
Once Space Station 13 has started, the Server tab located in the Stat-Panel will be a big help. From there, you can change maps and also skip the post-initialization wait time by clicking Start Now (or just type Start-Now in the command bar). Observe as a ghost and view your changes. Compiling is a good way to view the more subtle nuances that you weren’t able to pick up on through the editor. This includes (but is certainly not limited to): lighting, door accesses, mob interactions, and just figuring out if it looks good.
End of san7890 guide and StrongDMM
|
SpaceSmithers говорит: "Need to find a good way to transition from StrongDMM to Meta's Dream Maker sections. Edit: I might just overwrite and renew all of Meta's stuff actually. I'll include a hyperlink at the top of the page that will take the user to an older version of the page with Dream Maker instructions." |
|
Big Chungus говорит: "If you wanna be consistent in the hyperlink usage, the Mapping Reference Collection uses https://tgstation13.org/wiki/index.php?title=Guide_to_mapping&oldid=37972 as it's ear-mark reference -> modern rewrite." |
Hid all this stuff to make scrolling and editing easier.
So now you have your folder with the latest code in, and a zip backup to go back to if you break everything. In the master folder, you'll see "tgstation.dme". You want to open this with Dream Maker a program that'll be in your BYOND folder. Set Dream Maker as the default program for opening .dme files, if it isn't already. When you open it, you'll see a two tabs on the left: file, and object. In the file tab, open maps, and then open 'tgstation.2.1.2.dmm', or whatever the current map version is called. You'll then get something looking a bit like this:
| SpaceSmithers говорит: "san removed this image for some reason [[File:Dreammakermap.png|center|600px]]" |
|
Big Chungus говорит: "I think it's because san7890 was trying to overwrite the outdated version of what the fuck map it was with a StrongDMM screencap, but the whole part wasn't formatted correctly to accomodate, so I think he just gave up. I'm big chungus but just trust me on this one. Also, I went through and looked at what you had already copied over from the Guide to Mapping and struck that through just to keep things managed (as well as stuff that only applies to Dream Maker Mapping), feel free to undo that if it interrupts your workflow." |
Switch from the files tab to the objects tab, and you'll see area, mob, objects, and turf. These are the four primary 'layers' that you can see in the editor. You can toggle their visibility and interactivity on and off using the layers dropdown. I'd advise copying this map, and renaming it to, say, teststation.dmm. Perhaps delete most or all of the default station, and build on the now-empty z-level, wherever you like. To build stuff, use the object tree on the left of the UI to select things, then click to place them. A simple click lets you place one item per tile from each category, while Ctrl-click stacks it on top of all previous ones and Shift-click deletes the topmost item. You can have multiple maps open at once - I usually have the default /tg/station map and mine open, and can then shamelessly copy-paste things far more easily. Also, finding stuff in the object tree can be tedious as hell - right click something you see and you can see its path in the tree - obj/structure/closet/etc. This will help you find things. From this point on, really, you can begin mapping proper.
You can select areas to copy/paste/delete, or enter add or fill mode when placing objects. Basically just click around all the menus and you'll work out how they work, more or less. Options>Zoom allows you to zoom out to 50% to see more stuff. Use layers to select which of area, objects and turf you want to edit. If you actually want to be able to see anything, I'd deselect area, and tick 'only show selectable layers'.
The first step, then, is to be able to create your first few rooms. Select a turf (floor) from the generic simulated floors. These will start with the right make-up and pressure of air on them, which is how you'll want it. Surround these floors with walls, and hey presto you have a room. Try sticking some tables in there, perhaps a vending machine or two.
If you want to add some chips to your new den but are unhappy of how they neatly stack on top of eachother, you can change their "pixel_x" and "pixel_y" values in the "edit" rmb-menu to arrange them as you want! (Remember to start and end the value with doublequotes! Also, all custom values are bold so it's easier to identify them.) In fact, most wall-mounted machines on stations are shifted like this, and while they APPEAR to be on a wall, they are actually on the tile in front of it. Just don't go overboard with this, as every new instance of an object is added as its own entry in the menu, and when there are dozens of them it can get hard to remember which one you wanted. Once you've made your room you'll want to put lights in.
|
| So now we get to the basics of making a functioning room. First of all, you'll need to re-enable the area layer. Pick some area from the object tree, and cover your room in it. You can rename this area if you want, we'll do that later. Make sure the area isn't used anywhere else on the map. Each area should have one APC or Area Power Controller in it. Copy one in from the default map or spawn one yourself, then rename its "name" variable through "edit" to something appropriate. If you copied your APC from another map, chances are that cell type and dir are both in bold. Cell type defines how much power the APC can hold, and for your first map you'll want to set this nice and high as you don't have any sort of generator yet - 10,000 ought to do. Dir defines the direction the APC is in with regards to the cell it occupies. Basically, 1 means it is above the cell you place it in, 2 is below, 4 is to the right and 8 to the left.
Note that with APCs, dir is the only variable controlling their position. Other objects have their positions defined by pixel_x and pixel_y - this changes where APCs appear in the editor, but once ingame they snap to whatever the dir variable says. Other things, like signs on walls, will only take notice of the pixel variables and not necessarily dir. In a normal power system, you'd connect the APC up to all the others and the station's generator via SMES cells, but we'll do that later. For now you have a basic room that is powered and starts with enough air to breathe happily. You can put an air canister in if you think you'll consume all the oxygen, or somesuch. |
Important Note: There are nudge_x and nudge_y variables in the editor, as well as various z-axis variables. Don't ever change these, they're not used in SS13 and break things.
To be able to actually spawn into a room, you'll want to place spawners. You'll see these as the big red X symbols on the default map, for each role. There are also blue Xs for xeno spawn locations and the spawns for all latecomers on the arrival shuttle. Stick in a spawn_late somewhere in your room for now.
To actually test your map and be able to screw around in it as an admin, you'll have to compile it. The easiest way to do this is through Github Desktop, where you will open the repository in your external editor by clicking the "Open in Visual Studio Code" button. If this is not present, change your default editor in the options to Visual Studio Code. In Visual Studio Code, press F5 to both compile and launch the game. Full permissions are automatically granted as "localhost".
The best possible training is through experience. From here on out, you can make whatever you like, really. Copying the default map and working out how everything works isn't too hard and is fairly rewarding. You could just tweak the default one if you like. The first thing I made was a small shuttle - you can see this at the bottom. Just tweak and add stuff and you'll work out how almost everything works fairly easily. Poke around with both Github Desktop and StrongDMM. For explanations of wiring, piping, and atmos, ask away on the mapping channel of our discord or on the forums.
Pre-commit checklist
- Are floors with or without air, as they should be? (regular or airless)
- You can test this one out by looking for Active Turfs.
- Does the area have an APC?
- Does the area have an Air Alarm?
- Does the area have a Request Console?
- Not every area needs this, look at other stations.
- Does the area have lights?
- When you compile your map for testing, make sure the lighting is adequate. You don’t want any unwarranted “dark” spots in your rooms. If you’re going for “warm” or “cold” lighting, make sure it all matches.
- Does the area have a light switch?
- Only smaller rooms that get minimal traffic should recieve lightswitches. Areas like primary hallways should definitely not have them.
- Does the area have enough security cameras? (Use the Debug Verbs for help)
- Does the area have enough security cameras? (Use the verbs under Mapping for help)
- Does the area have enough intercoms? (The verb
Intercom Range Displayin the Mapping Debug Verbs helps with this.) - Is the area connected to the vent air loop (distro)?
- Is the area connected to the scrubber air loop (waste)?
- Is everything wired properly?
- Does the area have a fire alarm and firelocks?
- Typically, doors leading into maintenance do not need firelocks. Do not place firelocks on doors facing the exterior of the station (like space or the planet).
- Do all airlocks work properly?
- Are accesses set properly on doors, pod buttons, etc.
- For typical airlocks, you can use the Airlock Mapping Helpers. Otherwise, consult the reference for Door Accesses.
| SpaceSmithers говорит: "what are pod buttons?" |
|
Big Chungus говорит: "Probably don't exist any more. I also think it might be a misnomer for stuff like buttons that attach to stuff like shutters, flashers, bolting doors, etc. Should probably just be "buttons". I updated the Mapping Reference Collection since it just was obtuse. Nyehehehehe what's up doc" |
- Are all items placed properly?
- In summary, are your objects all on tables as needed? Are tables or other objects obscuring your vents/scrubbers?
- Does the disposal system work properly from all the disposal units in this room as well as the pipes of which pass through this room?
- Just throw yourself through a few disposals systems that seem to pass through the area you touched. Easy to forget.
- Check for any misplaced or stacked piece of pipe.
- /tg/station also lints for this to catch you if you forget.
- Check for any misplaced or stacked piece of wire.
- /tg/station also lints for this to catch you if you forget.
- Identify how hard it is to break into the area and where the weak points are and balance the area accordingly.
- Check if the area has too much empty space.
- You don’t want vast, bald spots in your rooms that serve little purpose. Fill it up with stuff if you can, or just trim the fat entirely. Whatever works best for the station and your design.
- Are there any indestructible turfs where they shouldn't be?
General Station-wide Mapping Guidelines
In general
Don't run pipes/cables/disposals through walls if you can avoid it. Otherwise it's a pain to repair or sabotage them, especially under r-walls.Try to connect departments to maintenance through a back or side door. This lets players escape and allows antags to break in. Metastation is a good example for this.
Atmospherics
Each area should have EXACTLY one air alarm (Exceptions are only possible if a room has scrubbers or vent pumps on different frequencies).Each ROOM (Walled off space) should have at least one vent pump and scrubber, which is properly connected to its respective loop.
Keep in mind that scrubbers don't detect gases/pressure; only air alarms do.The air supply loop's pipes should be colored blue.The scrubbers loop's pipes should be colored red.Some areas require special air alarm subtypes: /engine for the SME and /server for tcomms or the RnD server room.
Power
Each area (which requires power) should have exactly one APC. For areas with a high roundstart power draw (engineering/cargo), one of the highcap subtypes can be used.
Atmospherics
Pipes and manifolds
Atmospherics releases it's cocktail of gases into the air supply loop (blue pipes). The station is also equipped with a scrubber loop, which filters unwanted gases and sends them back to atmospherics via the scrubber loop (red pipes).
If you're expanding the air supply loop (blue pipes) use the objects in /obj/machinery/atmospherics/pipe/simple/supply/visible or ../hidden depending on if you want it to show above floors or below them. For manifolds use the objects in /obj/machinery/atmospherics/pipe/manifold/supply/visible and ../hidden.
If you are expanding the scrubber loop (red pipes) use the objects in /obj/machinery/atmospherics/pipe/simple/scrubbers/visible or ../hidden depending on if you want it to show above floors or below them. For manifolds use the objects in /obj/machinery/atmospherics/pipe/manifold/scrubbers/visible and ../hidden.
If you are however building a pipe network which has nothing to do with the air supply or scrubbers loop, you should use the objects in /obj/machinery/atmospherics/pipe/simple/general/visible or ../hidden. For manifolds use the objects in /obj/machinery/atmospherics/pipe/manifold/general/visible and ../hidden.
To add new colors of pipes, you will need add a new subtypes in the appropriate .dm files located in tgstation\code\modules\atmospherics\machinery\pipes
Please refrain from var-editing pipes, as it typically introduces graphical glitches and other issues.
Air Alarm
Every single area (with scrubbers and/or vent pumps) should have exactly one air alarm. More than one should be placed if vent pumps or scrubbers use different radio frequencies than the default one (1439).
Scrubbers (Station air supply)
Every room (ie. walled off space) except for maintenance hallways should have at least one scrubber.
The path for scrubbers that start on is /obj/machinery/atmospherics/components/unary/vent_scrubber/on
And make sure the id_tag is the default one (null)
Also ensure the scrubber is connected to the scrubber loop!!
Vent Pumps (Station air supply)
Every room (ie. walled off space) except for maintenance hallways should have at least one vent pump.
The path for vents that start on is /obj/machinery/atmospherics/components/unary/vent_pump/on
Please make sure the id_tag is the default one (null)
Also ensure the vent pump is connected to the air supply loop!!
Gas tanks and filters
Each station should have a full set of these - or at the bare minimum, one for N2, one for O2 and a third tank to filter dangerous gases into.
Each gas tank needs:
Outside: A tank computer and a gas filter to pick what gases will be filtered into it.Inside: A gas injector (input), a vent pump (output), a gas sensor and a specific turf.
The tank computer controls the input/output and receives data from the gas sensor.
The specific turf creates the gases that will be inside each tank - the gas canister is just for decoration.
Let's take a look at the MetaStation N2 tank:
Tank computer: /obj/machinery/computer/atmos_control/tank/nitrogen_tankN2 filter: /obj/machinery/atmospherics/components/trinary/filter/atmos/n2Gas injector: /obj/machinery/atmospherics/components/unary/outlet_injector/atmos/nitrogen_inputVent pump: /obj/machinery/atmospherics/components/unary/vent_pump/siphon/atmos/nitrogen_outputGas sensor: /obj/machinery/air_sensor/atmos/nitrogen_tankTurf: /turf/open/floor/engine/n2
These objects have all the neccessary vars preset and start switched on - you'll only have to edit the dir if neccessary.
Additionally, you'll want this type of gas mixer for the airmix tank (N2 + O2):
Air mixer: /obj/machinery/atmospherics/components/trinary/mixer/airmix
Power
APC
Each new room needs at least one, this will provide all the power for the room (magically). Each piece of machinery inside the APC's area will draw power from either the lighting, equipment or environmental channel.
Any room that is very equipment heavy (for example cargo bay) may need a beefed up APC (apc/highcap) to prevent early blackouts. These start with higher capacity power cells.
Wiring
Make sure the wires lead from the main power grid, and to the APC(s) of your area. If any equipment in your new area requires a wire under it, line it up, connected to the main power grid, and under the machinery.
Wires are also helpful when making electrical grilles (just dot wire under a grille), make sure the wires touch the main power grid (or they won't shock people).
Equipment
Lights
Lights take up a lot of power, don't use too many! Make sure to put in just enough so the room is fully lit, but not so many that the equipment will go out in ten minutes of the round starting.
Light switch
For mood lighting, or to show the room is currently not in use by the primary occupant. These disable the lighting equipment (and power drain associated) in the area, but not desk lamps. Place these on walls, usually by a door.
Request Console
If a certain room has no need for materials, or produces no materials, do not give it a Request Console. If it does (for either case or both) make sure it has at least one, that is in a place where some one will see it.
Intercoms
At least every room should have one of these. They should be set to 145.9, and be speaker ON Microphone OFF. This is so radio signals can reach people even without head sets on. Larger room will require more than one at a time.
Security Cameras
Most areas should have these, enough to see the general area from a Human point of view, but, not bunched together for the AI's sake. Larger rooms may require more than one.
Room Structure
Access
Refer to ..\code\__DEFINES\access.dm for door access values.
Access to doors is handled by req_access values. There are four when editing a door - req_access, req_access_txt, req_one_access, and req_one_access_txt. The one's we're concerned with are req_access_txt and req_one_access_txt.
Multiple accesses to doors are handled by adding a semicolon (with no spaces) between access values (eg. "28;31" is for Kitchen and Cargo access). This might seem worthless, but it's useful for small maps, where jobs might need to share access due to cramped spaces.
There's an important difference between the two that you need to pay attention to - req_access_txt requires ALL LISTED ACCESSES to open the door, while req_one_access_txt lets anyone with ONE OF THE LISTED ACCESSES open the door. For example - say you want your Brig to be openable by the Detective and Security Officers, we would put "63;4" in req_one_access_txt, because we want the Detective AND Security to have access. If we used req_access_txt, you would need BOTH accesses to open the door, meaning neither the Detective or Security could open it.
You can view all of the access values in the code/game/jobs/access.dm file. (Most should be self explanatory or have a label, but if you really aren't sure, you can take a look at Boxstation's map file and check the value on the door you're looking for).
Airless Floors
Ideal for rooms or chambers that mix gas, and for tiles exposed to space. Not ideal for areas that humans will cross in frequency.
Use these on external tiles (to prevent lag when the game starts) and chambers that will require gas mixing (toxins mix chamber/ furnace). Double check these to make sure you don't suffocate mobs in the new rooms.
Fire Alarms and Fire Doors
Make sure to put these INSIDE of the boundary of the area, so there is a lock down. Any spot that gets hot as a normal function should not have a fire Alarm right next to the heat source (toxin mix chamber). Make sure there is a fully sealed area (with the exception of maintenance doors for people to escape fires) that can't be open by normal civilians.
Weak Points
Judge how high security the room will be, if it is high security, reinforced walls and electrified grill windows may be in order. Areas that do not need a lot of security can use basic walls, and windows to your liking (though normal glass windows break very very easy). Each room should have one place that's weaker than the rest (like a back door, side entrance, or a window), just because the main entrance might be out of commission (and realistically, for traitors to break into).
Item and Machinery Distribution
Be smart about what will go in an area, keep a fine balance between the size of the room and amount of equipment. Large rooms may require multiple APCs to prevent power outages early in game. Second, make sure to place equipment that make sense for the area (security computer in a security area/ Medical vendor in a medical area).
Indestructible Turfs
Before you finalize a map, check for any indestructible turfs. These turfs ignore things like external damage and are typically meant for things like special ruins/rooms where you want to avoid people trying to circumvent a path. Due to these characteristics, they have no real place on regular station maps and would probably lead to confusion for players more than anything.
Balance
Item contents
The harder the room is to enter, the more goodies or sensitive equipment there is inside. Make sure to keep this in mind (and don't make an empty room that's covered in blast doors, electrified grills, reinforced walls, and captain level doors).
Room security
A room is only as secure as its necessity. Public rooms should not have many security functions (other than a fire alarm), but private work space must be more secure (based on job). The bartenders do not need reinforced walls around their storage, but engineers do.
The highest security rooms should utilize the highest security measures. The lowest security rooms should utilize the cheapest security measures.
Step_x, step_y and the broken movement syndrome
So you compiled the map and suddenly whenever you move you no longer get the animation of moving but just 'appear' on the next tile?
So a while back step_x and step_y were introduced to allow pixel based movement. SS13 does not utilize this. Step_x and step_y are variables that each atom has. The way they work is that as soon as you set any object on the map to use one of these variables, the game interprets that you overrode all default movement code and wrote your own - but you didn't (The code that makes the animation from tile to tile).
To fix this problem you need to close dream maker (save the project first, obviously). Open your map (.dmm) file in a text editor, such as notepad or notepad++. Search (ctrl+f) through the file for step_x and step_y and remove any reference to it. Once no more step_x or step_y -es are found in the file, save it and open it in dream maker once again. Compile the code and movement should work fine once more. Go to the development IRC if you need more help.
Shuttles
Basically there's 3 types of shuttle dock stationary, transit and mobile
stationary == places where the shuttle can docktransit == shuttle as it movesmobile == the place with the actual shuttle
so you'd have a transit dock in the transit area and 2 stationary docks, one in centcomm and the other one in the station and 1 mobile dock, in centcomm for most shuttles (apart from mining)
The shuttle docks are grouped by id eg id = "cargo_away" id = "cargo_transit"
You need to add the dock types to the map and edit the bounding boxes via varediting the dock, you need to varedit height, width, dheight and dwidth at minimum. These are offset by the dir so do keep that in mind, eg if dir == 2 then width goes from EAST to WEST, if dir == 4 then width goes from NORTH to SOUTH and dwidth/dheight are offsets from the lower-left corner of the plane switched to the dock's dir
You should also ensure the directions face the shuttle or face away from the thing the shuttle docks with.
If a shuttle's mobile docking port direction is different then the stationary docking port's direction, the shuttle and all items on it will be rotated accordingly. (Try it, it works properly for just about everything)
Warning the bounding box for the mobile dock must fit inside of the stationary dock (after any rotation) Or the shuttle will refuse to move.
If the shuttle's mobile docking port is in an area that is a subtype of /area/shuttle, Only turfs in the bounding box in that same area are moved. Otherwise it moves all turfs in the bounding box. This can be used for odd shaped shuttles. (the area will be transfer over as well)
Also note that the emergency shuttle and cargo shuttle need special subtypes of the dock type eg so /obj/docking_port/mobile/emergency
The other variables of note is traveldir, which defines if the shuttle rotates on transit, it's an angle in degrees (just imagine the shuttle is inside a circle . For example, if you want the shuttle going right to left set it to 270 degrees.
Dwidth and Dheight in more depth
dwidth/dheight is the offset of the docking_port obj from the (0,0) bounding box corner. In dir == 1 (north) 0,0 is the bottom left corner? This changes for each direction, For example when dir is 2 it's the upper right corner. so dwidth and dheight identify where the bounding box starts relative to the docking port obj whereaswidth and height determine the actual width and height of the bounding box
Note: We count step 0 as a tile, so a height and width of 9 is actually 10 tiles (tile 0 to tile 9)
Here is an example for the north facing shuttle dock direction - you can rotate this image to determine where the offset is for each other cardinal direction
Файл:ShuttleBox.png
Other files
If you are adding a map to the game, you need to ensure it has a JSON file under _maps, and is included in the maps config file.
Helpful regular expressions
Everything in the code blocks is a regular expression, most decent text editors are able to use regex in their searches.
Replace the regex proceding => with what follows.
Pesky var edits for the `something` var are all over my map
Replace something with the var that needs to be removed. You need to run both replacements to catch all cases.
For standard dmm format:
\bsomething *= *.+?; *=> nothing{\W*\bsomething *= *[^;]+?\W*}=> nothing
For TGM format:
^\W+\bsomething *= *.+?;\n=> nothing{\W*\bsomething *= *[^;]+?\W*}=> nothing
Multi-Z
Multi-Z is a feature which allows a station map to have multiple Z-levels layered on top of each other, behaving as a single station with multiple floors. This feature is currently in use on the Tramstation and IceboxStation maps. A station's multiple levels can be bundled into one map file, or in several seperate files. The traits section of the map configuration json tells SS13 how to link the maps together.
If you are building station rooms on a lower Z level, ensure that a floor of some type is mapped on the Z level above the room. You can check the coordinates in the mapping editor to ensure you floor over the correct dimensions of the room. When running the server in Dream Daemon to test the map, you can go to the Debug tab and hit show debug verbs, go to Mapping tab and hit Show ATs, if the list is empty, you are good.
Earlier versions of multi-z did not require a baseturf to be defined under each z-level's traits in the config json. Each level must now have a baseturf set.
The maploader will not load and link a map file without areas or turfs defined. An empty space (nothing but baseturf) map will runtime. If you are adding a Z-level to an existing map, be aware of this.
SS13 will cache a map's configuration json file in data\next_map.json. If you alter a map's configuration json locally, you must also clear this file by using the change-map verb in game, deleting the file, or replacing it with your updated json file.