05 Jan, 2009, quixadhal wrote in the 1st comment:
Votes: 0
Ye Olde first meeting of the new year should be tonight, around 9pm EST. BYOB. :)

I've checked in the OLC code for both Ice and Fire branches, and I encourage people to find things broken so they can get fixed! There are still UI changes I want to do, but I figured I'd rather get it out the door to everyone than sit on it any longer.

I have NOT checked in the modified area files, since I'm not 100% confident the conversion went correctly yet. The next checkin should do that, but this way you can all try it yourselves and see if it looks right.

I also grabbed the OSX patch, and would ask our resident OSX expert to run this nifty command on his system for me!

gcc -dM -E - < /dev/null

That there will show you all the pre-defined symbols your particular version of gcc has, and if you wade through it, you'll probably find something you can use instead of having to add -DMACOSX by hand. :)

For example, on my system I have both "linux" and "__linux__". I suspect you'll have both a FreeBSD symbol, and an OSX symbol, and maybe even a DARWIN symbol.

See ya'll later!

Oh yeah, I will toss the beastie up on shadowlord.org 2000 again, so people can poke at stuff while I'm idle and try to break things. :)
05 Jan, 2009, ghasatta wrote in the 2nd comment:
Votes: 0
Re: Mac OS X symbol. That's a neat trick. However, I don't really see anything suitable except perhaps '__APPLE__'.

I put the full output here in case it is of interest to anyone.

So does that mean all your changes are now in the repos? If so I am going to start destroying refactoring structures so that they use std::string instead of c-style strings.
05 Jan, 2009, quixadhal wrote in the 3rd comment:
Votes: 0
Hmmm, maybe __APPLE__ and __MACH__ together might be enough? I'm kindof surprised.

For me, I get:
Quote
#define __linux 1
#define __unix 1
#define __linux__ 1
#define __unix__ 1
#define __gnu_linux__ 1
#define unix 1
#define linux 1


and

Quote
#define __unix__ 1
#define __OpenBSD__ 1


We'll see how apple + mach works, I think that should be safe. apple should only be defined for apple machines (maybe including old macintosh), and mach should only be defined for microkernel-based architectures (NEXT, OSX, etc), so the combination might be valid. :)

Yep, I just need to merge in Tricky's fix, your OSX fix, and ummmm… maybe something else I'm forgetting.
05 Jan, 2009, quixadhal wrote in the 4th comment:
Votes: 0
Patching in the OSX fix, I decided to just use __APPLE__ and see if that works. If it breaks for someone running Yellowdog linux or something, we'll work around it then. :)

In sha256.h, I changed it so that it uses "<sys/endian.h>" for FreeBSD or APPLE. If that fails, let me know where OS X hides your endian.h file. NOT including it might do bad things, as the sha256 function does magic that relies on knowing the byte order of blocks of memory.

One issue with your patch though. You need to find out where, exactly, you need to include "<time.h>", because I won't sanction putting an include inside another header file. Bad mojo in C!

Otherwise, should be good to go I think!
05 Jan, 2009, Tricky wrote in the 5th comment:
Votes: 0
FluffOS/MudOS just uses APPLE and GNUC to identify it as Mac OS X.

Tricky
05 Jan, 2009, ghasatta wrote in the 6th comment:
Votes: 0
Quote
I changed it so that it uses "<sys/endian.h>" for FreeBSD or APPLE.
It should be <machine/endian.h>.

Quote
because I won't sanction putting an include inside another header file.
:surprised: I've never heard anything like this before. What's the rationale for this?

I use this frequently – if my header file has a class that has some other class member variables (let's say an STL vector) I consider it SOP to include the <vector> header in myclass.h. The alternative, having to include <vector> in each source file where I include myclass.h seems extremely unwieldy. What if you switch from vector to list? You would then have to update each implementation file individually.

Regardless, I commented out the time.h include in merc.h and it seems to compile fine, so I guess you can just take that one out.

I plan on submitting a patch soon that adds a bunch of string utility functions for std::string to the olc files as a precursor to making a bunch of std::string changes, fyi.
05 Jan, 2009, quixadhal wrote in the 7th comment:
Votes: 0
Ok, I'll go ahead and change that in the next update. :)

My rationale against nested includes is readability of the code. C++ and C are two somewhat different beasties, and it's unfortunate (IMO) that they C++ designers decided to stick with the old C division of source and header files. They really don't apply the same way.

In C, you never put any code in a header file. Everything there is data type definitions, macros, and prototypes. Likewise, you *should* never put those things in the C source files unless you're really sure nobody will EVER want to use them outside of said source file.

By the same token, listing your include files in the source file which uses them allows the future debugger/developer to glance at the top of the file and quickly see what's going on. If you bury includes inside of includes, you have to waste a lot of time following the chain of files to figure out what all it uses.

Unfortunately, C++ tries to cram the square peg into the round hole by having us define the class in a header file, but push all the methods off into a seperate source file. That makes it difficult to maintain the black-box nature of an object hierarchy, since if you use myclass, you have to include <myclass>, which then itself has to include <vector> because you can't know that's what IT uses unless you go pry it open.

The reason I'm picky about that is that I hate polluting the namespace and thwarting the dependancy tree. If a given file needs time.h, it includes it because it uses something from it. If you put time.h inside merc.h, now EVERY file depends on time.h, even though half of them shouldn't need to care.
05 Jan, 2009, kaervos wrote in the 8th comment:
Votes: 0
Hoping to get some feedback on this, so please make comments.

Alright, I'm working on creating an intermediary channel(…) function that all mud communications are channeled through. Every channel function (do_gossip, do_auction, etc) will maintain it's functionality when called without arguments (for enabling/disabling), checks against specific flags / factors (like not being in a clan for clantalk, god-imposed COMM_NOSHOUT flag for yell, etc), and special handlers like for mob prog triggers in do_say, but after that, this new function will take the character, the arguments, and the channel type to perform the rest of the communication.

I was strongly considering creating a channel table that would be filled with an array of channel_type structures. These structures would contain the to/from text ("gossip"/"gossips", "tell your group"/"tells the group", etc), the channel type, the minimum position, and the specific blocking flag a victim may set to reject receipt of the communication (Eg: COMM_NOGOSSIP for CHAN_GOSSIP). I'm coming to question if this table is a good idea or not. See below.

This function would then have to switch on the channel type, as each channel has specific requirements for descriptors that are candidates for receipt of the communication, and various other handlers specific to the channel (Eg: AFK stuff for tells) . At this point, the channel table becomes ancillary, because I'm going to have to iterate through the descriptors inside the case statement anyway, so I might as well have the to/from text and other blocking flag logic done right there.

When a descriptor is found that will receive the communication, we need to perform language translation prior to calling act_new(…). Color code translation needs to be done deeper, inside act_new(…) just before the call to write_to_buffer(…), because color codes can appear all over the mud, not just in speech. I can't see any good way to reconcile this difference to get the ANSI color and language translation all in the same spot.

I have a good plan for language translation. Prior to writing the speech to act_new(…) for the victim, the text will be translated into the speaker's native tongue either in full (if the victim has no proficiency in the language) or partially, based on the victim's proficiency level. The language translation will work as so:

-Ignore color codes, so they will be left in place.

-For each word in the text, perform a proficiency check against the victim's skill in the language. If the proficiency check passes, leave the word as is. If the proficiency check fails, translate the word into speaker's tongue.

-Translation routine will operate using two translation tables, one word-based and one letter-based. First check word-based translation table for replacement. If found, substitute the translated word, maintaining capitalization. If the word translation table does not contain a match, perform letter-based translation of the word.

- After entire speech has been run through language translation, check the drunkeness of the speaker, and slur the words if appropriate. This allows other languages to be slurred from their natural form using the same slurring scheme.

Note that this requires the victim's unique (perhaps partially) translated text to be slurred. This overall routine seems a great implementation aside from the heavy processing required every time someone hears someone speak. The speech will have to be language processed, drunken processed, and eventually color-code processed. Is this going to make an impact on performance? I have a large array of dwarven and elven word translations, so we are talking about for comparing each spoken word (for each recipient) against a table of 200 words.

The word and letter based language translation is a great idea (IMHO), as it alllows certain words in the language to be universally recognized. For example, adding "mithril", "mithril" to the elven word translation table will make an elven speaker say "mithril" the same way, so even someone that doesn't understand elven will recognize the word. The same can be done for town / deity names, and anything else that would shine through regardless of language.

Just thought I would get my ideas and worries about the implementation out there, and see what everyone thinks. Let me know.
06 Jan, 2009, quixadhal wrote in the 9th comment:
Votes: 0
One thing I did with Smaug's color processing (which I'll probably borrow for this project too) was to create the color filters so that you can get output as either embedded ANSI sequences or stripped to just plain text (the default for mobs, and players with ANSI disabled).

What you could do when translating is break the string on whitespace, pass each "word" into the colorize function, set to remove color codes, and then do your translation on the resulting "clean" word. All you need is a way to then add the color codes to the newly translated word.

I was going to just suggest that we not allow color codes in chat channels, at all…. since I know a lot of people (myself included) get annoyed by people typing 'I will OMGWTFBBQ you!', and spamming all the channels with it. However, you'd still need to solve the above problem for object descriptions, room descriptions ,and NPC dialog with specific language text in it.

My 2 cents, is that at the level of the channel interface itself, you shouldn't be checking for what language the text is in. It should already be tagged as being a particular language when passed to the channel for distribution. The channel routines will then have to check to see if the recipient knows the language in question, and filter it if they don't.

It should also be said, that there must be a default "common" language, but I highly suggest not allowing the players or any NPC to ever speak it. That is to say, all room descriptions and basic text that's describing what's going on will normally be unscrambled to everyone. However, if you let people speak in common, that's all anyone will ever use unless there's a specific reason not to.
06 Jan, 2009, BleaS wrote in the 10th comment:
Votes: 0
Options are always a good thing. Something that you wouldn't think is important might be important to another person, just a thought. Is there one place here that is indexing everything going into RaM? It would make sense for me to go through that before offering suggestions.
07 Jan, 2009, quixadhal wrote in the 11th comment:
Votes: 0
Heh, well, options are always a good thing if you're NOT the programmer who has to write extra code to allow and support them. :)

Put another way, I've played both World of Warcraft and EVE-Online. WoW supports UI extensions that can be written in Lua, as well as full texturing via XML config files. You can literally change almost every aspect of how the game looks and plays. EVE, does not support any modifications at all, not even repositioning the windows.

I've spent FAR more time having to update, fiddle with, adjust, and fix my UI in WoW – even being told that I can't join such-and-such a raid unless I install this mod and that mod. With EVE, I just log in and play. I know how it works, and I know nobody else has an unfair advantage because of some uber-mod/macro setup that I don't have.

I know that has almost nothing to do with this discussion – but I'm just pointing out that options aren't ALWAYS a good thing. :)
07 Jan, 2009, BleaS wrote in the 12th comment:
Votes: 0
That's certainly true enough, I suppose I was pointing more at situations where you are spending more effort to code something out. If you're going to code it out, there's always the consideration of doing that, but still leaving an option to have it, which tends to be far better than simply coding in a 1000 options. I'm quite a newbie programmer, so I know I wont stand much in an argument about code, but it's not like it is some mystical spell to me ;)
07 Jan, 2009, kaervos wrote in the 13th comment:
Votes: 0
I agree about the use of color in channels now, but a decade ago when I was first mudding, being able to use color codes in channels and your title was bloody AWESOME! As such, I wasn't planning on modifying Lope's general color code usage. I think if players could use color codes in their prompt, but not in channels, they would be a bit miffed. I feel that Lope's color code is a bit excessive, and breaks things the admins may want to do like turning %h in the prompt yellow and then red as a character nears death. Maybe we should talk more about specifically what level of color support we want. Stripping color codes out of room and object descriptions doesn't worry me much, as Lope's color code does this when the player's color option is disabled. Same for stripping color codes from the spoken text, as I can use basically the same routine.

On a different note, while looking through the channel functions in act_comm.c, I've noticed the use of this while looping through descriptors:

victim = d->original ? d->original : d->character;


Where 'd' is the current DESCRIPTOR_DATA pointer in the descriptor_list.

Strangely, although most channel functions do this, others just opt to use 'd->character'. Even more strangely, functions that DO use this will continue to use 'd->character' as well as 'victim'.

What is 'd->original', and if it isn't null should we always be using this instead of 'd->character'?

Otherwise things are coming along fine. This is what the channel table looks like:

const struct channel_type channel_table[] = {
/* channel, outgoing, incoming, min position, blocking flag */
{CHAN_GOSSIP, "gossip", "gossips", POS_SLEEPING, COMM_NOGOSSIP},
{CHAN_AUCTION, "auction", "auctions", POS_DEAD, COMM_NOAUCTION},
{CHAN_QUESTION, "question", "questions", POS_SLEEPING, COMM_NOQUESTION},
{CHAN_ANSWER, "answer", "answers", POS_SLEEPING, COMM_NOQUESTION},
{CHAN_QUOTE, "quote", "quotes", POS_SLEEPING, COMM_NOQUOTE},
{CHAN_GRATS, "grats", "grats", POS_SLEEPING, COMM_NOGRATS},
{CHAN_WIZ, "godspeak", "godspeaks", POS_DEAD, COMM_NOWIZ},
{CHAN_SHOUT, "shout", "shouts", POS_RESTING, COMM_SHOUTSOFF},
{CHAN_TELL, "tell", "tells you", POS_DEAD, COMM_DEAF},
{CHAN_SAY, "say", "says", POS_RESTING, -1},
{CHAN_GROUP, "tell your group", "tells the group", POS_SLEEPING, -1},
{CHAN_CLAN, "clan", "clans", POS_DEAD, COMM_NOCLAN},
{CHAN_YELL, "yell", "yells", POS_RESTING, -1}
};


I was wondering if you all think it is fine to order the table elements according to the values defined to CHAN_*, and then index into the table using the CHAN_* defines. Otherwise I could make a channel_lookup function that takes one of the CHAN_* defines as an argument and returns the appropriate index into the table. That way the table elements could be out of order, and it wouldn't matter.

Let me know your thoughts.
07 Jan, 2009, BleaS wrote in the 14th comment:
Votes: 0
kaervos said:
I agree about the use of color in channels now, but a decade ago when I was first mudding, being able to use color codes in channels and your title was bloody AWESOME! As such, I wasn't planning on modifying Lope's general color code usage. I think if players could use color codes in their prompt, but not in channels, they would be a bit miffed. I feel that Lope's color code is a bit excessive, and breaks things the admins may want to do like turning %h in the prompt yellow and then red as a character nears death. Maybe we should talk more about specifically what level of color support we want. Stripping color codes out of room and object descriptions doesn't worry me much, as Lope's color code does this when the player's color option is disabled. Same for stripping color codes from the spoken text, as I can use basically the same routine.


Using color in prompts is pretty awesome, in channels is a bit odd but some people do use it which is why having it as an option is a nice route, leave it to the administrator! This is also why I would like to know what will be in RaM so I can make suggestions. I love how the MUD I use does prompts, but all of the codebases I've seen so far havent really come that close except SMAUG and I'm not sure how close SMAUG came since now I have issues running it. As I said, obviously the MUD I'm playing has been highly customized as it's been around for 11 years, but having something like what the MUD I play has for a prompt as stock in codebase would certainly be neat.
07 Jan, 2009, quixadhal wrote in the 15th comment:
Votes: 0
The d->original check is to handle immortals who have switched into a mob, and perhaps also players who have polymorphed?

One thing to keep in mind with creating tables… at some point in the future, I'd like ALL of those things to be loaded at runtime from configuration files. There's no reason channels have to be static in nature, although there are some that should probably be auto-created if they aren't present (like say, room_description, battle, etc…). As such, I tend to lean towards using the channel names to reference the channels, just because it's easier to map.

Once we're using C++ features, they can be kept in a std::map for fast lookups, but for now a lookup function would work fine. If you want, look at the skill lookup code, as I switched that to sort and use a binary search. As long as the channel list is re-sorted whenever a channel is added (or renamed), that would probably work fine.

BleaS, RaM is pretty much a slow-growth organic project, so I can't directly say what's going to be in it. A few of the other threads do talk about what KINDS of things we're trying to accomplish though. The main idea is to add features that enhance the admin/builder experience so they can spend more time writing their game, rather than cobbling together infrastructure.

On the short list so far:

OLC (done, needs testing and enhancement)
color parser
channels
runtime configuration of class/race/terrain/item-types/etc…
an account system (disabled by default?)

and of course, conversion of all strings to C++ std::string, and many arrays/lists/etc to STL containers.
07 Jan, 2009, BleaS wrote in the 16th comment:
Votes: 0
What kind of content is covered by OLC? Anything that can be added without code like areas, items, mobs, restrings, etc?

Anyways, I'd love to help in any way I can and it's not likely going to be code. I guess I'll just wait for next release and work from there. :P
07 Jan, 2009, quixadhal wrote in the 17th comment:
Votes: 0
Once we've done the C++ conversion, I'd like to take almost ALL of the hard-coded things in tables.c (for example) and load that data from a set of files. Anything done that way should be managed by OLC in some form.

The only caveat is that a certain amount of care will have to be done when removing elements from those lists. For example, if you choose to remove the warrior class from the class table, you have to check to ensure that either no NPC's or players are warriors and forbid the deletion, or ensure that there's a fallback class which all former players/NPC's will become.

That kind of thing is easier to manage in C++, because you aren't as likely to be using array indexes directly. It might even be the case that you don't actually delete the elements immediately, but flag them for deletion on the next startup.

We'll certainly appreciate the help! Right now, we're still at a point where things are in flux quite a bit, but eventually we'll need people to help with lots of the non-code aspects of the driver. In particular, I'm hoping to eventually retire all the "stock" ROM areas and create new ones that do a better job of teaching both players and builders how things work, and also make it clear that this isn't a "download and play" game system, but one where you can and should build your own world.

There's been talk of a ROM area respository, and ideally I'd like to make it easy to import areas if you really do just want to cherry-pick pieces, but that's a ways down the road I think.
07 Jan, 2009, kaervos wrote in the 18th comment:
Votes: 0
Quix, funny because after I posted that I did move the channel table to just use the channel name instead of the defines. It makes the table order not important, and aligns better with the other lookup functions (which always take a name as an argument).

You have me confused though… when I say channel, I mean… commands a player can use to speak with (sans emotes). Room_description and battle don't fit into the work I'm doing at all. What are you thinking of when you think of a channel?
07 Jan, 2009, quixadhal wrote in the 19th comment:
Votes: 0
They do, but that's phase 2. *grin*

In an ideal world, ALL generated output should eventually be funneled through a single place. Currently, the closest thing to this is send_to_buffer() (or send_to_queue… I forget what it's called here). That is, all the various act/ch_printf/wiznet functions dump into it.

Right now, each of these functions does its own processing on the data, and the output routines just collect it and ship it out the sockets. What I'd eventually like to see happen is to have the colour/MXP/language-cipher processing happen in that backend, as it's being sent to the player's socket. That way, it's all in one place and works consistently.

How that ties into channels is that each channel would tag the output with the channel name (id, whatever), and then that backend filtering can decide (based on the user's settings) what colors to use, what translations need to be done, etc. When the driver sends a room description, it will work 100% the same way, except it will get a "room description" tag.

Again, the big win here would be for smart clients, as we could ship MXP support that allows them to break things up as they want… more importantly, people writing new code don't have to remember how to tag it. they just know what channel to use.

But like I said, that's phase 2. Having proper chat channels, is a first step that can be done without any of that infrastructure.
07 Jan, 2009, kaervos wrote in the 20th comment:
Votes: 0
Alright, I like where you are headed with this. For the sake of immediate progress, I'm going to ignore what may come down the road and focus on chat channels, as I have been. Do you have a problem with the following:

in merc.h
/*
* Channel types.
*/
#define CHAN_GOSSIP "gossip"
#define CHAN_AUCTION "auction"
#define CHAN_QUESTION "question"
#define CHAN_ANSWER "answer"
#define CHAN_QUOTE "quote"
#define CHAN_GRATS "grats"
#define CHAN_WIZ "immtalk"
#define CHAN_SHOUT "shout"
#define CHAN_TELL "tell"
#define CHAN_REPLY "reply"
#define CHAN_SAY "say"
#define CHAN_GROUP "gtell"
#define CHAN_CLAN "clan"
#define CHAN_YELL "yell"


in tables.c:
const struct channel_type channel_table[] = {
/* channel, outgoing, incoming, min position, blocking flag */
{"gossip", "gossip", "gossips", POS_SLEEPING, COMM_NOGOSSIP},
{"auction", "auction", "auctions", POS_DEAD, COMM_NOAUCTION},
{"question", "question", "questions", POS_SLEEPING, COMM_NOQUESTION},
{"answer", "answer", "answers", POS_SLEEPING, COMM_NOQUESTION},
{"quote", "quote", "quotes", POS_SLEEPING, COMM_NOQUOTE},
{"grats", "grats", "grats", POS_SLEEPING, COMM_NOGRATS},
{"immtalk", "godspeak", "godspeaks", POS_DEAD, COMM_NOWIZ},
{"shout", "shout", "shouts", POS_RESTING, COMM_SHOUTSOFF},
{"tell", "tell", "tells you", POS_DEAD, COMM_DEAF},
{"reply", "tell", "tells you", POS_DEAD, COMM_DEAF},
{"say", "say", "says", POS_RESTING, -1},
{"gtell", "tell your group", "tells the group", POS_SLEEPING, -1},
{"clan", "clan", "clans", POS_DEAD, COMM_NOCLAN},
{"yell", "yell", "yells", POS_RESTING, -1}
};


Defining the channel types as strings allows using the CHAN_ defines to be used to in the channel_lookup function.

Interesting actually because with like room_description, COMM_BRIEF would be the blocking flag for that "channel".

I'll try to finish this up and get a patch out.
0.0/47