TeensyMud : Forum

Subject: Release 2.8.0 [priorities beginning to gel]
Author: Tyche
Posted: 01/18/2006 02:01AM

I started prioritizing the next set of features.

Release 2.8.0 [beginning to gel] - estimated date Feb 5

1. engine refactoring
2. system/world object
3. enhanced account support
4. hamster enhancement
5. boolean expression parser
6. move logging configuration into configuration file
7. SQLite database support

I cut it off there as it does look like seven features seems to be my average and a goodly and holy number. These are not quite as ambitious as the last set of changes which was five in number and turned out to be seven.

Also check this out this here. Just as an idle experiment I wired the web site into a live TeensyMud running locally on SDBM. Obviously I did not spend any time making it pretty. It'd be much easier were I working with SQLite, so that's on me list above.

Security which did not make the list is a definite for 2.9 as it is my precondition for running a live development demo/chat mud server here. One of the optional Account configurations will be to use TeensyWeb's account system as a single point registration for the wiki, forum and development server.

Oh yeah... The secret code name for the 2.8 release is HOOTERS. Pass it on.. ;-)

Subject: Release 2.8.0 [priorities beginning to gel]
Author: Tyche
Posted: 01/23/2006 05:09AM

Tyche wrote:
> I started prioritizing the next set of features.
>
> Release 2.8.0 [beginning to gel] - estimated date Feb 5
>
> 1. engine refactoring
> 2. system/world object
> 3. enhanced account support
> 4. hamster enhancement
> 5. boolean expression parser
> 6. move logging configuration into configuration file
> 7. SQLite database support

Revised esitimate - Feb 2nd.

1. engine refactoring - done
2. system/world object - done
4. hamster enhancement - done

All checked into repostory. The Hamster is dead and its functionality has been moved into World. I updated the SystemView to reflect the current state of the system. What you might notice is the movement of things at the CORE level into Objects.

6. move logging configuration into configuration file - canceled/postponed.

Just fancy fluff at this point. It gave me a headache, and doesn't move the server closer to the first major milestone, which I want to achieve by April 1st.

3. enhanced account support

Account really needs to be an Object in the database. Now what's bugging me are the infinite ways one might want to set up the relationship between Accounts/Players/Characters. Much of what's in Player is really account information. Some of it is Character information. It's my goal with the game I'm building to have Accounts owne multiple Characters. Some may prefer the traditional Diku model of Account == Character. In either case there are clearly two separate pieces of data, non game data (session, color, termimal info) and in-game data (stats, skills, etc).

5. boolean expression parser

Had a brainstorm with these farts triggers. Triggers will become generic objects, independent of the object they are installed on. Each object will retains a list of Trigger object ids. This allows shared use, and reduced object size.

Each trigger will have a type code which determines what processor will execute it. This makes it open ended. It could be a Ruby script, Farts script, my Boolean expression parser above, or some other Tiny Language of one's own invention. And like I said earlier I have no future plans for extending or enhancing FARTS. It was only a proof of concept model.

7. SQLite database support

Still to do.

----

If you look at the new cmd_look.rb and cmd_set.rb, you'll see the code getting simpler with the changes to calling delegating functions from root and world, instead of this stupid global $engine variable that's now history.

Subject: Release 2.8.0 [priorities beginning to gel]
Author: Massaria
Posted: 01/23/2006 11:11AM

Nothing much to say, just wanted to add a quiet 'yay' :-)

Especially looking forward to the new account system - the separation of account/player and character is integral to my plans too.

The new engine setup is looking very good too. Much simpler ;-)

mass.

PS: where's the Hooters? Big'uns?!?

Subject: Release 2.8.0 [priorities beginning to gel]
Author: Tyche
Posted: 02/03/2006 10:24AM

Tyche wrote:
>
> Revised esitimate - Feb 2nd.
>
> 1. engine refactoring - done
> 2. system/world object - done
> 4. hamster enhancement - done
>
> All checked into repostory.

3. enhanced account support
5. boolean expression parser - done
7. SQLite database support - partial

8. revised and updated regression tests - done
9. generic Trigger object

Revised estimate - Feb 11th

Subject: Release 2.8.0 [priorities beginning to gel]
Author: Massaria
Posted: 02/16/2006 05:05PM

Tyche wrote:
> Revised estimate - Feb 11th

It came and went, and some of us is on a schedule here. Not me, mind you, but nevermind that ;-)

Mass.

Subject: Release 2.8.0 [priorities beginning to gel]
Author: Tyche
Posted: 02/19/2006 01:17AM

Massaria wrote:
> It came and went, and some of us is on a schedule here. Not me, mind you, but nevermind that ;-)

Yep. I need to get back working on it. I discovered that what I'm trying to do with scripts/triggers is actually called AOP or Aspect Oriented Programming. I got sidetrack in learning AspectR? and Needle, which you can get from RAA and Gems respectively, as they are almost exactly what I'm doing. I'm rather loathe to include any dependencies, as I think you should be able to get it up and running out of the box (minus the having ruby installed requirement).

Both cover what I'd like to do, which is to allow one to specify a list of methods on a class that have 'pre' and 'post' condition execution code injected around them. So if you have 'move' code, it would check and execute any 'pre' move scripts, then execute the move code if the script was successful, and then check and execute the 'post' move scripts.

Scripts will have a language type. Currently only 3 possibilities (ruby, boolexp, and farts). Thus you can write your own scripts in ruby and they will be dynamically loaded and compiled once as needed (similar to how the commands are loaded).

Anyway I want to get it working right the first time.
No new estimate. :-P

Subject: Release 2.8.0 [priorities beginning to gel]
Author: Massaria
Posted: 02/20/2006 09:45AM

Tyche wrote:
> Both cover what I'd like to do, which is to allow one to specify a list of methods on a class that have 'pre' and 'post' condition execution code injected around them. So if you have 'move' code, it would check and execute any 'pre' move scripts, then execute the move code if the script was successful, and then check and execute the 'post' move scripts.

Super. Sounds real good.

> No new estimate. :-P
>

Oh well. Seems it's worth the wait :-)