Oh, also a few more concerns have been raised by secretsnail (who sadly
couldn't come to the computer right now, so here are their comments from le
discord.)
1. What is the ultimate goal of petrinets? What are gap are they trying to
fill?
2. How would an officer report on these?
3. There's no actual way to make lockers yet.
On Tue, Aug 16, 2022 at 2:49 PM Forest Sweeney <notorious...@gmail.com>
wrote:
> I do like this, but I have serious doubt it will pass at current-state
> Agora:
> 1. on discord, the current attitude is "no more subgames pls"
> 2. The power level to override some of the other rules (eg liquid assets)
> is insane, so that will be a huge hurdle (in addition to the overall
> complexity) of gaining Agoran Consent.
>
> Anyhow, my review:
> 1. I have a problem with the terminology. Overall. I'd say petriplaces
> should be petribags (hold tokens), petransitions should be petrinodes
> (nodes can fire), and the petrivalence is the petransition (valence just
> seems like a silly word, and the word transitions make it clearer that the
> bag changes based on these).
> 2. I think we prefer switches at all times if possible.
> 3. Lockers are an asset, so they can be given, but also, it's unclear how
> they can be taken. Assets already have owners, so this poses a problem,
> since the attribute is being double defined.
> 4. Because these are so intricate, I doubt we need more than one petrinet,
> so it's a little overkill to allow multiple. However, unfortunately, this
> does leave the open question on how you would extend or reduce an existing
> petrinet. I would personally only want one to exist.
> 5. Example Interfaces:
> Name: Lockerswitcher
> Additional attributes: A Locker.
> Conditions: Fireable Whenever.
> Action: The Locker is transferred to the player who fired the
> Lockerswitcher.
>
> Name: Playernode
> Additional attributes: a player.
> Conditions: Fireable only by the specified player.
> Action: Nothing.
>
> Name: Stamper
> Additional attributes: none? a player?
> Conditions: Fireable whenever.
> Action: A stamp of the player who fired/specified player is created in the
> ownership of the player who fired the Stamper.
>
> etc...
>
> 6. This feels particularly complicated, so I made a diagram of what I
> think was intended. It's basically a bipartite graph. If I call this
> diagram 'Bobnet' then it is also a machine, if I pay the coins and such.
> Now, this is what I garner from the rules on how firings would work:
> Example: following the diagram, say we want to fire interface P:
> We'd increase the petokens of A by 1, B by 2, and C by 3. We could always
> fire P as long as the petokens on each node are >= -1, -2, and -3,
> respectively.
>
> For Firing Q, we need at least 1,2,and 3petokens in A,B,C (respectively),
> and then we'd remove 1 petoken from A, 2 petokens from B, and 3 petokens
> from C.
>
> And for firing R, we need at least 1 petoken in B, and when fired, we'd
> remove 1 petoken from B.
>
> Diagram:
> [image: image.png]
>
>
> On Tue, Aug 16, 2022 at 6:39 AM juan via agora-discussion <
> agora-discussion@agoranomic.org> wrote:
>
>> My peeps,
>>
>> I'm working on a draft for some rules. I humbly ask for y'all's
>> opinions. Do you have any interest? Also, what would be the best
>> practices to implement what I'm trying to?
>>
>> My intention is that new Interface types could be created to allow for
>> more, more interesting interactions.
>>
>> {
>> ------------------------------------------------------------------------
>> Machine Definitions
>>
>> A Petriplace is an entity defined by a unique name among
>> Petriplaces in the same Petrinet.
>>
>> A Petransition is an entity defined by a unique name among
>> Petransitions in the same Petrinet, along with a Type of either
>> Internal of Interface.
>>
>> A Petrinet is given by a set of Petriplaces, a set of
>> Petransitions, and for every Petriplace and Petransition, an
>> integer (defaulting to zero if unspecified) called the
>> Petriplace's Petrivalence for that Transition.
>>
>> Petokens is a Petriplace integer switch with default value
>> zero.
>>
>> Given a Petrinet, one of the Petransitions is Enabled if for
>> every Petriplace in that Petrinet, its Petrivalence summed with
>> its Petokens switch's value is nonnegative.
>>
>> ------------------------------------------------------------------------
>> Interface Petransition Types
>>
>> In case a Petransition is an Interface, it also has two other
>> textual attributes: Conditions and Actions.
>>
>> Other rules nonwithstanding, An Interface transition CANNOT be
>> Fired unless its Conditions are met. When Fired, an Interface
>> transition causes its Actions to be performed.
>>
>> The possible Interfaces types are as follows, specified as a
>> Name, additional attributes, its Condition, and its Actions.
>>
>> * Lockerswitcher. A Locker. Whenever. The Locker's owner switch
>> is flipped to the Firing player.
>>
>> ------------------------------------------------------------------------
>> Machine Entities
>>
>> The Machine Yard is an entity.
>>
>> Machines are assets tracked by the Machinist and ownable by the
>> Machine Yard. Their essential attributes are solely a unique
>> name among Machines. Machinestate is a Machine switch tracked by
>> the Machinist with values over Petrinets, and default value the
>> Petrinet with no Petriplaces and no Petransitions.
>>
>> A Player CAN create a Machine under the possession of the
>> Machineyard by specifying its name, a Petrinet, and paying a fee
>> of 1 BoC.
>>
>> A Player CAN, by announcement, Fire a specified enabled
>> Petransition in a specified Machine. When e does so, that
>> Machine's Machinestate Petriplace's Petokens switch are flipped
>> to their current value summed with their Petrivalence for that
>> Petransition.
>>
>> In a message where e Fires a Petransition, a Player SHOULD also
>> publish the specified Machine's new Machinestate.
>>
>> The Machinist CAN, with no objections, destroy a specified
>> Machine. E SHOULD do so if a Machine hasn't been used for too
>> long.
>>
>> ------------------------------------------------------------------------
>> Lockers
>>
>> Lockers are assets tracked by the Machinist and ownable by the
>> Machine Yard. Lockerowner is a Locker switch with values on
>> Players or Unassigned (default). Other rules notwithstanding, a
>> Player CAN, by announcement, transfer any liquid asset e owns to
>> a Locker of which e is the Lockerowner, and similarly transfer
>> any assets from such a Locker to any entity that can own that
>> asset.
>>
>> A Locker is empty if it does not own any assets.
>>
>> A Player CAN, by annoucement, flip a Locker's Owner switch to
>> emself if it is Unassigned. A Player CAN, by announcement, flip
>> a Locker's Owner switch to Unassigned if it is emself if it is
>> empty.
>>
>> ------------------------------------------------------------------------
>> }
>>
>> Specific problematic points:
>>
>> * I really don't know when to use switches and when to directly define
>> attributes.
>>
>> * I can't tell the best way to define the Interfaces (I guess something
>> akin to Birds or Stones, but only for Transitions with a particular
>> Type).
>>
>> --
>> juan
>>
>
>
> --
> 4st
> Referee
>
--
4st
Referee
