30 Jan, 2012, plamzi wrote in the 21st comment:
Votes: 0
Cratylus said:
plamzi said:
Cratylus said:
you win. it sux.


In your passive-snippiness mode, I'm afraid you're missing the point. The point was to throw some cold water on the LPMud folks who show up predictably to every thread of this sort, eager to snub their nose at their inferior Diku brethren. Silly stuff.


I guess the joke's on me for responding to arguments on their merits.

Do carry on with whatever other thing you were doing.

-Crat
http://lpmuds.net


OK, so the OP suffered from a bit of naivete. There will always be people who are new to a concept. The helpful thing would be to point them to a place where they can learn how to implement shared objects and to give them a sense of the amount of effort is vs. the benefits. Correct me if I'm wrong, but examples of unhelpful (and self-indulgent) responses would include talking about how many years ago one saw this concept used in LPMud and projecting inferiority on people using other codebases. And I don't mean your post, which was much more sober than quix's. I hope you don't feel like I was attacking you because I actually agree with all you've said so far except for the "worth touting" bit.
30 Jan, 2012, quixadhal wrote in the 22nd comment:
Votes: 0
While I may be a bit evangelical in my descriptions, what part of my statement was not factual?

LpMUD is a game system, designed NOT to implement a game, but rather to implement a working environment and a fully generic programming language which is used to create a game within that sandboxed environment. Changes to anything inside the sandbox can occur at any time, and a failure of one component will result ONLY in the failure of that component, or of any components which reply on that one to function.

This is in contrast to the DikuMUD architecture, which places all game systems in top-level code with no sandboxing of any kind. A failure in one system can, at best, crash the driver and prevent the game from functioning until it is repaired. At worst, it can cause string corruption which may be written back to disk without the knowledge of those running the game, and that can cause loss of data.

Now, it is true that with copyover, you can simulate being able to modify core systems on the fly, and thus (at least in theory) you could allow people to edit them online, in practice this would be a bad idea for security reasons. In an LpMUD, I can grant you permission to modify a given area's code, and any changes you make are thus limited to that area. In a DikuMUD, I don't see how you can reasonably allow editing of the source code without affecting the entire game, since you HAVE to generate a new executable to implement the changes. While you could restrict the files they can edit, you can't easily stop them from modifying data – because it's all accessible via pointers.

I suppose you could use dlsym to unload/load segments of code at runtime, and trust to C++'s encapsulation to try and protect you from novice/malicious coders. But by the time you've invested enough effort into building such a system… you could have put that effort into coding your game by using an LpMUD (or ColdC, or TinyMUSH, etc) which was designed for it.

Now, by all means, you may return to reinventing the wheel for the 9001st time, and pat yourself on the back at how clever you have been in NOT using all those other inferior wheels that other people have been overly smug about using. It's YOUR wheel, and even if it has a few flat spots, it gets the job done, no?
30 Jan, 2012, plamzi wrote in the 23rd comment:
Votes: 0
quixadhal said:


I suppose you could use dlsym to unload/load segments of code at runtime, and trust to C++'s encapsulation to try and protect you from novice/malicious coders. But by the time you've invested enough effort into building such a system… you could have put that effort into coding your game by using an LpMUD (or ColdC, or TinyMUSH, etc) which was designed for it.

Now, by all means, you may return to reinventing the wheel for the 9001st time, and pat yourself on the back at how clever you have been in NOT using all those other inferior wheels that other people have been overly smug about using. It's YOUR wheel, and even if it has a few flat spots, it gets the job done, no?


There's nothing in the OP to suggest that he is shopping around for a codebase, deeply excited about online sandboxing for coders, yet stubbornly refusing to look at anything but stock Diku. I believe those are all your projections, designed to allow you to feel smug about your own choices and imagine that you have "the most inflated wheel" around. It's basically a re-dressed Apple vs. PC debate, and as such it can serve no useful purpose.

And in case your last two paragraphs are addressing my game rather than Igabod's or Rarva's, then you're most definitely projecting. I never shopped around for a codebase (wanted to develop a specific CircleMUD I used to play) and I never cared about creating a secure environment for novice coders to update code at runtime. When I develop for my project, I try to stay focused on end results that improve the gameplay experience. There's precious little here that's "client-facing", so any further development on my quick shared object implementation is going to have very low priority (it remains to be seen whether I'll even use it in production).
30 Jan, 2012, Rarva.Riendf wrote in the 24th comment:
Votes: 0
Single example: How can you in a LPMUD make so you can have a unique instance of an object that no player can quit with or destroy in any way, that if on the ground move around every random amount of time, that will put an info if picked or when moving…cannot be sold, cannot be enhanted etc.
That remembers its position and is loaded in he case there is a crash or reboot.

Just by giving right to only edit one or two files…

Oh and do that live :)

Be careful in the order in wich you edit the code….
30 Jan, 2012, Cratylus wrote in the 25th comment:
Votes: 0
Rarva.Riendf said:
Single example: How can you in a LPMUD make so you can have a unique instance of an object that no player can quit with or destroy in any way, that if on the ground move around every random amount of time, that will put an info if picked or when moving…cannot be sold, cannot be enhanted etc.
That remembers its position and is loaded in he case there is a crash or reboot.

Just by giving right to only edit one or two files…

Oh and do that live :)

Be careful in the order in wich you edit the code….


Well in DS you'd make it SetUnique, you'd make it add a shadow to the owner that prevents quitting, give it a heartbeat and add a move function to it that's checked on heartbeat, set it to be not CanSell, add a shadow to it so it can't be enchanted.

So that's all just in the one file for the one object.

As to saving its location on reboot, you'd probably make a call to the room so that it's persistent, which iirc I added to the lib at some point. So actualyl I guess that's just still the one file.

I'm late for a meeting, so let me know if I missed a requirement and I'll check back

-Crat
http://lpmuds.net
30 Jan, 2012, Rarva.Riendf wrote in the 26th comment:
Votes: 0
I do not want the owner to be forbidden to quit, I want the item to leave him if he does…
I do no want it to not be sellable, but to leave the player if he attempt to sell it..
And for enchant I do want it to have a specific message if he does attempt it.
I want the object not being damageable 'by any means' but state a specific message depending on the skill that usually can do it.
And the timer is only set if the object ends up on the ground.

Oh and the items override anything that could prevent it to be wearable by the player (provided he has the part needed)
And when you identify it it looks different as it is a unique item.
30 Jan, 2012, Cratylus wrote in the 27th comment:
Votes: 0
I understand you think this is some kind of challenge. It really really isn't hard at all.

Rarva.Riendf said:
I do not want the owner to be forbidden to quit, I want the item to leave him if he does…


That's even easier. Disable "save on quit" on the object.


Quote
I do no want it to not be sellable, but to leave the player if he attempt to sell it..


No problem. Override eventSell().

Quote
And for enchant I do want it to have a specific message if he does attempt it.


Override functions that modify the object's stats and have a message in the override.

Quote
I want the object not being damageable 'by any means' but state a specific message depending on the skill that usually can do it.


Override eventReceiveDamage() with the appropriate checks.

Quote
And the timer is only set if the object ends up on the ground.


Make the heartbeat-triggered function check the environment and disable heartbeat as appropriate.

Quote
Oh and the items override anything that could prevent it to be wearable by the player (provided he has the part needed)
And when you identify it it looks different as it is a unique item.


I don't really know what this part means but it sounds pretty easy too.

You really don't get LP, that much is obvious. And, once again, all this stuff is in just the one file for the object.

-Crat
http://lpmuds.net

PS one caveat…in DS if you're going to use a shadow for this, you'd need a separate shadow file too, so strictly speaking my example uses 2 files, updateable at runtime with no risk of instability to the game.
30 Jan, 2012, quixadhal wrote in the 28th comment:
Votes: 0
Rarva.Riendf said:
I do not want the owner to be forbidden to quit, I want the item to leave him if he does…
I do no want it to not be sellable, but to leave the player if he attempt to sell it..
And for enchant I do want it to have a specific message if he does attempt it.
I want the object not being damageable 'by any means' but state a specific message depending on the skill that usually can do it.
And the timer is only set if the object ends up on the ground.

Oh and the items override anything that could prevent it to be wearable by the player (provided he has the part needed)
And when you identify it it looks different as it is a unique item.


All quite doable. The specifics would vary from one mudlib to the next.
I'm sure DS has an option to make an item not save when it's part of a player's inventory, so if they quit by any means, it will simply not be there when they return.

Likewise, if setting the value to 0 isn't good enough, you can trap attempts to sell it and print a cute message while having the object destroy itself. The easiest way would be an add_action(), but I'm sure there are others.

An "enchant" totally depends on the system, since there isn't any common sense of what that actually means from one mudlib to the next. It may be as simple as a NoEnchant property with an associated failure message. It might be more complex. Realize that an "enchant" might be as simple as adding a property to an object that gets checked later, or as complex as a shadow or other function that actually intercepts calls and alters their results.

Moving around while on the ground is easy. Just make a heartbeat() function and in it, check that environment(this_object()) is a room, and if so, decrement your "move" timer. If it hits zero, move and reset the timer. If the environment changes, reset the timer.

Avoiding damage… I think DS has an eventDamage() and perhaps a eventReceiveDamage() which could be overridden. Most LpMUDs tend to have such calls return 0 on success and an error message string on failure, so if you can identify the damage type that's being applied (likely), you can print a custom message while rejecting the damage.

Having it present a unique appearance is easy. You can just setLong( (: code to show unique appearance here :) ); If the appearance won't change over the lifetime of the individual item, you don't even need a funcational, just set it in init() when the object is cloned.

Not quite sure what you mean by the wearable issue. I assume perhaps you mean make the item automatically remove any cursed items that might otherwise prevent you from wearing it? That also seems quite doable, and there's likely an eventWear() or similar which is called when you attempt to wear something.

So far, nothing you've posted requires anything outside the object itself.

EDIT: Heh, Crat replied while I was typing, so assume he knows what he's doing and I don't. *grin*
30 Jan, 2012, Rarva.Riendf wrote in the 29th comment:
Votes: 0
No, not disable save on quit, but have an action made on the object when the player quit.(basically have it randomly dispatch somewhere, and have an info telling where it has gone)
Maybe you have a ItemActionOnQuit event.

Quote
No problem. Override eventSell().

No, you do no sell…you type sell, and the object leaves you. (with a general info message ), I dont want to have all the selling messages dispatched.

Quote
Override eventReceiveDamage() with the appropriate checks.

And every spell/skill that interact with the object is also in the object file ?

Quote
I don't really know what this part means but it sounds pretty easy too.

It means that whatever object you are wearing it is removed and replaced by the items,overrides everything that could prevent an item to be removed.
30 Jan, 2012, Cratylus wrote in the 30th comment:
Votes: 0
You're starting to depress me :(

Rarva.Riendf said:
No, not disable save on quit, but have an action made on the object when the player quit.(basically have it randomly dispatch somewhere, and have an info telling where it has gone)
Maybe you have a ItemActionOnQuit event.


Yeah in this specific case you'd override eventMove() to determine why the object moved, and if it is due to a quit, send some detailed message.

Quote
No, you do no sell…you type sell, and the object leaves you. (with a general info message ), I dont want to have all the selling messages dispatched.


Just put the appropriate checks and messages in the override.

Quote
And every spell/skill that interact with the object is also in the object file ?


Those things make a call to the object. That call goes to a function. The calling object doesn't have to be relevant if you don't want it to be. The function just does what you code it to, whether it's to disregard the buff, send a snarky message, whatev.

Quote
It means that whatever object you are wearing it is removed and replaced by the items,overrides everything that could prevent an item to be removed.


Yeah, trivial. Just override CanEquip() or whatever. Are we done yet?

-Crat
http://lpmuds.net
30 Jan, 2012, plamzi wrote in the 31st comment:
Votes: 0
You can override any function that you've already set to be looked up in the shared library first. If a bug is in an unintercepted function or if a change you envision requires modifying the way in which the main game logic interacts with the mudlib, then you'll need to reboot. When that happens, try to remember that uptime != awesomeness and just do it. If you need therapy afterwards, come to mudbytes and pretend that you've never had to reboot your game. Someone will eventually be impressed.

Classes of uniform functions (e. g. all user commands) are easier to intercept than, e. g. utility functions called from multiple places. True, you can eventually intercept all functions in your game, but if you're anything like me, you'd be dead from boredom by then. But if you're not dead, you'll have the longest, erm, uptime of them all. That is, unless someone else has been overriding you without you even noticing!
30 Jan, 2012, Cratylus wrote in the 32nd comment:
Votes: 0
plamzi said:
If a bug is in an unintercepted function or if a change you envision requires modifying the way in which the main game logic interacts with the mudlib, then you'll need to reboot.


I'd like an example of this, actually. One does not readily come to mind for me, since the game logic is in the mudlib.

In any case, as tiresome as the rarva quiz was, I think it makes a good point that explains why "uptime" is not the thing to focus on as being oh so awesome, but rather flexibility.

I assume that rarva was dreaming up these "challenges" because for him it would require some kind of coder intervention that would call for a reboot.

The thing I'd like to point out is that if you leave out the "reboot" part, you notice that the real awesomeness here is more about a rank-and-file creator/builder/whateveryouwannacallit having the power to do this stuff without requiring a special class of uberuser called a "coder" to get around to implementing it for them*.

Cmon, that's a littlenifty.

-Crat
http://lpmuds.net

*shadows are a special case since they require some security precautions, but largely they can be worked around if you are determined enough
30 Jan, 2012, plamzi wrote in the 33rd comment:
Votes: 0
Cratylus said:
The thing I'd like to point out is that if you leave out the "reboot" part, you notice that the real awesomeness here is more about a rank-and-file creator/builder/whateveryouwannacallit having the power to do this stuff without requiring a special class of uberuser called a "coder" to get around to implementing it for them*.

Cmon, that's a littlenifty.


You have legions of rank-and-file coders who have great stuff to contribute to your game, know how to code almost anything, but yet are not worthy enough to be given code access and would otherwise have to wait for you to shine in? Lucky you, I guess. I have to think about this some more, but it seems that using a mudlib as a way to keep a close tab on your code is indeed very nifty.

So, to sum up, mudlibs are the way to go if you want to:

1. Compete in the uptime e-peen contest.

2. Have people contribute code to your game without giving them code access.

3. Optionally, dis other codebases that don't care to compete in #1 and #2.
30 Jan, 2012, Cratylus wrote in the 34th comment:
Votes: 0
Did I offend the Shaolin temple? Maybe I just looklike Quix?

I explicitly discounted 1) in my previous post, you keep acting like it's all LPmudders care about.

I don't see how you can consider what I've shown to be not "giving them code access". It obviously is given.

And if you're trying to discourage people from mindless trolling, perhaps you should avoid it yourself, as you failed to avoid in 3).

I think I made a valid point. If that's really how you react to valid points, I fear to read the other threads you're in.

-Crat
http://lpmuds.net
30 Jan, 2012, plamzi wrote in the 35th comment:
Votes: 0
Cratylus said:
The thing I'd like to point out is that if you leave out the "reboot" part, you notice that the real awesomeness here is more about a rank-and-file creator/builder/whateveryouwannacallit having the power to do this stuff without requiring a special class of uberuser called a "coder" to get around to implementing it for them*.



I don't see how you can consider what I've shown to be not "giving them code access". It obviously is given.


I think I made a valid point. If that's really how you react to valid points, I fear to read the other threads you're in.

-Crat
http://lpmuds.net


Maybe I'm missing something in your point that you can help me understand better. If you're not talking about "sandboxing" coders, how is a game using shared objects any more flexible than a game that provides code access to a developer instance? To me, the only difference seems to be that once changes are tested, the former will not require a reboot to implement these changes while the latter will.
30 Jan, 2012, Cratylus wrote in the 36th comment:
Votes: 0
plamzi said:
Maybe I'm missing something in your point that you can help me understand better. If you're not talking about "sandboxing" coders, how is a game using shared objects any more flexible than a game that provides code access to a developer instance? To me, the only difference seems to be that once changes are tested, the former will not require a reboot to implement these changes while the latter will.


It's what the title of the thread is about. In-game programming allows you to set permissions within the game that allows you to provide access to code in a manner that makes sense within the game, rather than making anyone with shell access de facto superuser.

Your creators have the power to do very fancy things without needing shell or indulgent coders. That was kinda where this started.

It's not just about reboots. You're the one focusing on that.

-Crat
http://lpmuds.net
30 Jan, 2012, Rarva.Riendf wrote in the 37th comment:
Votes: 0
Yeah just wondering what happens when you end up with an infinite loop overriding all those methods when you have two events thaat call each other.
30 Jan, 2012, Cratylus wrote in the 38th comment:
Votes: 0
Rarva.Riendf said:
Yeah just wondering what happens when you end up with an infinite loop overriding all those methods when you have two events thaat call each other.


If you do an infinite loop, it breaks with a "too long eval" when it hits the maximum eval limit.

Some Windows versions of LP don't handle this well, but on unix this problem is avoided.

-Crat
http://lpmuds.net
31 Jan, 2012, Rarva.Riendf wrote in the 39th comment:
Votes: 0
By the way I am not dreaming a challenge, I did this in my code, works well without a hassle. Seems to me you have an awful lot of overiding in methods to have the same result, with an obvious problem to me: overriding methods means they start doing stuff that could break thing if you make the basic method evolve…I would hate to maintain that…but yeah you did not reboot in 'this' perticular case
31 Jan, 2012, Cratylus wrote in the 40th comment:
Votes: 0
Rarva.Riendf said:
By the way I am not dreaming a challenge, I did this in my code, works well without a hassle. Seems to me you have an awful lot of overiding in methods to have the same result, with an obvious problem to me: overriding methods means they start doing stuff that could break thing if you make the basic method evolve…I would hate to maintain that…but yeah you did not reboot in 'this' perticular case


It might seem like a problem to you, but it's not really so in practice.

In any case it's a pretty convoluted and contrived exercise, so I don't think it's probative of much of anything, honestly, other than flexibility of the codebase, as I mentioned previously.

-Crat
http://lpmuds.net
20.0/111