SS14s DeviceNet is inspired by goons version of packets ^wiki and allowing players to see packets and send their own in a limited capacity is something I want to also implement in SS14. This document is going to mention some of the ideas in Devicenet Ideas and Cartridge Loader. Implementing the proposed features is going to require Device networking access restrictions. Receiving packets When a packet is displayed to the players only primitive types and maybe types that are designated as being displayable in some way will be displayed to the player. Players will generally be able to receive and inspect packages using the planned NetSnooper cartridge and NetMonitor cartridge. In addition to that certain players will have access to the NetSecurity cartridge which allows them to see and inspect packets sent by other players. The NetMonitor cartridge allows players to set their pda to notify them when it receives packets that match some conditions given by the player.

To prevent everyone from say, setting an air alarms mode to panic using their PDA for example, devices need some way to restrict who can send them packets. This should ideally be done using the access permissions we already have with id cards. An engineer or a head should be able to change the settings of an air alarm using devicenet if they have their ID inserted into their PDA. This should only be necessary for packets that get sent manually and for that packets should have a way of identifying if they are constructed by a player or not. The NetworkAccessRestrictionComponent & System This works like other connection components like the WirelessNetworkComponent or the DeviceListComponent in that it can prevent packets from being sent.

Rich text needs to parse and store parsed markup. Then the parsed markup needs to be processed and rendered. The current rich text implementation uses a flattened tree structure and the parser parses the start tag, the contained text and the end tag seperately. In addition to the single tag type color being hardcoded into the parser. I want to improve on that by making the parser more flexible and changing the process of rendering the markup while keeping changes to rich texts public api minimal. Current RichText Current RichText isn't that bad once you understand how to read Pidgin parsers. The biggest problem with current RichText is its inflexibility and the fact that it only supports one tag: color.