Guide to mapping: Difference between revisions

Jump to navigation Jump to search
4,434 bytes added ,  11:20, 28 July 2015
imported>Kosmos
(Added Metacide's Guide to Mapping, was just concerned that it would get forgotten and buried if it stayed on the forum.)
imported>MrStonedOne
(12 intermediate revisions by 4 users not shown)
Line 34: Line 34:
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.  
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.  


'''[u]Important Note:[/u]''' 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.
'''<u>Important Note:</u>''' 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 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.  
Line 40: Line 40:
To actually play your map and be able to screw around in it as an admin, you'll have to compile it. First, make sure the file tree (on the left like the object tree, click the file tab) is open, and go to maps. Make sure the only one ticked is your own. Then click Build>Compile from the top, and wait for it to finish. This will give you a something like "tgstation.dmb" in the folder containing bot, code, config, maps, etc. Whilst here, quickly go into config, and open 'admins.txt'. Replace everything in there with:
To actually play your map and be able to screw around in it as an admin, you'll have to compile it. First, make sure the file tree (on the left like the object tree, click the file tab) is open, and go to maps. Make sure the only one ticked is your own. Then click Build>Compile from the top, and wait for it to finish. This will give you a something like "tgstation.dmb" in the folder containing bot, code, config, maps, etc. Whilst here, quickly go into config, and open 'admins.txt'. Replace everything in there with:


"<yourbyondname> - Game Master", filling in your BYOND name.
"<yourbyondname> = Game Master", filling in your BYOND name.


This will make you an admin, which is very helpful for tinkering ingame. Now to actually boot up a server so you can run your map! Find 'Dream Daemon' (has a big green icon) in your BYOND folder, and click the 'File' dropdown at the bottom. Select your "tgstation.dmb". Select a port if you want, put security on safe, and visibility to invisible, for now. Click start to start the server, which will take a little while. You can then connect to it through BYOND by putting in either your external IP, shown in Dream Daemon, if that port is correctly forwarded. Otherwise use your internal IP, 192.168.x.x, where x is whatever. If you don't know this, ask and I can help. Once in, go to the admin tab and click 'start game'. By joining after the start, you'll spawn at the late spawn you made, and, being an admin, will be able to make stuff, delete stuff, and other handy admin things (like causing massive explosions).  
This will make you an admin, which is very helpful for tinkering ingame. Now to actually boot up a server so you can run your map! Find 'Dream Daemon' (has a big green icon) in your BYOND folder, and click the 'File' dropdown at the bottom. Select your "tgstation.dmb". Select a port if you want, put security on safe, and visibility to invisible, for now. Click start to start the server, which will take a little while. You can then connect to it through BYOND by putting in either your external IP, shown in Dream Daemon, if that port is correctly forwarded. Otherwise use your internal IP, 192.168.x.x, where x is whatever. If you don't know this, ask and I can help. Once in, go to the admin tab and click 'start game'. By joining after the start, you'll spawn at the late spawn you made, and, being an admin, will be able to make stuff, delete stuff, and other handy admin things (like causing massive explosions).  
Line 48: Line 48:
If you've managed to get all the way to the end of this before I've added more, fine effort on your part. Have fun screwing around with stuff, and feel free to ask anything you like. I'll add more stuff here soon.
If you've managed to get all the way to the end of this before I've added more, fine effort on your part. Have fun screwing around with stuff, and feel free to ask anything you like. I'll add more stuff here soon.


== Pre-commit checks ==


== Pre-commit checks ==
*Are floors with or without air, as they should be? (regular or airless)
- Are all the floors with or without air, as they should be? (regular or airless)<br>
*Does the area have an APC?
- Does the area have an APC?<br>
*Does the area have an Air Alarm?
- Does the area have an Air Alarm?<br>
*Does the area have a Request Console?
- Does the area have a Request Console?<br>
*Does the area have lights?
- Does the area have lights?<br>
*Does the area have a light switch?
- Does the area have a light switch?<br>
*Does the area have enough intercoms?
- Does the area have enough intercoms?<br>
*Does the area have enough security cameras? (Use the verbs under Mapping for help)
- Does the area have enough security cameras? (Use the verbs under Mapping for help)<br>
*Is the area connected to the scrubbers air loop?
- Is the area connected to the scrubbers air loop?<br>
*Is the area connected to the vent air loop? (vent pumps)
- Is the area connected to the vent air loop? (vent pumps)<br>
*Is everything wired properly?
- Is everything wired properly?<br>
*Does the area have a fire alarm and firedoors?
- Does the area have a fire alarm and firedoors?<br>
*Do all pod doors work properly?
- Do all pod doors work properly?<br>
*Are accesses set properly on doors, pod buttons, etc.
- Are accesses set properly on doors, pod buttons, etc.<br>
*Are all items placed properly? (not below vents, scrubbers, tables)
- Are all items placed properly? (not below vents, scrubbers, tables)<br>
*Does the disposal system work properly from all the disposal units in this room and all the units, the pipes of which pass through this room?
- Does the disposal system work properly from all the disposal units in this room and all the units, the pipes of which pass through this room?<br>
*Check for any misplaced or stacked piece of pipe (air and disposal)
- Check for any misplaced or stacked piece of pipe (air and disposal)<br>
*Check for any misplaced or stacked piece of wire
- Check for any misplaced or stacked piece of wire<br>
*Identify how hard it is to break into the area and where the weak points are, and balance the area accordingly (eg. the Vault should be made of reinforced structures and electrified windows, the Kitchen should not)
- Identify how hard it is to break into the area and where the weak points are<br>
*Check if the area has too much empty space. If so, make it smaller and replace the rest with maintenance tunnels
- Check if the area has too much empty space. If so, make it smaller and replace the rest with maintenance tunnels.<br>
*Are there any [[guide_to_mapping#Room Structure|unsimulated floors]] where they shouldn't be?
- Are there any [[guide_to_mapping#Room Structure|unsimulated floors]] where they shouldn't be?<br>


== General Station-wide Mapping Guidelines ==
== General Station-wide Mapping Guidelines ==
Line 234: Line 234:
=== Access ===
=== Access ===


==== Door access ====
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'''.
 
[[File:DoorAccessImage1.png|thumb|left|300px]] This image shows a door on the Arrivals shuttle - since it's a public door, the access is set to "0", as everyone should be able to open it. If we look at the Brig front door, we would set the access to 63, because that's the value for Security front doors - accessible by Security positions, but no one else.
 
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.


==== Airlocks ====
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.


==== Pod Doors ====
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 ===
=== Airless Floors ===
Line 276: Line 280:
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 [[Community|the development IRC]] if you need more help.
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 [[Community|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 dock
*transit == shuttle as it moves
*mobile == 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
[[File:ShuttleBox.png]]
[[Category:Guides]] [[Category:Game Resources]]
[[Category:Guides]] [[Category:Game Resources]]
{{Contribution guides}}
{{Contribution guides}}
Anonymous user

Navigation menu