Proposal : Crash!

[ As discussed, we should probably deal with the MCP crashing... ]

Add to Rule 11 (The Master Control Program), before "Where there is any disagreement":-

Certain execution errors will crash the MCP. These are specifically defined as:-

Getting stuck in an infinite loop.

Encountering a line which opens more brackets than it closes.

Attempting to use a variable (such as 'X') which has not been previously set.

If the MCP crashes, it aborts with no further effect (although instructions executed until that point still stand) and the Robot who was running it should alert the other Robots via the weblog.

Enacted by Kevan, 7th Oct. +17 to Kevan.

Proposal : Product Usage

To Rule 13 (Inventory), add:-

The Factory's Product is a versatile multi-purpose piece of electromechanical hardware, designed for both civilian and military use. Robots are discouraged from operating items of Product within the Factory.

To the MCP, add (immediately before venting):-

// !!! Robots are discouraged from activating Product within the Factory.

if (keyword = "ACTIVATE_FIRE" && inventory(self) contains product_object) 

{ 

  // Release electrical charge, powered from batteries.

  power(self) = power(self) - 10

  power(other) = power(other) - 30

  

  // !!! Penalty

  efficiency(self) = efficiency(self) - 2

}

Enacted by Kevan, 7th Oct. +17 to Kevan.

Proposal: Product sales

alter the Glossary so that the following sentence:

Liquid Power - Liquid power is the total power a robot would have if their entire assets were liquidated at the same value at which they were originally produced plus the power they already have stored away as noted by the GNDT.

is replaced with:

Liquid Power - Liquid power is the total Power a Robot would have if their entire assets were liquidated plus the Power they already have stored away as noted by the GNDT. Batteries can be sold at the same value at which they were originally produced, whilst Product can be redeemed at it's retail value of 20 Power, regardless of the Power taken to produce it.

Enacted by Kevan, 4th Oct. +16 to Est, +5 to Kevan.

Proposal: Overpower

Add at the end of Rule 15 - Malfunction:

If the liquid power of the Control Unit is ever exceeded by the liquid power of another robot by a margin of 150 or more, the Control Unit will short circuit and the Robot with the highest quantity of liquid power shall become the new Control Unit.

Failed by Kevan, 4th Oct. -5 to Damanor, +2 to Kevan.

Proposal: Overload cut-off, take 2

Make the following changes to Rule #11 - "Master Control Program"

add :

if (power(loop_robot) > (100*(1+number_of_batteries(loop_robot))))
{
   power(loop_robot) = (100*(1+number_of_batteries(loop_robot)));
}

after

power(loop_robot) = power(loop_robot) + 50;

to prevent the overloading of a robot's power.

Enacted by Kevan, 4th Oct. +16 to Est, +5 to Kevan.

Proposal: More Virus Fun (Trivial)

There is a slight chance of a problem with the virus interacting with the MCP in weird ways.
In Rule 12, in the MCP Source Code, where it reads:

//Create a single item of Product
if (efficiency(self) > 3)
{X=10}
if (efficiency(self) < 4)
{X=15}

Alter it to:

//Create a single item of Product
X=10
if (efficiency(self) < 4)
{X=15}

Explanation: Pull out your copy of the MCP Source Code. If the Virus infects the MCP Source Code and changes either the 3 or 4 in this subroutine, then for certain levels of efficiency X becomes undefined. If the 3 is doubled (to 6), a robot with efficiency from 4 to 6 would not have X defined in either "if" statement, and would not be able to subtract it from the power in the next section of code, where {power(self) = power(self)-X}. The same thing happens if the 4 is halved, for efficiency from 2 to 3.

With the change, X would be defined for everyone initially, and then changed (if applicable) as the MCP moved in sequence to the next line.

I hope this makes senseto everyone. The odds of it happening are pretty tiny (with the present ruleset, 1 in 221, averaging once every 4 years or so) but with Murphy's Law in effect at all times, this seemed like a reasonable patch for otherwise flawless code.

Enacted by Kevan, 2nd Oct. +2 to Damanor, +2 to Kevan.

Proposal: No Easy Cure

In Rule 14 (Virus!), add at the end of the rule:

That number may not be altered by a rule change proposal for one full week.

[To prevent pelayers from just changing numbers back to their original state]

Failed by Kevan (timed out 2F3A), 2nd Oct. -5 to Royce, +2 to Kevan.

Proposal : Pro-Virus [Trivial]

In Rule 14 (Virus), replace:-

That number has a 50% chance of being halved (rounding up), and a 50% chance of being doubled.

with:-

That number has a 50% chance of being halved (rounding up); if it is not halved, it is doubled.

[ Fixing the ambiguity, and the risk of one number being mutated but not the other. Elegantly, the lower this number gets, the more likely it is to be raised, and vice versa. ]

Enacted by est 1st Oct. +2 Kevan, +2 est.

Proposal : Handoff

Add some new syntax to Rule 11 (The Master Control Program), after "if":-

other. "other" represents any other Robot in the Factory; the Robot calling the MCP should choose a single Robot at the start of the program.

Add to the MCP, before the "vent excess power" section:-

// Robots may hand off Product to other Robots to increase their efficiency.

if (keyword = "HANDOFF" && inventory(self) contains product_object) 

{ 

  inventory(self) = inventory(self) - product_object

  inventory(other) = inventory(other) + product_object

  efficiency(self) = efficiency(self) + 1

}

Enacted by est 1st Oct. +12 Kevan, +5 est.

Virus!

This week the Virus has attacked Rule #19 - Ascension.

It has halved the starting Power of any new Control Unit to start this week to 50.

Proposal: Overload cut-off

Make the following changes to Rule #11 - "Master Control Program"

add :

power(loop_robot) = (100*(1+number_of_batteries(loop_robot)));

after

power_unit(loop_robot) = power_unit(loop_robot) + 50;

to prevent the overloading of a robot's power.

Failed by est 1st Oct. -5 est, +2 est.

Nomination

Kevan is nominated as the person responsible for me joining.
I hope this goes in soon enough for him (and me) to get the Power.

Proposal: Forever Is A Very Long Time

Robots should only vote FOR this proposal if they have already voted FOR Proposal: Termites.


enact a rule entitled "Malfunction":

Should the Control Unit's liquid power fall below that of the liquid power of the Robot that has the least quantity of liquid power then the control unit shall short circuit and the Robot with the highest quantity of liquid power shall become the new Control Unit.

Perhaps someone who knows this MCP language can draft a trivial proposal that will put this into the MCP. I am not sure whether it has to be in the MCP to actually take effect. The MCP has been the source of my recent blaseness with regard to this game as of late.

Enacted by est 1st Oct. +10 Aaron, +5 est.

Proposal: Termites

add to the glossary the following term:

liquid power - Liquid power is the total power a robot would have if their entire assets were liquidated at the same value at which they were originally produced plus the power they already have stored away as noted by the GNDT.

Enacted by est, 1st Oct. +2 Aaron, +2 est