Lima Coder LFW

[Holyavenger]

Looking for work

Admined a Lima mudlib w/Loriel. Moderate skill

[zyl]

I've sent you a message here on the forums about a project of mine.

[Holyavenger]

If I had my way, I would alter lima in the following ways

1) Make some sort of leveling daemon that handles the classic 2.4.5 xp rates, level range, titles etc. Somewhere in the admtool there should be level ranges, titles, xp requiremensts that can be modulated. Heck, even the classic "buy up" the next level if your 15% or whatever and have gold/ This was an area where the lima team just felt if you didnt want a skill only system or didnt know how to code a leveling system your basically thrown to the wolves.

2) Drop alot of the function names from classic 2.4.5 and call it set_brief instead of set_short. There is no need to alter things for sake of idealism. I dont know if Dead Souls fixed the mixed caps issue where you can use either, but personally, mix caps is harder to read (Set_Long). Why do lib coders insist on changing things that work fine (end rant)

3) Reverse much of the "boxed" design decisions, like NO ADD_ACTIONS. I agree verbs are the way to go but there are some areas where a rare single command, an example is "deposit" to/from banks probably is better off using an add-action. Moreover, multilingual muds where english is not the default should have the option to define outside the verb paradigm. Verbs should be a guidline, not a straight jacket.

4) Adjust the news system to use bboards like dead souls. Easy and clean syntax, but I would try to code a phpbb3 web to in game bboard.o's to modern social media. At this point intermud is a not the make or break point of any mudlib. Real innovations and expansion to twitter. vent, facebooks, phpbb3 is the way to go.


5) Fix the bodyslots.h  so dual wield it works with the other options other than just "hitpoints"

6) Import the Dead Souls parser adjustments, if Crat is agreeable, so the weirdo lima syntax get third sword of second table to just get sword 3 from table 2. The parser syntax is not that player friendly. Major props to Wodan/Crat for the driver adjustments to overcome another annoyance.

7) adjust the party system to somewhat closer to boxed 2.4.5 stock. Rollback some function names to their classic names. Again do away with wierdness.


Stats..... whats wrong with the classic? Str, Dex,Con, Char, Wis, Int. Even Coffeemud uses these stats. No need for fancy terms like agility etc to replace what is well established in the mud world and beyond.

9) Flags are somehow better than "set_properties"? or set_perm flags.h is just really another way of idealizing and not changing anything real

10) create a pkiller daemon and corresponding options in the admintool to yes, no, range level, bounty system, etc.

11) Adjust MSSP, MCP and the goodies that DS modernized in their lib. Part of me wants to just use their earliest beta .08
 lima and adjust from there using Nightmare 3.3.1 some function.

Finally, on Dragonfire, we are making BATMUD like java client as an option.

[cratylus]

I am left wondering just why you like Lima.

It sounds to me like you're better off using Nightmare 3 and modernizing it, rather than jailbreaking Lima.

Lima has architectitis...inflammation of the design. As with the metric system, things that look great
on paper sometimes are lousy at roll up your sleeves time.

http://www.tysknews.com/Depts/Metrication/metric_land.htm

-Crat

[Holyavenger]

I am left wondering just why you like Lima.

It sounds to me like you're better off using Nightmare 3 and modernizing it, rather than jailbreaking Lima.

Lima has architectitis...inflammation of the design. As with the metric system, things that look great
on paper sometimes are lousy at roll up your sleeves time.

http://www.tysknews.com/Depts/Metrication/metric_land.htm

-Crat

I would be amenable to pay cash for core mudlib level hacking on hourly/per diem basis. Starting immediately. Unfortunately, I just don't have the core mudlib coding "gift". Perhaps using 3.3.1 Nightmare and moving on is the way to go. Thanks for the suggestion, Crat.

Moreover, any gains or code changes, I would release back to the public because I feel that any well done lpmud is a net gain for the community.

[On the side, I have a developer who has an elance project produce batmud like client. I committed to financing, so coin being spent]

Anyone want to make money with their lpc skill? Contact me here or email and later we can work out the details via phone.

Andrew

holyavenger @ mail. com

[Holyavenger]

I am left wondering just why you like Lima.

It sounds to me like you're better off using Nightmare 3 and modernizing it, rather than jailbreaking Lima.

Lima has architectitis...inflammation of the design. As with the metric system, things that look great
on paper sometimes are lousy at roll up your sleeves time.

http://www.tysknews.com/Depts/Metrication/metric_land.htm

-Crat

Yea, your probably correct. I know you have done a solid job getting LP's back into the mix of things

- I've ordered a live host. When one has to be serious about things, coin must be sent.
- redid so many options in local_hosts.h. I Enabled PCRE extentions for web based char creation the future and
backloaded it with every package woden created.

-Sans the add_actions and DB, both which I lack the mastery to overcome.

Add_Action problem, is there anyone who can help me restore this? I'm willing to pay cash. Besides add_actions recompiled into fluffos, there is
a /secure/check_config.c that needs commenting out.

Code: [Select]

/* Do not remove the headers from this file! see /USAGE for more info. */

#define need(x) badness += x + " is required for LIMA libs.\n"

#define FOOTER "**********************************************************\n"
#define IMPOSSIBLE_TO_MISS_HEADER \
               FOOTER \
               "* You have incorrectly compiled the MudOS driver.  This  *\n" \
               "* driver is not compatible with the LIMA mudlib.  Please *\n" \
               "* make the following changes to 'options.h' (or          *\n" \
               "* 'local_options' if it exists) in the driver source,    *\n" \
               "* and recompile.                                         *\n" \
               FOOTER

static
void create() {
    string badness = "";

    if ( mud_name() == "Your Mud's name here" )
badness += "You must change your mud's name in config.lima\n";

#ifndef __SANE_EXPLODE_STRING__
    need("#define SANE_EXPLODE_STRING");
#endif
#ifdef __CAST_CALL_OTHERS__
    need("#undef CAST_CALL_OTHERS");
#endif
#ifndef __NO_LIGHT__
    need("#define NO_LIGHT");
#endif
#ifndef __NO_ADD_ACTION__
    need("#define NO_ADD_ACTION");
#endif
#ifdef __NO_ENVIRONMENT__
    need("#undef NO_ENVIRONMENT");
#endif
#ifndef __NO_WIZARDS__
    need("#define NO_WIZARDS");
#endif
#ifdef __OLD_RANGE_BEHAVIOR__
    need("#undef OLD_RANGE_BEHAVIOR");
#endif
#ifdef __OLD_ED__
    need("#undef OLD_ED");
#endif
#ifndef __MUDLIB_ERROR_HANDLER__
    need("#define MUDLIB_ERROR_HANDLER");
#endif
#ifndef __ARRAY_RESERVED_WORD__
    need("#define ARRAY_RESERVED_WORD");
#endif
#ifndef __PACKAGE_CONTRIB__
    need("#define PACKAGE_CONTRIB");
#endif
#ifndef __PACKAGE_PARSER__
    need("#define PACKAGE_PARSER");
#endif
#ifdef __PACKAGE_UIDS__
    need("#undef PACKAGE_UIDS");
#endif

    if (strlen(badness))
error("Bad driver configuration:\n" + IMPOSSIBLE_TO_MISS_HEADER + badness + FOOTER);
}

I'm willing to pay for help on this. I know everyones time is valuable. The ADD-ACTION thing is huge (to my way of thinking) and getting someone good with DB's
knowlege would be be nice. I'll post my local_options.h. 

This what I will give back. A character/http to ingame PRCE character creations that will take this muddin to the next notch. Simimiliar to to BATMUD clients. We all know it needs it.

I'm open to anyone who can enable the ADD_ACTION thing. PLeaze let me your rates

Code: [Select]

lazyclownfish@yahoo.com 203-538-4262 Andrew

[unagi]

Why do you need add_action specifically? If you are going to the trouble of sticking with Lima, why not handle one-off actions like the designers intended?

From the file help/wizard/design_decisions/add_action:

Code: [Select]

P.S. if you really need it somewhere, there is always:

void create() {
    parse_init();
    parse_add_rule("foo", "STR");
}

mixed can_foo_str() {
    // or something appropriate to objects meant to be carried
    return environment(this_body()) == this_object();
}


Is there a specific reason you need add_action? Or you want it back because that is the expected syntax of the vast majority of the lpc-coding world?

[Holyavenger]

Why do you need add_action specifically? If you are going to the trouble of sticking with Lima, why not handle one-off actions like the designers intended?

From the file help/wizard/design_decisions/add_action:

Code: [Select]

P.S. if you really need it somewhere, there is always:

void create() {
    parse_init();
    parse_add_rule("foo", "STR");
}

mixed can_foo_str() {
    // or something appropriate to objects meant to be carried
    return environment(this_body()) == this_object();
}


Is there a specific reason you need add_action? Or you want it back because that is the expected syntax of the vast majority of the lpc-coding world?

Exactly, the "expected syntax of the vast majority of the lpc-coding world?". Moreover, it is I realize the LIMA designers wanted the all verb design for lima stamped muds, but there is a time and a place for add_actions. Even Dead Souls has add_actions sprinkled in here and there. Further, If you look at many of these mudlibs, you'll notice most pass functions that are the same but just named differently. For example, SetShort, set_short, set_brief, wtf, is there any real reason to have ever have changed it from set_short from back in Amylaar days. I digress though, I want to enable all the features the FluffOS driver is capabable of (within reason).

[cratylus]

Design is law, and Lima's design is not only clear but the intent
explicit. Adding add_action() to Lima is probably the highest insult
and heresy to its spirit.

I happen to think it's perfectly good and right to violate Lima's
short-sighted design philosophy, btw. I would suggest, though, that
if you're going to be an apostate anyway, you might as well avoid
a lib designed to make that as difficult as possible.

-Crat

[quixadhal]

The LIMA people were right, to a point.  add_action() really shouldn't be used in 99% of the cases you think it needs to be used.  The add_action() supporters will rightly tell you that adding new verbs is a pain in the rear, and thus add_action() is much easier.

LIMA's design seemed to be "do everything with verbs, even if it hurts, because it's the right thing to do!"  A more reasonable approach might be, do you think you're likely to want to use this verblike thing more than a couple times elsewhere in the entire history of your game?  If so, make it a verb.  If not, add_action() is probably a good choice.

For example, "push" would be a stupid add_action() choice.  There are likely to be lots of times you want to push something.  OTOH, "unravel" might be a good add_action() choice, unless you're doing a mystery or knitting themed MUD.

[detah]

I am not a computer science person. I cannot speak to much of this design theory stuff. I also cannot comment on Lima's intent.

But as I understand the issue, this is a Turnpike Theorem problem. Yes, it might be some extra work to write the verb. But in the longrun, you are making your life easier. You are adding to your library of available verbs and making your entire world a more seemless structure. Having coded on a mud which used add_actions almost exclusively, you should avoid add_actions, if for the one reason of simplicity. But if that is not sufficient, I also argue that it is also work-minimizing in the long run.

We had 'read' as an add_action. We had some books hardcoded in rooms, which used the read add_action. AND we had book objects which also had the read add_action in them. Believe me, this became a nightmare very quickly, trying to distinguish every single book object in the game. When 'read red book' in your inventory is conflicting with a different 'red book' in your current room, I think that alone is sufficient evidence against add_actions. But consider this: The solution to this common object conflict in the verb case is pretty simple: add a unique adjective or alias to one of the objects. The solution to this conflict in the add_action case is to add a whole new if(str=="big red shiny book") OR statement. It is obvious at this point, that the verb route is both the optimal way and the work-minimizing way to go.

-Detah@Arcania

[zyl]

I don't think anyone would argue that add_action() is a poor way to go about things the vast majority of the time, but to cut out a part of code that everyone knows is a little silly just because you have some idealistic goal to achieve. Read is very bad, but withdraw, which would probably only ever be used in a bank, would be a fairly good example of a time when adding a verb would be extra, and not needed extra at that.

[quixadhal]

I have to disagree with Zyl here.

Bad practice is bad practice.  You may *THINK* you only have one use for a particular verb, like withdraw, but at some point down the road another coder will find a different use for it, like withdraw sword from fire.  Then another builder will come up with withdraw from race.  And it goes on...

Also, how is it that "everyone" knows add_action?  New coders don't know it.  Old coders coming here from the DikuMUD world don't know it.  Just because us old farts all know it, doesn't make it some kind of universal thing that everyone will just intuit.

I submit that if you learn and work with a verb system, it pretty quickly stops being "hard" or "all that extra work", and just becomes "the way to add new commands".

[Holyavenger]

I have to disagree with Zyl here.

Bad practice is bad practice.  You may *THINK* you only have one use for a particular verb, like withdraw, but at some point down the road another coder will find a different use for it, like withdraw sword from fire.  Then another builder will come up with withdraw from race.  And it goes on...

Also, how is it that "everyone" knows add_action?  New coders don't know it.  Old coders coming here from the DikuMUD world don't know it.  Just because us old farts all know it, doesn't make it some kind of universal thing that everyone will just intuit.

I submit that if you learn and work with a verb system, it pretty quickly stops being "hard" or "all that extra work", and just becomes "the way to add new commands".

What if you want to tap into other spoken langanges ( multilingual MUDs ) verbs have different rules on different languages

Second, verbs should be a tool not a straight jacket. Let the designers make that choice. Loriel almost vomited when I came back with a version jailbroken and I had to retreat on it and lost the 3 files that allowed them

[quixadhal]

Multi-linqual muds (if such a thing really exists... most muds tend to have a dominant language, and somewhere between no and some support for others), may need different rules for parsing.  You might need the verb system to look at the player's language choice when deciding which order to parse command tokens with.

The problem with letting developers choose is.. they all choose something different, and often inconsistent.  See the current state of the Linux desktop.

add_action() is quick and easy.  Most people will use it because it's less work than fiddling with a verb system and making it work properly.  Hands down, all the lazy folk will use add_action() if it's there.

Then there's the permission issue... anyone who can create an object can add a command to it via add_action().  You can add hooks for existing verbs easily, but adding a brand new verb requires higher security access, as you need to place it in a verb path somewhere.

But saying "it's easier, and the builders should be able to choose" ignores the exact problem that verbs were created to solve.  When you want to add "twist" as a new command for your dagger, and you can use add_action(), you just do it and move on without thinking.  When you have to use verbs, it requires you first check to see if twist already exists (or is a synonym of another verb).  If not, you then have to think... is it REALLY a new verb, or could I add it as a synonym for something else....perhaps turn?  And, if you finally decide it really is a new, unique, command... you have to get an admin to agree with you.

What's that gain you?  Consistency.  It means once "twist" is added as a synonym to "turn", along with "rotate", the player can now stab you and twist/turn/rotate for extra damage without needing to worry about which variation is the "right" one.

Normally, you'd think "twist dagger", but maybe the builder who used add_action() was thinking "turn dagger".  Maybe a different dagger from a different area of the game (coded by a different builder) used "twist dagger".  So, you played through area 13 and used twist dagger to bloody success.  Now, you're in area 15 and a new dagger drops.  You wield it, and suddenly "twist dagger" doesn't work anymore.  Do you even think to try "turn dagger", "rotate dagger", "spin dagger", "curse at guess-the-verb dagger coder"?  Or do you just assume that for some reason, this dagger is square and can't be twisted?

How do you prevent this while allowing add_action()?

Are you really going assign an admin to audit EVERY SINGLE instance of add_action() in the entire mudlib?