ACS CyberCore 2016

Unit Message: The message that is llOwnerSay()ed to the unit when the Protocol is Activated. Defaults to, “Your name protocol has been activated. Check your mirror (url) to see the # Rules imposed.” You can change it to be more specific. (7/16/17: Yes, this should be added. Otherwise it’s up to the programmer to include a *[[ccmd>self] command in the Signal that activates the Protocol if they want to be sure the unit even notices the protocol is active.)

Like on a workbench or bed.

no task description

no task description

starbabe1701 is the latest to express interest, but others have as well.

no task description

<p>Export a program so someone else can put it on their remote?</p>

no task description

no task description

<p>Could replace the punctuations system with one that requires multiple typing. Type each word twice, or it doesn&#39;t appear... or three times, when power is lower. Something like that.</p>

<p>&nbsp;</p>

<p>When, for example, I try to change a package name to an invalid value, the server properly throws an exception, which the browser reports - but the invalid name is still displayed in the tree. We should validate in JS before talking to the server, set the value back to what it was before the change, AND handle it properly if the server catches something the browser didn&#39;t.</p>

<p>When a Record is installed, all Protocols attached to it are also installed. So it wouldn&#39;t make sense for one of those Protocols to require a higher access level to install than the Record does.</p>

<p>Same is true for Controls/Signals.</p>

<p>Should be consistently coremodel, coreversion, coreappend, coredescription.</p>

<p>Should be owned by one script - CyberCoreInterface. (Not ServerLink, as that might be shared with other core types.)</p>

<p>&nbsp;</p>

<p>1. If RLV is available, the Core and attachements should always be locked. (Use workbench to remove, or relog w/o RLV. Should also be a cheat for me.)</p>

<p>2. Eliminate the Bolted scope/protocol/state. IC, a unit can never remove its own core.</p>

<p>&nbsp;</p>

<p>Because they&#39;re in three different places (CCU-to-Orix, CoreWeb, and CyberCore), from many different era/sversions, with likely duplication. And I&#39;ve probably forgotten more of it than is good for me.</p>

<p>The server currently separates Core, Config, and State. The core doesn&#39;t really do that. Should it?</p>

<p>PROBABLY. Items in Config can only be changed using devices - Workbench or Programming Pad. The core itself never requests such a change. The command may go through the core, but it&#39;s not a regular mcStatesChange. (So what is it? And have I implemented that?)</p>

<p>&nbsp;</p>

<p>Add &quot;powered&quot;,&quot;electrical&quot; - this becomes how a full shutdown or standby is represented.</p>

<p>&nbsp;</p>

<p>&nbsp;</p>

<p>A toolkit. Hand attachment and HUD attachment. HUD lets you select a tool (chooses animation and which tool is visible), work on a standing or lying down unit, and choose where along the unit you&#39;re working. Detects the unit with a sensor.</p>