Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - FallenTree

Pages: 1 ... 31 32 [33]
Drivers / Re: FluffOS-2.16
« on: June 16, 2009, 03:06:01 AM »
If you see an mudlib is an "designed" world for people to have fun in it. It's really the designer's right to decide whether to show or not-show the source code for the players.

Some game will not be that interesting if you can see the code directly in it. isn't it?

Having an ability not only for mudlib designer to quickly and easily share their product, but also give an chance for people purely playing the mudlib an easier way to install and have fun.

Scene 1: Say an player wants to play an mudlib "abc", so he downloads an abc.dat, loads with the driver he downloads previously, and suddenly, it all works. an new world to explore! and you can even host them on the LAN or WAN for friends, would it be cool?

Scene 2: Say an designer want to show-off an newly designed world, which the descriptions and content may be copyrighted. By distributing an signed/encrypted dat file, he remains the rights to display an usage warning, which may encourage more people to distribute their work this way.

It's just like concept of sharing SWF / FLV and PSD / PNG.

There's an few game engine I know accept for an "dat" file, and people have fun in the game itself rather than modding it, and there's is tools for them to customize too. Why can't mud become one of them too?

Drivers / Re: FluffOS-2.16
« on: June 16, 2009, 02:03:20 AM »
I would rather say this is an speed gain than an deployment gain.

If we want people to distribute their mudlib.

An signed dat file (all binaries) will be the best.

The problem here is we currently have compile time options, which certainly doesn't fit in the nowadays world.

I would say I am willing to add the binary support again.

After I've been able to port my chinese mudlib on to fluffOS

Drivers / Re: Sub-second timers
« on: June 12, 2009, 01:48:46 PM »
In terms of an round-based game.

Mudos is trying to be an fake-realtime game.

I think one thing we've been misunderstanding is that in mudos, there's no "guaranteed time". But there will be guaranteed heartbeat.

So you are saying "an cast needs 3 seconds, it's wrong, it should needs 3 heartbeats" while an heartbeat should be guaranteed to happen during an time frame.

So there's been 2 problems regarding the current driver.

1. It tries to catch-up with the real world by speeding heartbeat if you lost some time in loading object etc. so you will see "whack...whack......(whole server lag)...whackwhackwhack"

I don't think this behavior is correct.

2. There's no way to sort the execution order in an heartbeat time.

An workaround maybe set the heartbeat to 1/10s and you will be able to further adjust real attack.
well, the smaller the heartbeat you get, you also get an problem with doing that heartbeat to all the objects. it's simply not possible and it will lag at hell.

So an workaround maybe to start an separate heartbeat for objects that in combat. with an much shorter time period, well.. it needs another thread, and locking mechanism, synchronize stuff, which really just doesn't happen yet.

Drivers / Differennces Between Mudos V22.b14 and FluffOS
« on: June 12, 2009, 12:11:09 AM »
Hi, guys

It's very nice to see LPMUD is still so alive.

I am from china, where there's an small group of people like me working on LPMUD, but it's getting smaller and smaller. We've been focus on MudOS for an long time, but all the work is being lost during the time.

I start my plan recently to gathering the gold pieces lost in the chinese mud forum, patches to MudOS.

And it's good to know that FluffOS is doing very well. My question is , how much difference is there between FluffOS and MudOS.

Is there a lot of LPC semantic/behavior differences, will it be hard to port the lib from mudos to fluffOS? Is there an way to clearly see the changes being done?

Thanks again for the beautiful work!

Pages: 1 ... 31 32 [33]