Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Google, DotBot, Bing

Members: 0
Guests: 9
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » Elysium Custom Codebase
Forum Rules | Mark all | Recent Posts

Elysium Custom Codebase
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3, 4 next >>
Post is unread #41 Jun 28, 2009, 1:59 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

So I got ahold of FearItself@AvP and got an example and a bit of an explanation of how their Virtual IDs system works. So I'm going to attempt to summarize it. :)

So, instead of vnums they have Virtual IDs, a virtual ID normally looks like: chicago:eastside:32
That's in the zone : namespace : # format.
Zone is the area it's in.
Namespace is an optional, and arbitrary field.
And number is the Numerical ID of the room/object/mobile/script.

So, chicago:32 is the same as chicago:eastside:32. Because namespace is optional. Now, there are some rules to the system Fear wrote.
FearItself said:

The rule is:
zone tag must start with a letter, and can contain letters and numbers and it ends with a colon
after the colon may follow a namespace
a namespace must start with a letter, but can contain letters, numbers, and colons, but may not have a number following a colon.
a namespace ends with a colon
finally there is the number
So these are valid:
chicago:EastSide:North32ndAve:Floor1:5

In regular use we have things like
classes:core:0
classes:marine:sniper:3
our EQ is stored like that
meq2007:pred:weapons:56

(It was easier to quote this part then try and explain it myself and screw it up. :P)

If you specify just a colon and a number ( :5 for example ) in a script or in the OLC, it pulls directly from the area the script prototype is in, or the area whatever you're editing is from. So that if an area is renamed, it makes it easier if all calls to things in the area are just called as a colon and a number because they then don't need updated.

Now, let's say you have an area of 3200-3299. In Fear's ID's notation these would be converted to 32:0 to 32:99. But what if the area was 3200-3499. It would then become 32:0 to 32:299. The upper bound of one area would no longer affect the lower bound of another. So where before with vnums if you had 3200 to 3499, the next available vnum was 3500. With Fear's Virtual ID system you would still have access to 33:0 and up even if 32:## went up to like 599 or something.

His system also uses separate indices for Mobs, Objects, Rooms, and Scripts. So you can still have a Room 1, Mob 1, Object 1, and Script 1. His things also have a very unique file storage method which I thought was pretty cool too. Which is apparently how Circle handles it, but that Fear has since improved upon. Anyway, this is how he described it:
FearItself said:


world/mob/*.mob
world/obj/*.obj
world/zon/*.zon (the zone master config file and room resets)
world/wld/*.wld (rooms)
world/trg/*.trg

so zone fearitself is world/mob/fearitself.mob, world/obj/fearitself.obj
there is a world/zones.lst
which is a file that lists all the zones
zonetag(tab)descriptive zone name
this determines which zones' files are loaded
first the .zon file, then the various mob, obj, wld, trg files


So, I dunno about you guys, but I like the way this is all set up. And I'm going to pursue a system similar to this for Elysium. Because chicago:eastside:32 is a lot easier to understand then 46932 or something.
       
Post is unread #42 Jun 28, 2009, 7:42 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Honestly I'm not sure what's wrong with regular old vnums, but I can see an advantage to a system like this in that you'd not run into the duplicate vnum issues. Personally I think Name:# would be much easier to deal with instead of Name:namespace:namespace:namespace:# with however many namespaces it will allow.
       
Post is unread #43 Jun 28, 2009, 9:13 am
Go to the top of the page
Go to the bottom of the page

Tonitrus
Fledgling
GroupMembers
Posts47
JoinedJun 24, 2009

Nakedmud (which is pretty awesome, by the way) uses the following syntax

vnum@areaname

Or maybe it was

name@areaname

Probably both.

goto executioner@darkhaven

If you're going to have "areas", it makes for an easy syntax and looks less unwieldy than "chicago:eastside:32"
       
Post is unread #44 Jun 28, 2009, 10:22 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Good reply! We gave you stuff to read, eh? :)

Kayle said:

I worry that too much OO design, might make a steep learning curve for those that pick up Elysium for their MUDs.

I wouldn't be too concerned. There are still people starting up brand new LP MUDs, and there you not only have to warp your head to the idea of OO design, but you also have to work around the peculiarities of driver-imposed limits that we Diku people never worry about. In an LP, you have a limited number of execution ticks to process whatever you're processing, and then your thread is killed. If you can't finish the job in that limit, YOU have to figure out how to break your task up and schedule a call_out() to pick up where you left off. They also have to deal with recompiling lpc objects on the fly and how to go about updating all the things which inherit them.

In short, design it well and people will use it. Try to make it look (at a code level) like something else, and it'll just be another derivative that people hack a bit and then cry because snippet-foo won't compile cleanly.

Kayle said:

Quixadhal said:

If you make them the same, it's dirt simple to switch control from an AI script to a command interpreter. That lets people choose how they want to handle things at the game layer... if you want named NPC's to show up in the who list, done. If you want players to become NPC's when they log off... done.

Related to this... split the body structure away from the control structure. If you can just create a new body and swap pointers, things like polymorph/possession/reincarnation, all become simple.

The first part of this one, I understand and agree with almost completely. But the second part I'm not sure I'm wrapping my head around completely. Are you saying have a field on the class that points to whether the Mob control system is in control, or whether an external connection is in control? A little more detail into what you meant might help me understand.


Sure. Currently, the Diku model doesn't allow for swapping control around at will. You can, using things like "switch", take control of an NPC, but it doesn't disable their AI routines, it just passes what you type along to the command interpreter, but run with the NPC as "ch" instead of you. Likewise, there's no way to dynamically switch AI routines, or assign one to a player who has gone linkdead.

To take it another step further, the nanny() loop is a big state machine that does junk and flips around states on a descriptor. If you abstract that so every state if just a function call (rather than chunks of an ugly switch statement), you're one step away from a dispatch table. Now, instead of using switch() or if/then/else, instead just store a pointer to the correct interpreter function in the descriptor. If it's not NULL, call it and pass the command arguments in. Done.

Ok, let's move that down a notch. For a player, they'll have a descriptor pointer that points back up to their connection data. An NPC will typically have this be a NULL pointer, since they don't have connections unless they're being controlled (IE: possessed). If you place a command pointer in the player/npc strucutre, it would work just like what I described for the connection/nanny one. The player one would normally point to interpret(), although it might also point to editor(), or something else. The NPC one would normally point to whatever npc AI is normal for that kind of creature (warrior_ai(), orc_ai(), etc). If I charm an orc, you'd store away the old pointer and now it points to charmed_ai(), which may do nothing but try to break the charm every so often... but it would also be a hook for the "order" command to use.

Now, if the orc shaman charmed ME, *I* would be the one who gets their interpreter switched, so now instead of interpret(), all my input goes through charmed_ai(), until the charm wears off. Similarly, if I go linkdead, the game could switch me over to an AI routine that would try to do things to keep me alive until I can reconnect.

It may be that you need both fields... because if your character is AI controlled, you want it to do stuff every so often without you typing. But that's an implementation detail.

Quixadhal said:

Yes, but it gets that Beatles song stuck in my head... Elysium Fields, which makes me think of Strawberry Fields, and now (hopefully) you hear it too... Muahahahaha!

I'm gonna pretend I'm old enough to get your reference, and just smile and nod so you feel better. *smiles and nods*

Ok, you asked for it! LINK!

Kayle said:

My plan was to actually get the base into a connectable state with at least very basic rooms, objects, and mobs and then begin to think about either having something like AFKMud's areaconvert command, or just have a converter program available on the side. But, I'm not very good with the GUI side of C/C++ so I dunno how I'd work that one. :P

I'm also terrible at GUI's... but I wrote a mean C format converter to go from my old DikuMUD format to a text report, PNG map files, or a partial LPMUD conversion. I also wrote one in perl which is better designed, but doesn't work as well. *grin*

Kayle said:

Samson said:

* A command structure that's based on permissions. Your level should have nothing to do with this. Builders should get commands useful for building. PR/Enforcement people should get commands useful for that. Someone being level 108 should not mean they get to ban people and modify half the areas in the game, unless someone on the admin team specifically wants that.

Quixadhal said:

That's one I've been advocating for YEARS. I would probaby do this as a set of groups (using std::set perhaps). If your character/account has the "builder" flag, you get this group of commands... if you have the "admin" flag, you get these other commands... having one doesn't imply the other.. so an admin might be able to kick people or snoop them, but not use OLC.
You might even want to have a "player" group, so new characters could have a restricted set of commands... just keep the system flexible enough so every command requires one group, and every player can belong to more than one. A player with no groups at all might only be able to quit. :)

I'd been planning on doing just this. But I haven't decided on exact specifics for the release version of the base. for MW, There will be 65 levels total. 60 of which will be Player levels, but we have a sortof D&D 3rd Edition inspired Multiclassing thing going on that's a tad hard to sum up in a few words so we won't go into that. But 5 of them will be the Immortal levels. Each level will have several permissions settings in addition to the level. But you won't need the level in question to receive the permissions for that level. For instance, a very trusted 61 could be given level 64 admin perms or something. This might be wrong, I can't find my notes on these atm. :P

I think you missed our point on this one.

NO LEVELS!!!!!!

Players have levels, NPC's have levels, immortals don't have levels. Immortals have responsibilities, and the command structures *NEED* to be grouped logically, and given out according to those responsibilities. Using levels for this is absurd.

I mean, why should a level 103 immortal be able to do OLC but not be able to snoop/kick people, where a level 104 immortal can do both? Maybe you want immortals who can act as sherrifs and snoop/kick people or reimburse people, but don't EVER want them within 20 feet of the OLC commands. By the same token, you don't really want every single builder to have access to snoop, do you?

I know there's that whole "trust" system to dish out commands, but that's not really good either. You don't want to hand out single commands, you really want to grant people abilities which are grouped by function. If I want someone to have goto/trans, I really want them to have "travel powers". If I want them to have medit/oedit/etc, I really want them to have OLC.

Leave the levels alone... let a level 3 immortal fight a level 5 player and lose, there's no reason to link level with permissions. If some admin wants all his staff to have "finished" the game, that's his choice to not hand out permissions to people until they're max level. The code shouldn't influence that, IMHO.

Kayle said:

Sounds like a good idea, but how would one determine where the current would flow? that would kindof require coding in some sort of elevation determining stuff and what not wouldn't it?

The code I have had a "flow-to" direction... essentially, every few seconds anyone standing in the river would be forced out the exit that flow-to pointed towards.

Elevations would be cool, but also probably unused by 90% of people. *I* would use them to punish people by making a city on a hilltop really hard to attack, because snow + uphill == very slow movement. But I'm evil.
       
Post is unread #45 Jun 28, 2009, 10:36 am   Last edited Jun 28, 2009, 11:00 am by Quixadhal
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Hmmmm, with respect to the area:namespace:number idea... I like the idea, there's only three things I disagree with.

I don't like namespaces being optional. It's fine to have them be optional with respect to not needing one, but it sounds like "mirkwood:trail:32" and "mirkwood:woods:32" would both refer to the same location, and that would be unworkable with a large team of builders. If that's not the case, then remove one objection. :)

I don't really like the idea of still using ranges. If you have a unique naming scheme, why put ANY kind of bounds on the numbers, other than perhaps being non-negative? On something that was hacked into an existing Diku, it obviously has to fall back into a plain old vnum at some point... but in a custom codebase, there's no reason to no just use the ID directly.

std::map<std::string id, Elysium::room *room> Rooms;
ch->send("You stand in %s\r\n", Room["mirkwood:trail:32"]->Title.cstr());


That would be perfectly valid... no need to assign ranges or futz about with conversion.

Objection #3 is the CircleMUD style area files. I HATE looking at a directory and wondering what 201.wld is. Again though, there's no reason to equate numbers anywhere in the picture. The "mirkwood" area could be stored in "mirkwood.wld", "mirkwood.mob", etc.

I have no objection to splitting the sections out into seperate files... that's what I'm used to anyways (Diku used tinyworld.wld, .mob, .obj, .zon, and .shp I think).

EDIT: I should probably mention though, that the file format is largely unimportant if you're intending OLC to be the primary means of building or modifying things. My Diku pre-dates OLC, so I tend to "vi tinyworld.wld" and then reboot.
       
Post is unread #46 Jun 28, 2009, 12:10 pm   Last edited Jun 28, 2009, 12:12 pm by FearItself
Go to the top of the page
Go to the bottom of the page

FearItself
Fledgling
GroupMembers
Posts1
JoinedJun 28, 2009

Hello, decided to register to respond to this to clarify things.

Quixadhal said:


I don't like namespaces being optional. It's fine to have them be optional with respect to not needing one, but it sounds like "mirkwood:trail:32" and "mirkwood:woods:32" would both refer to the same location, and that would be unworkable with a large team of builders. If that's not the case, then remove one objection. :)


Kayle misunderstood this part. Namespaces are unique. The VirtualID is a 96 bit structure: 32 bit zonetag hash, 32 bit namespace hash, 32 bit ID #.

What I meant when I said "namespaces are optional" is that a namespace isn't required in a VID - i.e, "mirkwood:32" is a valid VID. The namespace hash is 0 in this case.

So "mirkwood:32", "mirkwood:trail:32", "mirkwood:woods:32", and "mirkwood:woods:cabin:32" are all unique locations. Likewise, there can be an object "mirkwood:32", a room "mirkwood:32", a mob "mirkwood:32" in my system.


I don't really like the idea of still using ranges. If you have a unique naming scheme, why put ANY kind of bounds on the numbers, other than perhaps being non-negative? On something that was hacked into an existing Diku, it obviously has to fall back into a plain old vnum at some point... but in a custom codebase, there's no reason to no just use the ID directly.


The only limit on the number component of a VirtualID is that it must be an unsigned 32 bit integer.

My codebase started as Circle (doesn't look much like it now, 12 years on) which used numbered zones, with a 16 bit VNum. A zone's number range was (zone*100)...(zone cap), so zone 15 would be 1500 to 1599 by default, and the upper limit could be increased. However, we ran out of world space, and things got unwieldly for organizing certain aspects (such as your bi-yearly Mission Equipment redesign which easily uses a few hundred vnums worth of space), so I stripped out VNums as they were.

There is a legacy system in place for converting VNums to VIDs. The VID parser code will detect if the VID string is a pure number, and if so it will send the number to the legacy lookup system. Older zones that were part of the VNum system register themselves as the 'zone' for a given classic VNum range. For example, zone 23 will register itself as 2300 to 2399 handler, these become 23:0 to 23:99; zone 150 (which had a top range of 18999, as it has 4000 rooms) registers itself as the handler for 15000-18999, and these become 150:0 to 150:3999.

In these cases, for example, the zone 23 (2300...2399 >> 23:0 ... 23:99), the zone 23 can also have 23:100, 23:5893, but these cannot be referenced as a VNum, only as a VID. This is not a problem for us as the legacy system is meant for existing references in scripts, player save files (this was a live conversion meant to be seamless without a pwipe), and because staff had memorized some of the old numbers and used them a lot.

Out script engine is also VID aware, and if it detects a VID on one side of a comparison equation, it will convert both to VID and compare from there (so scripts that still use VNums work fine without changes).


std::map<std::string id, Elysium::room *room> Rooms;
ch->send("You stand in %s\r\n", Room["mirkwood:trail:32"]->Title.cstr());


That would be perfectly valid... no need to assign ranges or futz about with conversion.


Performance, for one. When you get to 25,000 rooms, looking things up by name, even in an RB/tree, can get slow enough that anything that involves a lot of lookup in a large map gets slow. Additionally, inserts into a map are slow enough at large numbers, make it string comparison instead of number comparison and it will get really bad. For comparison, I ran performance tests years ago when it was still straight vnums. Rooms that load in order, vs inserted into a map, the map took about 100x longer to fill at 25,000 entries (tree rebalancing - every insert will cause a rebalance as it keeps weighting down one side of the tree. On a 1ghz server like we were on for years (which was more than enough for our general runtime) this was a 2 minute bootup/copyover with our world. 3 integers can sort much quicker than a string comparison.

My system uses custom container classes which use sorted vectors of pointers, and binary search. It uses dirty flagging, where an insert occurs at the end and flags the container as dirty (but if the insert at end is valid as far as a sort is concerned, it doesn't flag dirty), and will sort on demand or on lookup if the dirty flag is set.


Objection #3 is the CircleMUD style area files. I HATE looking at a directory and wondering what 201.wld is. Again though, there's no reason to equate numbers anywhere in the picture. The "mirkwood" area could be stored in "mirkwood.wld", "mirkwood.mob", etc.


That's how I do it now. Old numbered zones still exist as #.wld, but a zone can be renamed. This is, again, legacy support. They still maintain registration data for the legacy VNum->VID conversion.


EDIT: I should probably mention though, that the file format is largely unimportant if you're intending OLC to be the primary means of building or modifying things. My Diku pre-dates OLC, so I tend to "vi tinyworld.wld" and then reboot.


Even though we use OLC exclusively, I've written a custom hierarchical file format that is fully human readable, uses the actual enum names for flag bits/enums rather than arbitrary numbers. This allows me to delete/add/reorganize bit names and enum names in code. I also use a custom std::bitset-like class.

Regarding permission based for staff - I agree. We base staff commands off of a permission group set. A staff member (or even player) can have multiple permission groups, and a command can be part of multiple permission groups. We still have staff levels (101-105) because I personally like them for rank/seniority purposes - a 103 can't mess with a 104 - but that's pretty much all they exist for. We're set in our level range by design and aren't increasing it, and I have a personal affinity for it and haven't felt like implementing a separate system.

For nanny - no! no lookup tables! No enums! Use a state machine with actual state objects on a stack. This way each state can implement it's own input, enter, exit, pause, resume, and idle functionality, you can add custom states anywhere for whatever reason you need. States can be pushed onto the stack, swapped onto the stack (even by the current state), popped off the stack (again, even by current state), etc. As states are actual classes, they can even inherit behavior. I can go over this in more detail with you directly, Kayle, if you want, and show you how I handle it. Codebases should grow up and not need nannys :-)
       
Post is unread #47 Jun 28, 2009, 12:49 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

I find it VERY hard to believe that string hashing is still so horrible. I've written real-time code in perl, which is a string-based interpreted language using garbage collection, and it performed well enough to show cases where the database server needed to be optimized.

I guess it might depend on what std::map would use for underlying storage. A tree would be poor for strings that always start the same (unbalanced). A hash table might avoid it by using a clever hash algorithm. I'm not a C++ guy, but I assumed there would be some tunable parameters behind the STL containers.

Hmmm, I do like the idea of a stack, rather than just a pointer. That does give you the implicit ability to restore previous states, so when you exit an editor, that state just goes away. It also gives me an interesting idea. :)

I've always liked the idea of players always existing, but when their human controller goes away, they take on some default behavior which their human defined for them. In most cases, it's probably to go sit in their room in the inn and watch TV, sleep, sit around waiting for their human to return. However, it's also possible to have them try to explore, or try to harvest resources, or even go kill things. Of course, they won't be very good at it (compared to their human), and they may well die trying, but hey...

Anyways, if PC's and NPC's share the same class object, one could give NPC's the default state of their AI behaviour (even if that's being a stone statue), and override it when a player connects to them. On disconnect, that state pops off and they go back to what they were doing before.
       
Post is unread #48 Jun 28, 2009, 5:18 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

quixadhal said:

I guess it might depend on what std::map would use for underlying storage. A tree would be poor for strings that always start the same (unbalanced).

I believe that the default implementation on most STL distributions is a red-black tree, meaning that it takes care of balancing itself. Something that used unbalanced trees in general would not be a very good general-purpose data structure because it would be fairly dependent on things like the order in which things are inputted, the distribution of values, etc.
       
Post is unread #49 Jun 28, 2009, 8:22 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006


Tonitrus said:

Nakedmud (which is pretty awesome, by the way) uses the following syntax

vnum@areaname

Or maybe it was

name@areaname

Probably both.

goto executioner@darkhaven

If you're going to have "areas", it makes for an easy syntax and looks less unwieldy than "chicago:eastside:32"


Looked at NakedMUD, and I wasn't impressed. It's basically just a python implementation wrapped around SocketMUD, and that isn't anything I'm looking to do either. I'd prefer to use an easier to read language, like Lua.
       
Post is unread #50 Jun 28, 2009, 9:32 pm
Go to the top of the page
Go to the bottom of the page

Tonitrus
Fledgling
GroupMembers
Posts47
JoinedJun 24, 2009

Kayle said:

Looked at NakedMUD, and I wasn't impressed. It's basically just a python implementation wrapped around SocketMUD, and that isn't anything I'm looking to do either. I'd prefer to use an easier to read language, like Lua.

I agree, actually. The reason I don't use Nakedmud for anything is because of python. It's also really, really minimal.
(I've also pretty much settled on using Lua if I ever want a scripting language.)

However, the organization of the C-side of NakedMUD is a work of art :(
       
Post is unread #51 Jul 3, 2009, 10:01 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Well. Progress was made.

Connected to host malevolentwhispers.org
You said: Test
You said: Rofl.


Yes. That's the Elysium Engine running. ;) Granted. You can't see anyone else who happens to connect. Nor can you communicate. It merely takes whatever you enter, and spits it back at you. But hey, that's better than nothing.

Completed so far:
- Working Sockets implementation
- Telnet State handling, courtesy of Elanthis' wonderful Libtelnet library.
       
Post is unread #52 Jul 4, 2009, 7:04 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Hey, it's a start! :)

You're halfway up to where socketmud++ is at (more than half, since you have a working telnet state machine).
       
Post is unread #53 Jul 5, 2009, 1:32 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

I'm way past SocketMUD++. SocketMUD++ is just the Sockets and the main(). It doesn't have any of the extra stuff SocketMUD has. (Looking at it now.)
       
Post is unread #54 Jul 6, 2009, 12:26 am   Last edited Jul 6, 2009, 2:25 am by Kayle
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

So. Since there seems to be some sort of interest in how this is coming figured I might as well give a bit of an update of sorts. (God only knows why you people are interested in what my lame ass is doing but.. Eh..)

So, Thanks to FearItself I've got a modified version of std::string now that is case insensitive. So, there's another step in what I think is a forward direction. I've begun working on getting DNS lookups into their own threads using pthread. Once that's done, well, I dunno what the hell I'm going to do. But I've got an impressive list of things to keep me busy.

ToDo (In no particular order)
SHA-256 Encryption Support
dlsym support
MySQL Interface
Command Parser/Interpreter
Embed Lua
Shared String library (Maybe? DavidHaley's looks like a winner, but I've heard std::string is now a shared string deal of sorts?)
Line Editor or some kind of in game text editor for notes, building, etc
Data Structures for Characters, Items, Rooms, etc. PLus I need to build some kind of inheritance model...
Permissions based command structure
Some kind of Building/OLC system
Some form of AI for mobs.
Figure out some sane way of handling file I/O

Less close to the top of the list are:
Combat System
Magic/Skills system
Races system
Classes system
System for levels/leveling.


       
Post is unread #55 Jul 6, 2009, 12:57 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

People are interested in what your "lame ass" is doing because there's been plenty of talk over the years about starting a new scratch codebase for public consumption but never any activity actually taking place on it. Other than a couple of noted exceptions anyway.

For std::string, I doubt the native library implements any kind of shared system as we know it for Smaug. David's library was meant as a solution to that but since nobody has ever really done anything with Smaug or a scratch base that also wants c++ shared strings, it didn't really see much use. So his (or a system like it) is necessary to avoid the needless duplications of strings in memory.
       
Post is unread #56 Jul 6, 2009, 2:24 am   Last edited Jul 6, 2009, 2:25 am by Kayle
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Heh. So people are interested in what I'm doing because I'm bored and wanted to learn things? ... K. Saying it like that really does make me sound like a lame ass.

Well, I'll pester David about his shared string stuff next time I see him then. Also, I might look into implementing MSP since I have a telnet state machine and it oughta be real easy to implement. :P But I'm wondering what all clients support it.

Also, considering xterm 256 colors, but I'm not sure what clients support it. MUSHClient supposedly does, as does cMUD, but I don't know that zMUD does. So, it's going to require some testing to tell. Huh. I don't have ANSI Color support listed on my To Do list.. I'll have to rewrite my To Do list.

To Do (In no particular order)
SHA-256 Encryption Support
dlsym support
MySQL Interface
Command Parser/Interpreter
Embed Lua
Shared String library (DavidHaley's looks like a winner)
Line Editor or some kind of in game text editor for notes, building, etc
Data Structures for Characters, Items, Rooms, etc. Plus I need to build some kind of inheritance model...
Permissions based command structure
Some kind of Building/OLC system
Some form of AI for mobs.
Figure out some sane way of handling file I/O
ANSI Color support
Possibly xterm 256 color support. (This was actually requested by an immortal on my staff currently, surprised the hell out of me when he asked too...)

Possible Protocols:
ZMP - I'm interested in this. Need to do some more reading up on it before a decision about it is made.
MSP - This one should just be fun. Assuming there's no existing telnet state for 90 like Zugg set it up for.
MIP - Dunno. Seems kinda iffy, and I don't know that enough people use portal to justify implementing it.

Less close to the top of the list are:
Combat System
Magic/Skills system
Races system
Classes system
System for levels/leveling.
       
Post is unread #57 Jul 6, 2009, 2:58 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Kayle said:

Also, considering xterm 256 colors, but I'm not sure what clients support it. MUSHClient supposedly does, as does cMUD, but I don't know that zMUD does. So, it's going to require some testing to tell. Huh. I don't have ANSI Color support listed on my To Do list.. I'll have to rewrite my To Do list.


"Support" is mostly just emitting the right escape sequences. The trickier part is to come up with something on the server-side to do the translation.

Since I've already been through this debate and several arguments, I'll start out by asking if you're going to use the Smaug-standard colour codes? If so, you need a way to extend them to support 256 colour mode.

Not that I think my implementation is the best out there (I'm sure it's not), you might want to take a peek at what I did in LPC. In this case, I used Pinkfish-style codes, but you can easily make up some new extension of the Smaug codes.

Main points are... decision of translation target should be for each client (each player), and symbolic names make life easier for builders. I think I had something like "&[foo]", which could be extended to &[xterm:XX] easily.

Hmmmmm, where did I put those links..... oh well....

Here are a few images:



If anyone cares, I'll dig up the code and post a link to it somwhere. :)

Kayle said:


To Do (In no particular order)
SHA-256 Encryption Support
dlsym support
MySQL Interface

Any chance of making it ODBC? If not, at least try to isolate the SQL code well enough so porting to some other database isn't a nightmare. I'd probably suggest something like having methods in your objects like save() which would call save_mysql() or save_flatfile() or save_oracle(), depending on what you had set in configuration files.

While on that topic, will SQL be optional or mandatory? If mandatory, your config file only needs to tell you how to get to the database. If optional, you might want to use a standard config-file format since there's probably several nice libraries that will automate reading and writing it.

Kayle said:


Command Parser/Interpreter
Embed Lua
Shared String library (DavidHaley's looks like a winner)
Line Editor or some kind of in game text editor for notes, building, etc

If you allow character-mode telnet and provide a visual editor, you'd instantly gain a following, as that's something people have wanted for over a decade.

Kayle said:

Data Structures for Characters, Items, Rooms, etc. Plus I need to build some kind of inheritance model...
Permissions based command structure
Some kind of Building/OLC system
Some form of AI for mobs.
Figure out some sane way of handling file I/O
ANSI Color support
Possibly xterm 256 color support. (This was actually requested by an immortal on my staff currently, surprised the hell out of me when he asked too...)

Possible Protocols:
ZMP - I'm interested in this. Need to do some more reading up on it before a decision about it is made.
MSP - This one should just be fun. Assuming there's no existing telnet state for 90 like Zugg set it up for.
MIP - Dunno. Seems kinda iffy, and I don't know that enough people use portal to justify implementing it.

Less close to the top of the list are:
Combat System
Magic/Skills system
Races system
Classes system
System for levels/leveling.

       
Post is unread #58 Jul 6, 2009, 3:08 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

quixadhal said:

Main points are... decision of translation target should be for each client (each player), and symbolic names make life easier for builders. I think I had something like "&[foo]", which could be extended to &[xterm:XX] easily.

Personally I would very, very strongly avoid tying the color codes to any particular terminal's color codes. It would be much better to use something like HTML colors (8 bits for each RGB channel) and translate to the terminal's closest color at the very last minute. This means that if somebody has a 16-color client, you can downgrade colors appropriately, but if somebody has a 256 or higher color terminal, you can get much richer colors.
       
Post is unread #59 Jul 6, 2009, 3:43 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

David Haley said:

quixadhal said:

Main points are... decision of translation target should be for each client (each player), and symbolic names make life easier for builders. I think I had something like "&[foo]", which could be extended to &[xterm:XX] easily.

Personally I would very, very strongly avoid tying the color codes to any particular terminal's color codes. It would be much better to use something like HTML colors (8 bits for each RGB channel) and translate to the terminal's closest color at the very last minute. This means that if somebody has a 16-color client, you can downgrade colors appropriately, but if somebody has a 256 or higher color terminal, you can get much richer colors.


Yes, my system does allow for that, but it takes some CPU horsepower. The advantage of xterm-256 is that you can cache all the translations, so a few seconds of setup time means xterm:40 is a single lookup to get the ANSI version (which is non-bold green), the greyscale version, or the plain-text version. You can't cache the rgb:RRGGBB values (unless you have a LOT of RAM?).

I wrote this for a LP MUD, specifically Gurba-lib under DGD, and it had to run in a restricted environment where you only get so many CPU ticks before your process is stopped.

I think I mentioned the idea of symoblic names up above? In the system I have, the symbolic name "FOO" maps to "xterm:8F", which in xterm256 mode becomes the escape sequence for colour entry 143. If you're in greyscale mode it might map to the sequence for xterm256 entry 247. If you're in ANSI, it becomes the non-bold yellow sequence, and in "off" mode it just gets stripped away.

The builder would use "FOO". You could redefine it to be "rgb:928D00", but then you can't do a simple lookup, you have to do the computation to map it down below 24-bit colour. Individually cheap, but it adds up over millions of strings.
       
Post is unread #60 Jul 6, 2009, 3:55 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Well, you can probably map whole ranges into the xterm256 color cube at once, so it would only require a small sequence of if statements to figure out which color was appropriate for a given HTML color.

You could also build the cache on request (i.e. memoization). This way, you cache the things you actually use; there's no need to cache everything.
       
Pages:<< prev 1, 2, 3, 4 next >>