so you can see the boundaries of melee hit

Demonstrating guns and melee weapons actually doing damage will be a big milestone. This will show the there is actually some basic form of game to play, even if it is just endless deathmatch for now.

Requirements:

• Guns consume their specific ammo when fired.
• Guns will not work without ammo.
• Guns damage other entities.
• Melee weapons either swing in an arc or stab toward the target, doing damage to everything in the arc.
  Unarmed mobs will punch with their hands, doing damage. (Requires an intent system, out of the scope of this.)
• Thrown objects will collide with entities and damage them based on mass.

This requires #115.

If you run restartround your player will be kicked out of its entity but it won't respawn. Pretty sure there is simply no logic to handle this when on no-lobby mode.

Laser guns should use a power cell, the SMG should use actual magazines and bullets.

~

This is half code half game design, I apologise in advance.
-Punished Urist, The Game Designer Rejected By His Fellow Comrades.

Overview

Access is based on three components, ID, AccessReader and Access. An AccessReader has functions that, well, read a given Access component and tell other components and the entity itself whether access is granted or denied. This is usually done through one or two entities - an ID lock and, optionally, a signal splitter (see #30). Some access attempts are also recorded in a remote security console (via an AccessLogger component).

Access component

An Access component can hold several tags, such as “security”, “medical” and so on. These are strings that can be defined at runtime, not enums.

ID component

An ID component is an extension for Access. Access can exist without ID, ID can’t exist without Access. It holds a name of the ID’s owner, the job name and a “unique” number (well, ID). The third value follows a specific format and is generated at the beginning of the game for every ID assigned to a mob (human, AI, cyborg), guaranteed to be unique at that time. It is then recorded in a database on the station along with the associated name/job pair. After the ID number is generated, it can be edited with special tools in order to throw investigators off-track, and so can its database value.

AccessReader component

An AccessReader component has a list of rules, each of which is either in “OR” mode or “NONE” mode and has a list of tags. When an Access gets passed to the AccessReader it gets compared to each rule in the list, and if all rules are met, then the test is considered passed; otherwise it is considered failed. When an entity gets passed, it tries to find the Access item using the entity’s rules (for example, a human mob would tell about the Access-providing PDA in the PDA slot). If it does, it uses that as above. If it doesn’t, the test is automatically failed.
An “OR” mode rule is met if there’s at least one match between its list of tags and the Access’s list of tags. A “NONE” mode rule is met when there’re no matches between its list of tags and the Access’s list of tags.
If there is an AccessLogger component on the entity then it tells that component the time, success value of the attempt and the using Access’s entity’s ID component, if any.

Example

An AccessReader has the following rules: “OR”: “medical”, “security”; “NONE”: “engineering”.
It will pass the following Accesses: “medical”; “medical”, “security”; “security”, “botanical”.
It will fail the following Accesses: “medical”, “engineering”; “medical”, “security”, “engineering”; “botanical”

AccessLogger component

An AccessLogger component sends messages to a connected security console containing a link to the entity, ID information, date and success value of access attempts when it receives information about them. It has two bool values, “send successful attempts” and “send failed attempts”, which determine which attempts it logs.
The default (not-overriden behaviour) AccessLogger requires a Device component. It sends information about successful attempts only in powered mode and about successful and failed attempts only in powered or power-saving mode.

ID lock

A simple entity with AccessLogger, AccessReader, Device, RCOutput(#30). When interacted with using a PDA or a built-in ID service (for AI and such), checks the Access with the AccessReader and tells RCOutput to output an instant signal, “passed” or ”failed” depending on whether the test passed or failed. Its AccessLogger component is disabled by default but can be enabled and set up depending on where the ID lock’s used.

PDA

A held item with Access, ID components and a lot of other stuff (more on that in a separate PDA design doc). Generated for a player at round start. Goes into a separate inventory slot. When a mob with a PDA slot is asked for its Access, if it doesn’t have an Access component, the PDA in the PDA slot is automatically used.

Security logging and ID database

A single security console and a single ID database are located on the station. These are used to store information about access attempts across the station and everyone’s IDs, respectively.
The security console lists all the attempts sent to it by AccessLoggers across the station, but only up to X entries (on a FIFO system). The UI includes filtering by entity and getting info from the ID database via a click on the ID. It can be hacked and edited to remove, add or modify entries.
The ID database holds the information on all the round-start generated IDs and the associated name/job pairs. When something needs to know information about an ID, it asks the database. It can get updated information from ID editing consoles or hacked directly in order to add, remove or modify entries. It can never have two separate entries with the same ID numbers.

ID editing console

Edits a PDA’s ID and Access values - name, job, access tags. Has job + access tags presets. Can be hacked to also allow editing the ID number directly.

UI

Basically there’s UI for editing rules on AccessReaders and UI for editing tags on Access and UI for editing an ID. Dunno, it’s pretty simple but I ain’t visualising it just yet.

If somebody wants to get on this, go ahead.

I haven't thought much about this yet, so whatever.

Right now everybody just spawns on the same tile aaand as a result they get stuck due to the physics engine.

Even if we fix the physics deal, we should still have multiple spawn points.

if unequipping items from character's inventory, their bounding box is set in actual location of the item, while sprite gets under the character teleported to (0,0) location, making item impossible to pick up by clicking the sprite.

Raise tech levels, unlocks using materials to create new object types.
Simple various types of possible tech (steal from ss13)
Assign a few parts these tech levels
A simple machine that you use attackhand on, brings up a UI, select a research type, after certain amount of time has passed research completes and new tech level unlocks.
Finally a second machine with another UI that lets you input materials and print objects if you have the requisite tech level unlocked

A zone based atmospherics system.
Implement a flood fill algorithm to create a number of zones that are blocked off from each other with an airblocking component. Establish connection edges to space on any zones touching space.
When zones connect begin to equalize pressure and cause airflow movement from one zone to the other based on pressure differential. If blockers are destroyed create an airflow connection and finally merge after pressure equalizes sufficiently. If walls are created check to see if a new zone has been walled off.
Implement damage from under/overpressure and from not having the right gases in the atmosphere to breath.

Statuses that affect the mob directly and can be queried to ask if the mob is capable of actions.
Asking if mob is currently able to do an interaction
Preventing mob movement
Taking away sight
Adding screen overlays based on status such as health, darkness on unconsciousness, jelly screens when dead/heavily damaged

Mob Huds

A part of inventory handling and mob statuses. Implementing huds to represent things held in inventory, mobs statuses, and updating them

Implementing mob death, and unconsciousness.

Is there anything that needs done that I can give a hand with?

Following Top Priority list melee weapons are the ones which needed to make a nice demonstration.

Following Urist's design doc:

Melee weapons

Melee weapons are held items that when used with the “interact with this location” command spawn a cone hitbox from the character in that direction for a specific time. Entities that come into contact with the cone are affected by the melee weapon (this usually means damage but can be something more exotic).

Melee weapons have several characteristics:

• Angle and length of the cone, determining its area of effect.
• Windup time - how long it takes for the cone to appear after the command is issued.
• Cone duration time - how long the cone stays after it appears. Usually very short.
• Cooldown time - minimum time between the commands. Should usually be bigger or at least no smaller than the previous two combined.
• Damage type and value. By default, melee weapons apply that much damage of that type to Damageable entities hit.
• Possible overrides include changing what the “on hit” function does instead of damage, or changing the hitbox’s shape.

~

Most machines in SS13 have some sort of floating UI window that opens up when activated. We need a system in place that can manage opening up UI windows when a client activates an entity.

Requirements:

• A generic ECS Component that can be added to an entity that controls this system.
• Ability to data bind a specific UI Class to this component through Yaml.
• Opening the UI and pushing any required data to the client (Subscribing the client).
• Detecting any Client events like button presses and pushing them back to the server.
• Processing user events on the server.
• Detecting conditions for Unsubscribing the client from the Building UI System (like them dying, or moving out of range).

The specific UI classes bound to the components will be in charge of network communications, populating the UI with controls, and processing user events. There will probably be a specific class for every type of machine in the game.

The Inventory UI system is a decent working example of a similar system. You may want to research UI design patterns if you are new to UI programming, and you will need to know how to work with the Godot UI system exposed in SS14.

This issue requires #115 so that UI Windows are properly closed when the mob becomes incapacitated/blind.

Welcome to content club

Remember Urist's roadmap? THIS IS IT NOW, FEEL OLD YET?
Well, I guess it's time to organize content development in the same fashion we did so for engine's one! First we need to decide priority of features so we might create first milestone and have an actual roadmap. Below is Urist's original priority list. Feel free to suggest your options!

Top priority (so the first milestone)

1. UI (prototype - everything following will be added to the UI as it comes; but should be at least in general planned out beforehand) - #463
2. Containers
3. Player to entity interaction - #9
4. Holding and dropping items
5. Damageable entities - #10
6. Melee weapons
7. Basic inventory (toolbelt, backpack, equippable items) - #8
8. Health and stamina (non-organ based for now; will need to update it once those systems are designed) - #10

Other priority (second milestone)

1. Power system - #6, #25
2. ID system - #31
3. Remote control, signal sending - #30
4. Construction/destruction of snap grid elements
5. Temperature
6. Substances (non-discrete liquids/gasses/solids)
7. Atmos (gods this will be a doozie) (requires 5 and probably 4)
8. Ranged weapons
9. Chat system
10. Combat in general
11. Grabbing and dragging
12. Examine functionality
13. Organs
14. Basic game mode
15. Basic events

Low priority and ongoing (several milestones for later)

1. Chemicals
2. Hacking
3. AI
4. Logic computing?
5. Robutts?
6. Science + how plasma works - #29
7. Medical
8. Gravity
9. Do we even need intents?
10. Jobs
11. Radios or lack thereof :)
12. PDA functions
13. Admin tools
14. Events
15. Modes
16. Cookin with bob
17. Screw mining but gotta consider it anyway
18. Botany
19. Space fauna/critters (monkeys, space slugs)
20. Heck yeah security I love it
21. But that is part of the jobs
22. Eh fuck it might as well keep a separate point open
23. Not like I answer to anyone
24. Livin on the edge
25. i need sleep
26. Grabbing
27. Construction/destruction as in the game system
28. Space, gravity, antigravity and so on
29. Disease
30. After-round metrics and statistics
31. Janitor the garbage man
32. Blood and other substances on the floor
33. Cameras
34. Grenades, bomb assembly (and assembly in general?)
35. Gravity
36. Engines
37. Scoring is yes
38. Viruses aw ye
39. Server hub, player profile, databases, trust
40. Vent shafts?
41. Monkeys!
42. Bots (beepsky and such)

(thanks to @DeityLink for concept which I shamelessly copied from ivory tower)
When the server loads up, it generates "threat level" based on playercount/playerprefs/randomseed
(possibly weighted toward the center)

• if the number is closer to 0, there won't be many antags, the round will be akin to "extended"
• if the number is above 75, large threats like malf, blob, nuke are more likely
• And near 100, anything could happen.

The longer the round goes without any player being ghosts, the more chances the AI will decide to spawn new threats:

• If there are many ghosts, it'll spawn antag-type threats like raiders, operatives, or if the threat level is low it'll just autotator someone
• If there aren't many ghosts, it'll spawn random disastrous events

What should be in a "disaster spawning" equation?

• The length of the round?

• The current number of antags?

• The number of living players?

• The number of ghosts?

• The threat level?

• The map size?

• Should Tensioner/Threat AI/Storyteller/AI Director/Game Pacing System also manage other game progressing mechanics? (Science? Goals for you wagecucking job? Station goals?)

What it says on the thin. Should be stored client side in the user data directories so that we don't have to store them server side. Client's problems.

Ability to select a job in character setup and spawn in with certain equipment.

Requires #134

Step's to reproduce: with showbb command try to pick up an item.
What's should happen: item is placed on mob's location.
What really happens: showbb shows that item's bounding box (and actual location as well) still on the same place, but when character moves or rotates, it's moves and rotates too, but relatively to character it's still on the same distance/location.
For example: Trying to turn on the flashlight will light up area around actual location of flashlight, not character

There needs to be the ability to access the inventories of worn items, like backpacks and tool belts.

Requirements:

• Ability to access the contents of a worn inventory without unequipping it.

It is your choice how you want to implement this. The backpack or belt contents could always be displayed as a toolbar at the bottom of the screen, or you could open a UI element when clicking on the item in the character screen.

Ability to designate spots on the map as markers for stuff like spawn points, so they don't have to be hard coded.

IMO entities should be used for this because they're just transform + marker component. Some way to visualize them in build mode would be good.

Needed by #136

1. Turns off when picked up (this may be an engine issue in practice).
2. Can't be toggled.

Right now you have to IoC resolve IChatManager and get the INetChannel for the client. Of course, we do wanna cut down the amount of chat abuse, but it should still be relatively easy to do chat.

Source

Player to entity interaction

A player character (PC, mob controlled by the player) can interact with the environment by pressing primary interaction mode or secondary interaction mode (LMB and RMB by default).

The primary interaction mode is an entity-to-entity interaction mode - it checks the currently equipped object (if any), checks the entity clicked (based on clicking hitboxes) and, if the entity is within the PC’s reach, either uses the default command for the pair (if the button was just clicked) or gives a list of commands that are appropriate for the specific combination (if the button is held) - for example, using a wrench on a girder could give the “screw to the floor” and “disassemble” commands, with the default one being one of these.

The list of commands appears in a wheel around the mouse cursor and the player can select any of them by moving the mouse off center. Once the command is confirmed by moving the mouse in its direction and releasing the button, information about the PC, what command was chosen and what were the entities used and interacted with are sent in an event to both the entities and they act based on that.
The secondary interaction mode is an entity-to-location and entity-to-itself mode.

When the button is held, it provides a list of commands which the PC can do with the entity itself and a command for “interact with this location”; the default command (when the button is just pressed) is always “interact with this location”. For example, a gun could have the commands “shoot” (“interact with this location”) and “reload”, with the default one being “shoot”. These commands don’t check for reach.
Empty hands also have such commands, behaving just like held items in that regard. Honestly, maybe they should be held items.

The default action is always on the upper part of the wheel.

Commands are shown via icons or text or both, not sure yet.

Commands may be unavailable due to certain circumstances (a “shoot” command might be unavailable when the gun is out of ammo, primary interaction mode commands are unavailable when the object is out of the character’s reach). In these cases, the commands are greyed out on the wheel, with a message on top of them showing the reason why they’re unavailable.

This would be a basic Wandering AI for NPC mobs. The goal of this is to demonstrate controlling NPCs with an AI instead of player input. This feature will also provide a target for demonstrating the in-game weapons.

Requirements:

• Simple AI that can decide to move itself to a random nearby location.
• Actually walk the entity over time to the new location.
• If the AI is trying to move but isn't (because it collided with a wall or something), give up after a little time and select a new location.
• The AI should be aware of its own health, and will not try to wander when in crit or dead.

The AI does not need to be aware of its surroundings. It does not need to check collisions or any line-of-sight. It does not need to follow any sort of waypoints or collision mesh.

This feature requires #115.

Following top priority list we also need inventory for a good demonstration of features.

This is what Urist wrote on this subject (consider this headcanon):

Inventory

Mobs have several slots they can put items in, based on the organs of the mob and possibly items in other slots. These work as separate container entities. All of the slots that the mob has are shown on the UI (see the example) and can be interacted with as normal; they are always considered to be within the mob’s range. Worn items can affect the characteristics and behaviour of the mob.

One of the commands available for Container objects that hold HeldItems is “open”. It is a primary command always available regardless of the current item in the hand or a secondary command available when you have such a Container in your hand. When you open such a Container, a window pops up showing all its slots and items currently inside of them, if any. As long as the Container is within the mob’s interaction range, objects inside of it are considered within his interaction range too. The window can be closed via the close button in the corner.

Items can be dragged from inventory slots or the world map to inventory slots by clicking the LMB on the item, holding it, dragging it to the slot desired and releasing the button. If the slot can hold the item, it is moved there.

If a mob has a toolbelt equipped, it works as his hotkey bar. Each of the toolbelt’s slots is mapped to a key in the 0-9 range and by pressing that key the player controlling the mob can:

• If there’s an item in the current hand, it can go to the corresponding slot and the slot is empty, the item is put into that slot.
• If the current hand is empty, the corresponding slot has an item and the item can go in the current hand, the item is put in the current hand.
• If there’s an item in the current hand, the corresponding slot has an item and they can swap (meaning that both slots would be able to hold the others’ items were they empty) then they swap.
• If any of these scenarios occur, that slot is marked as “last used”. By pressing a hotkey a player can quickly access the “last used” toolbelt slot using the same behaviour as above.
• Accessing the backpack can also be done by using a hotkey (“I” by default) instead of using the “open” command on it as usual.

For now, the following inventory slots should suffice. I’m including organ-based stuff but that should only be worked in when organs are in, obv - organs shouldn’t come first:

• PDA/ID (provided by some clothing)
• Clothing (provided by the body organ)
• Toolbelt (provided by the torso organ)
• Ears (provided by the head organ)
• Mask (provided by the head organ)
• Hand x2 (each provided by an arm organ)
• Back (provided by the torso organ)

~

@clusterfack

Right now they're just direct arguments like in BYOND, but this means adding new parameters is a breaking change and causes refactors. Would be nice if they were event args.

Since powernet need machines to work let's throw another Urist's concept to your consideration! Urist read thousands game design's books after all!

Overview

Devices (possible for other entities too but mostly devices; the gates, for example, probably wouldn’t be devices) send signals to each other using two components, RCInput and RCOutput (RC for Remote Control). Most complex interactions involve this standartized system - have the entity’s own code operate what it sends via RCO and how it behaves on receiving signals via RCI. A supplemental RCOutputUI component is used for when you need to provide the player with the means to edit which RCInputs an RCOutput is connected to.
Signals can be instant or continuous and contain a string as their value.

RCOutput component

An RCOutput’s properties are its range, connected RCInputs and current continuous signals being output. It can have any number of RCInputs connected to it at a time. When the entity or another component tells RCO to output a signal, it informs all connected RCIs of its value. If it’s a continuous signal, the RCIs remember it, and the RCO will tell them if it gets disconnected, the continuous signal stops or its value changes. If an RCI is connected to an RCO while the RCO is outputting a continuous signal, it gets told about the signal.

RCInput component

An RCInput’s properties are its connected RCOutputs and current continuous signals being input.
It can have any number of RCOutputs connected to it at a time. When it receives a signal or an update on a continuous signal it informs other entities/components that rely on that information about it.
An RCInput component can have a flag that on interaction with its entity requests the one performing the interaction to automatically try to perform an interaction with all the connected RCOs in its reach. This can be helpful for things mobs often interact with, like doors - a mob bumps into a door, the door asks it to press the connected button, the mob does so because it’s inside the mob’s reach, the door receives the signal and opens; all without the player doing anything sans bumping into the door.

RCOutputUI

A simple UI that gets all the RCIs within an RCO’s range and lets a player using it connect/disconnect them.

Examples of usage (Content?)

• Logic gates - RCI, RCO.
• AND: outputs an instant “true” signal when receives signals from all connected RCOs within a certain timeframe (property) and at least one of them isn’t continuous. Outputs a continuous “true” signal when all connected RCOs output continuous signals.
• XOR: relays a signal from one of the connected RCOs while all other connected RCOs aren’t outputting signals.
• OR: outputs an instant signal defined by a property when one of the other connected RCOs outputs an instant signal and not outputting a continuous signal. Outputs a continuous “true” signal when one of the other connected RCOs outputs a continuous signal.
• NONE: outputs a constant signal defined by a property while none of the connected RCOs are outputting a signal.
• Signal splitter - RCI, RCO. When it receives a signal, based on the signal’s string and the splitter’s settings, sends it to a specific connected RCI. For example, a splitter could be connected to an ID reader and send a signal to a door when it receives a “passed” signal and to a turret when it receives a “failed” signal.
• Button - RCO. Sends instant signal defined by a property when used.
• Switch - RCO. When used, switches between on/off. While on, maintains a constant signal defined by a property.

Shoot gun diagonally.

Bullets defy the laws of physics.

As Urist wrote:

Health

When a mob takes a certain amount of damage it goes into a criticial health state. At that point it loses all stamina without being able to restore it, falls down, starts taking small amounts of passive damage over time, every action, speech and movement inflict additional damage. At a certain damage threshold the mob falls unconscious, and at another dies completely.

Stamina

Mobs have a stamina value. Stamina passively acts as defense against disabling conditions (and something you need to inflict disabling conditions) and actively as a resource. Stamina regenerates over time, starting after a brief period of windup after each time you spend stamina. Stamina gets telegraphed somehow.

As a defense against disabling conditions, it makes it so whenever there’s a >0% chance that a disabling condition will be applied to you and you have 0 stamina, that chance becomes 100%. As something you need to inflict disabling conditions, when you wield a melee weapon that has a chance (including 100%) of inflicting a disabling condition and you have 0 stamina, that chance becomes 0%. So, if two people at zero stamina fight with melee weapons, they won’t disable each other.

As a resource, stamina is expended on:

Melee weapon attacks. Even if you have 0 stamina, you can perform such attacks, but see above about the disabling conditions.
Sprinting. Mobs can increase the speed they move at by sprinting. Sprinting expends stamina. You can’t sprint if you have 0 stamina.
Defense against environmental hazards such as lack of oxygen and smoke. While in conditions where a mob can’t breathe, before actually taking damage or other negative effects from it, he’ll expend stamina first. Once stamina is at 0, that defense stops working.
Adrenaline burst. While at 90%+ stamina, a mob can perform an adrenaline burst. This reduces his stamina to 0 over a brief period of time but gives some benefits during that time - the mob sprints without cost, gets rid of all disabling conditions it currently has and becomes immune to them.

Statuses

Statuses or conditions are temporary (or not) effects that affect a mob’s behavior inflicted on it with external forces. Those are disabling and restraining conditions, the former of which are affected by the stamina system, unlike the latter. Disabling conditions are almost universally temporary. Restraining conditions are often non-temporary, based on permanent damage or items used on the mob.

Disabling conditions:

Knockdown - a knocked down mob can’t move normally, only crawl slowly.
Stun - a stunned mob can’t move or perform actions.
Daze - a dazed mob can’t move, perform actions, see any farther than a short range around him or speak. He drops the items he’s holding.
Unconscious - as daze, but can’t perceive anything at all and is knocked down.

Restraining conditions:

Blind - the mob can’t see. Has different levels of severity, ranging from “no seeing at all” to “muddy vision”.
Mute - the mob can’t speak.
Handcuffed (or whatever to call it) - the mob can’t perform actions.
Immobilized - the mob can’t move.

After some bikeshedding on Discord, we've had some ideas regarding how computers should work.

No special circuit board computers. Different functions are software based. Most computers either interact with say servers on a network, or tell other machines to do things.

This would be a basic health system for mobs. Nothing fancy, just something that can be used to demonstrate combat.

Requirements:

• At least a HP Value from 0 to 100.
• Basic Mob health states (Normal, Injured, Crit, Dead) that can be polled by other systems. These can be implemented as thresholds of the HP value.
• Events raised when Healed, Damaged, or State change.
• Basic HP packs that can be used on a mob to restore them. This does not need to be complex, it can literally just be an item that restores HP when used.

There already exists a damage system in Content.Server, it may be a good starting point.

This issue requires #42

Copied from Urist's design doc:

Held items

A mob has a container with X hand slots, usually 2. He can switch between them freely (using the mouse wheel? hmm). A hand slot can be empty or it can contain a held item. The item (or emptiness) in the currently selected hand is used as the “currently equipped” value for PC interaction with the environment.

The default command when using primary interaction mode with an empty hand on an item that can be held is “pick up”, and this command is only available in these circumstances. Picking up an item places it into the current hand slot.

Some items may occupy multiple slots. In that case, picking up that item will push around your inventory so the items can be in two consecutive hands.

All held items have a “drop” command in secondary interaction mode, always in the same place on the wheel (probably left part). It drops the item under the character’s feet, leaving that hand empty.

All held items also have a type tag that can be “default”, “none” or one of the specific other types. This determines in what kind of toolbelt slots it can go. “Default” can go only to non-specialised toolbelt slots, “none” can’t go to toolbelt slots and specific types can go to toolbelt slots of that type or to non-specialised slots.

(it's now separate issue)
Should make appearance visualizer for that

Let's discuss what it should be. As Urist wrote in his design doc:

UI

http://imgur.com/pxb4Dgd

• Okay so all windows should be resizable and movable; viewport should be always stretching to hit the screen (horisontal or vertical depending on whether the height or the width is bigger) while maintaining square shape and the same actual viewing area.

Some unobvious stuff:

• Chat has filters you can switch on and off
• Toolbelt is a hotkey bar. Colour of hand in toolbelt slot shows that the currently selected item in that hand came from that slot in toolbelt and pressing that key again will stow the item back. Small bar on the bottom of the cell shows type of item that can go there (orange for engineering for example).
• PDA modules are basically things you can turn on in the PDA having the appropriate module that provide you with some info at all times.

• You cannot start deconstruction on something that's already built. Deconstruction DOES work on in-progress frames though.
• Construction state is not stored with ExposeData.
• Deconstruction does not return materials.
• Construction doesn't actually use the material prototypes defined in #84, it's hardcoded to stack type. It SHOULD use these and then allow storage and re-referencing once say a wall is constructed to change its properties.
• In-hand construction does not work because the hands GUI doesn't do attackby. Kinda a nuisance.

Now that we have a proper construction system, spawning entities and tiles should be restricted to admins.

Requirements:

• Prevent clients from using the placement system unless they are admins.

~

Steps to reproduce: take a backpack, switch hands, take an item, try to put item into backpack by clicking on backpack with item in hand. Or, take a flashlight, take battery out, with battery in hand and flashlight in offhand try to put battery back.
What should happen: you should be able to put an item into backpack.
What really happens: nothing.

The reference to OpenTK needs to be removed from all of the Content projects. There should be no OpenGL calls in the content projects. Any OpenTK.Math references can be replaced with our SS14.Shared.Maths library.

Requires #600

Should be done with overlays. Might (hell, probably will) need a way to do persistent canvas items in the overlay system, which will be a can of worms to implement.

Also there is no move code in content which could prohibit mob from moving, i guess move code is in engine

When entering crit or dead state, game applies a screen effect and lowers FoV, but when you exit into main menu, this effect is still applied.
It also happens when you switch mob state from crit/dead to healthy, although it may be a different issue(related to #145)

~