28 Oct, 2009, Scandum wrote in the 41st comment:
Votes: 0
quixadhal said:
So, without having looked at your TITS, would this be one way to model the above safely?

Bob begins crafting a sword.
Event happens, creating an incomplete sword object.
The sword object begins completing itself on a timer, adding a percent
every N minutes that it, Bob, and the workbench are together.

Ideally you'd want to place the player in a crafting state, and the sword would keep track of the progress as its state is steadily altered toward being finished, but the sword itself shouldn't be doing anything. If Bob leaves to answer the door that would change his state, and subsequently stop anything associated to that state, including the crafting of the sword. In an ideal situation the unfinished sword wouldn't be replaced by a finished sword either. If a bandit was to enter the store Bob should be able to pick up the unfinished sword and defend himself.

I think the trouble starts when the events are supposed to keep track of an object's state, or detect when a state change has occurred.

staryavsky said:
It seems like if you passed enough arguments to the event, you could accommodate
for any potential logic conflicts. But then again, I'm not as experienced as Tyche or others yet, so I must be missing something.

The more information carried by the event the more information is lost when the event becomes invalid, so I'd say the trick is to store the various states and data on the objects and keeping the events as simple as possible.
28 Oct, 2009, David Haley wrote in the 42nd comment:
Votes: 0
Koron said:
Just because Bob logs off doesn't mean his crafted item is destroyed. If he's whittling a staff, there's no reason to expect interruptions to do anything other than delay completion. Real world complications may arise as you try to decide how to store these states. Woo!

This is a very interesting distinction IMO: the difference between global time and "character time" or "session time". Many events are indeed global, but others only make sense during the lifetime of a character – and when you have characters like players that can appear and disappear "at will" you need to decide if the event persists along with them. This seems far-fetched, until you think about relatively common situations like duration spells: should these all disappear when the character logs off?
28 Oct, 2009, Erok wrote in the 43rd comment:
Votes: 0
Erok said:
I'll take a look a SocketMud, and see how much effort it would be to migrate it to libevent. It sounds like it would be helpful to have a reference implementation of an event driven MUD available.

I've got this mostly working now.

Socket i/o is handled asynchronously, and there are two repeating jobs (events, timers, whatever). One fires every 10s to call recycle_sockets(), and the other fires every pulse to call update_handler(). Whatever update_handler() is supposed to do (presumably combat and all that other good stuff), it could be broken up into smaller jobs (single shot or repeating) that are handled independently of each other.

I need to handle shutdown, copyover, and clean things up, and then I'll upload it here. It's not beautiful, and this was my first foray into libevent, which isn't as nicely designed as ASIO, but it was relatively painless to get going.
29 Oct, 2009, Erok wrote in the 44th comment:
Votes: 0
Erok said:
I'll take a look a SocketMud, and see how much effort it would be to migrate it to libevent. It sounds like it would be helpful to have a reference implementation of an event driven MUD available.

Ok, I just uploaded EventMud-1.0 under the SocketMud branch in the code repository (it won't show up until cleared by the admin staff).

Disclaimer: This was the first time I'd looked at either SocketMud or libevent, so quality is neither guaranteed nor implied.
29 Oct, 2009, Tyche wrote in the 45th comment:
Votes: 0
quixadhal said:
Bob begins crafting a sword.
Event happens, creating an incomplete sword object.
The sword object begins completing itself on a timer, adding a percent
every N minutes that it, Bob, and the workbench are together.
Bob leaves the workbench to answer the door.
Event happens, The sword object stops updating, since Bob is not present.
Bob returns.
Event happens, The sword continues updating, since all three components are present.
The sword's completion percentage hits 100%.
Event happens, incomplete sword object replaced with crafted sword object.
Bob goes out and drinks a beer.

If I'm buying into the theory, each event is a state change, but the actual timer-based actions are not events but listeners which may change their behavior based on events they observe. If the shop catches fire and destroys the workbench, that would presumably generate an event which the incomplete sword would see as a component becoming unavailable.


A timer event is just a state change in time, informing any object listening that the time changed.
If I were doing a simulationist crafting game, I'd do pretty much what Scandum described. I'd check that the resources were present to build the item, put the character or characters in a crafting mode, make sure I'm registered with a timer, and then begin tracking completion of the item as I receive time events. If resources or characters disappear, or go out of crafting mode, we don't continue to progress the crafting. I'd probably create a crafting job, so multiple resources, products and characters could be associated with it, rather than put all the state tracking in the product (sword).
40.0/45