31 Jan, 2012, plamzi wrote in the 41st comment:
Votes: 0
Cratylus said:
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


If the goal is to implement access levels and allow users to contribute content, including code, within the same session in which they're gaming, then we shouldn't be talking about dynamic libraries at all but about specialized sub-interfaces. I realize that someone thinking within the LPMud paradigm would think of such tools as inseparable from their own codebase, but really there's nothing to stop any MUD from providing an editor for code snippets. Whether these snippets go live via a reboot of a developer instance, a hot boot, or a dynamic library recompile is really beside the point – the coding experience itself is/was "social".

I'm not so keen on the whole "editing within telnet" experience, but I do intend to let people edit and create special procedures via our new web-based OLC very soon. Most likely, my assistant coder and I will be the only ones using that part of the editor but it will be there for any future advanced builders.
31 Jan, 2012, Cratylus wrote in the 42nd comment:
Votes: 0
plamzi said:
If the goal is to implement access levels and allow users to contribute content, including code, within the same session in which they're gaming, then we shouldn't be talking about dynamic libraries at all but about specialized sub-interfaces. I realize that someone thinking within the LPMud paradigm would think of such tools as inseparable from their own codebase, but


I provided an example of it being done, and did so civilly.

-Crat
http://lpmuds.net
31 Jan, 2012, Rarva.Riendf wrote in the 43rd comment:
Votes: 0
I have a hard time considering this is not like a shell access to pretty much the whole code when you have the power to overide pretty much everything.
31 Jan, 2012, Cratylus wrote in the 44th comment:
Votes: 0
Rarva.Riendf said:
I have a hard time considering this is not like a shell access to pretty much the whole code when you have the power to overide pretty much everything.


It is a tremendous amount of power in the hands of creators, yes.

A good security scheme prevents most malicious abuse of that power, so it's not necessarily a problem.

-Crat
http://lpmuds.net
31 Jan, 2012, Rarva.Riendf wrote in the 45th comment:
Votes: 0
You mean careful selection of the coders that will be able do do it ? I do not see how you can prevent someone to screw everything if he wants to since he has code access.
31 Jan, 2012, Cratylus wrote in the 46th comment:
Votes: 0
Rarva.Riendf said:
You mean careful selection of the coders that will be able do do it ? I do not see how you can prevent someone to screw everything if he wants to since he has code access.


If I agreed with this, I would not be running a mud where anyone who logs in automatically becomes a creator: http://dead-souls.net/dsd/anyterm.shtml
31 Jan, 2012, Rarva.Riendf wrote in the 47th comment:
Votes: 0
Let me code an object that nuclear wipe your whole world :)
31 Jan, 2012, Cratylus wrote in the 48th comment:
Votes: 0
Rarva.Riendf said:
Let me code an object that nuclear wipe your whole world :)


You could probably code something that kills everything…indeed there's already a command to do it (it's called "vaarsuvius").

I didn't think that was what you meant regarding causing damage though.

-Crat
http://lpmuds.net
31 Jan, 2012, quixadhal wrote in the 49th comment:
Votes: 0
Rarva.Riendf said:
I have a hard time considering this is not like a shell access to pretty much the whole code when you have the power to overide pretty much everything.


Ok, here's the difference.

On an LpMUD, I can grant any builder access to the files in a given area of the world. They can code whatever they can dream up in there, without any access to the core game logic or any other areas. They can override any default function in any code they inherit, unless it's specifically prevented by the nomask keyword.

In theory, this gives them the ability to cause havoc. In reality, this gives them the ability to be creative. Because their code can ONLY write to things in their assigned area, they can't subvert anyone else's code. They can create objects which might do "bad things" or allow players to cheat, but those are easily shown to be theirs because everything in an LpMUD uses a pathname for an ID value. If /domain/cheater/sword.c is giving people inappropriate powers, you know it came from cheater's domain and can take the appropriate action to fix the objects and/or admonish the wizard who made it.

Within that area, the builders can make up entire new game mechanics and systems, ones that work entirely differently than anything else in the game. They can't directly modify the player object itself, but they can make so-called "invisible" objects which live in the player's inventory and save state information for those new systems. ALL without risking breaking the core systems.

That's the difference. With shell access, I can edit the source code and compile a new driver which has fundamental changes in core systems that may break or affect EVERYTHING in the game. With LPC, I can code systems which *SEEM* (to the players) to be just as fundamental a change, but are in reality limited to a handful of files and objects. If those objects suddenly went away, the players would still load up and play the game just fine, but would simply be without those things.

plamzi said:
If the goal is to implement access levels and allow users to contribute content, including code, within the same session in which they're gaming, then we shouldn't be talking about dynamic libraries at all but about specialized sub-interfaces.


And there is another illustration of the differences. Because the entire game system is built inside the LPC sandbox, anyone with access to write LPC code can create entirely new systems or override existing systems that don't explicitly prevent this. The special "admin" class of users doesn't have to sit down and think "OK, a builder might want to be able to do this, or this, or this, so I need to write API's to allow them to access exactly those things."

For example, in the default system there are rooms. These rooms have exits which link them to other rooms. There are events associated with someone attempting to use these exits. The mudlib may check for and call events functions for pre-and post conditions of both exits involved in moving from one room to another. In the pre-exit condition of the source room, you might stop them from leaving because they lack a key. In the post-exit, you might cause their group to follow them out. In the pre-enter of the destination room, you might return them to the room they came from because a security guard refuses to allow them in.

Now, those hooks are available to the builder as things they can override to accomplish whatever situations they want to dream up. But… suppose they want some kind of fighting arena where rooms don't work the same way? Maybe they want a big sandpit where moving is tactical and repositions you within the same room by coordinates? That's doable by the builder without having to modify the normal room code at all.

They can override the default movement commands, and they can design their own kind of room that has different rules and properties than the normal system. They don't need admin privs, they don't need the MUD owner to think up a new API to allow them to do it. They may choose to inherit functionality from the normal room system so they don't need their own special versions of commands like "look", but again… if they want to write their own commands, they are free to do that as well.

All those changes and creations are LOCAL to that builder's area. If a player gets stuck in there due to errors, another wizard can easily move them back into the rest of the world with no ill effects.
31 Jan, 2012, Rarva.Riendf wrote in the 50th comment:
Votes: 0
I definitely would not like this kind of system, as it means uncoherent behaviour depending on areas you are in.
And moreover, wheel reinvention all around.

Quote
he special "admin" class of users doesn't have to sit down and think "OK, a builder might want to be able to do this, or this, or this, so I need to write API's to allow them to access exactly those things'


Well off course…every user is already one, per default.
31 Jan, 2012, Cratylus wrote in the 51st comment:
Votes: 0
Rarva.Riendf said:
I definitely would not like this kind of system, as it means uncoherent behaviour depending on areas you are in.
And moreover, wheel reinvention all around.


That's not really how it works out in practice.

Rarva.Riendf said:
uncoherent behaviour depending on areas you are in


This is only true of the admins allow it. Just because your creators can make uberswords of slaying doesnt mean that your quality control team is going to let that stay in the creator's area once it is scheduled to be moved to the live areas players can access. Just like creators can't modify parts of the game they don't have write access to, they can't link their hosed up freaky areas to the rest of the mud on their own.


Rarva.Riendf said:
wheel reinvention all around.


Not really. Quix was describing an unusual situation to illustrate the power available. Having to redefine fundamental environment behavior isn't common. It's just an example of the power available to creators.

-Crat
http://lpmuds.net
31 Jan, 2012, quixadhal wrote in the 52nd comment:
Votes: 0
There's not really much wheel reinvention. Typically, you use things from system areas unless you want to do something different. As for non-coherent behavior, that's not a platform issue… that's a social issue. If you can't keep your builders on-track for the theme of your game, perhaps you need to find new builders rather than enforce it via code?

You missed the point Rarva. Every builder is NOT an admin by default. Just the opposite, they have the ability to code whatever they wish within their own areas, and NOT in the general system area where most of the inheritable code lives. Again, misbehavior is a social problem, not one you can solve with technical constraints.

I never understood the idea of trying to write your game in such a way that you're assuming the worst from your team. You give people access to create things in your game because you want to work WITH them, not against them. If they aren't doing this, you fire them and find new people. Trying to restrict people from editing things that can break large-scale systems is guarding against accidents. Trying to restrict them from not following your instructions or making things not-balanced/not-in-theme/etc is saying you don't trust them. If you don't trust them, why are they there? If you ran a business like that, you'd never release a product on time or under budget.
31 Jan, 2012, Rarva.Riendf wrote in the 53rd comment:
Votes: 0
I am not talking about balance, I am talking about code management. Tell Linus he should trust its comitter and not check their code till a problem appear….It is not a trust issue, at all. (yeah right)

Quote
If you ran a business like that, you'd never release a product on time or under budget.

If you run a bunisses like a lpmud, you will end up like the Linux desktop: utter failure for 15 year straight, and keep counting.
31 Jan, 2012, Cratylus wrote in the 54th comment:
Votes: 0
Rarva.Riendf said:
If you run a bunisses like a lpmud, you will end up like the Linux desktop: utter failure for 15 year straight, and keep counting.


Some very popular and successful muds are LP.

Can we please not go down the sad route of debating Linux desktops or declaring entire codebases failures.

Rarva, you are not understanding the point being made. Code management is not a problem in an LP any more than anywhere else. Users != Admins. Please understand that there are levels of access and privilege.

There are plenty of legitimate things to dislike about a given codebase. There is no need to make stuff up.

-Crat
http://lpmuds.net
31 Jan, 2012, quixadhal wrote in the 55th comment:
Votes: 0
Rarva.Riendf said:
I am not talking about balance, I am talking about code management. Tell Linus he should trust its comitter and not check their code till a problem appear….It is not a trust issue, at all. (yeah right)


Actually… that's kinda how it works. Folks submit new device drivers and since they are written as modules, if they crash they don't pull down the entire kernel. I highly doubt Linus hand-checks every single device driver's code, by hand. LpMUD is like that, objects are independant of one another to a large degree. If one does bad things, it is easily isolated and resolved. If I assign you to a domain, no matter how much you TRY to do bad things, you can only do them with respect to the domain you're part of.

Anyone who wants to try coding and building stuff is welcome to do so, but their stuff is restricted to their workroom area, which isn't linked in any way that the players can get to. If I (or a fellow established wizard) likes what you're doing, they may offer to let you work on (or even be in charge of) an area. In that case, you can do exactly the same thing you can do in your personal workroom, except in an area you share with other builders. If the quality is good, it'd be linked into the game world the players can access. If not, other builders may be assigned to help.

If you're really familiar with the infrastructure and want to help do so, you can be given a broader access level, allowing you to edit core systems. Again, this is all the same mechanism… there's no magic shell access or recompiling of anything. It's just a question of what parts of the mudlib you can edit vs. what parts you can only look at.

Keeping regular backups and revision control is always a good idea, but not as a form of security. If you have builders who are intentionally doing bad things, that's a social issue. That is *YOU* being stupid. No amount of code management will save you from that.

So, since you're being all snippy and superior, let me ask you a question.

How do YOU prevent your builders from making abusive items, either by setting values inappropriately, or by using your "mudprog" scripts to do things that aren't proper?
31 Jan, 2012, Rarva.Riendf wrote in the 56th comment:
Votes: 0
Cratylus said:
Rarva, you are not understanding the point being made. Code management is not a problem in an LP any more than anywhere else. Users != Admins. Please understand that there are levels of access and privilege.

I just see a lot of problems managing all that code around built in area instead of the engine itself. It may be a good engine I do not doubt it, but making it evolves without breaking anything must be a nice headache. Not to see Diku are free of them, but all the stuff you put in event are just put in functions, so if a builder wants to code, he pretty much to the same (go in the right method) and then everyone benefits from it as it becomes one more option in the API.
And you dont have to wait for problems to see if a change in an object wont interact badly in another area change.
As my example about object if one decided to overide an item so it cannot be removed 'at all' and one decide that an item can removed even those items…what happens…
If one decide to add a part to the player with an item, but another decide to remove that part, what happens.
Those points actually boggle me when you do not have centralized code. (unless it is the last one speaking always being right)


Quote
How do YOU prevent your builders from making abusive items, either by setting values inappropriately,

They can do whatever they want, I have something at boot that identify all items and show the one that are off mark in logs.
So it wont ever leave build port.
31 Jan, 2012, Rarva.Riendf wrote in the 57th comment:
Votes: 0
Quote
I highly doubt Linus hand-checks every single device driver's code, by hand.

Actually he does check a lot of stuff and if it does not please him they do not integrate the kernel.
31 Jan, 2012, Cratylus wrote in the 58th comment:
Votes: 0
Rarva.Riendf said:
I just see a lot of problems managing all that code around built in area instead of the engine itself. It may be a good engine I do not doubt it, but making it evolves without breaking anything must be a nice headache.


It isn't a headache. It's hardly even a consideration. See below:

Rarva.Riendf said:
As my example about object if one decided to overide an item so it cannot be removed 'at all' and one decide that an item can removed even those items…what happens…
If one decide to add a part to the player with an item, but another decide to remove that part, what happens.
Those points actually boggle me when you do not have centralized code. (unless it is the last one speaking always being right)


Now I have a better understanding of what is bothering you.

Let's take this example of a magic helmet which is ALWAYS wearable, to the point of removing any other headgear if it's in the way. Let's say this was coded by someone named Horn.

Another creator, Hardart, coded a helmet which CANNOT be removed, no matter what, to the point of overriding "remove" functions and even "move" functions.

What happens then?

What happens is that whichever object is coded to "win" that contest, either intentionally to overcome the other, or accidentally through thorough coding, "wins".

So if wear-helmet happens to know about no-remove helmet and is coded with specific countermeasures against it, well, no-remove helmet will likely be removed.

Then again, Hardart might find out what Horn was up to and code counter-counter measures in his no-remove helmet, and the wear-helmet will then fail to be worn.

And this tug of war might go on for a little while, either in good humor or bitter competitiveness, and if things get out of hand one or both will probably appeal to an administrator for a judgment call on how to handle the conflict.

In the end, what you describe is a human conflict which is handled through human conflict resolution. It isn't a problem specific to any codebase in my opinion, I suspect there are a few projects with multiple human participants that need Word Of God to settle such issues.

Having said that…this sort of absolute "my object must win" sort of thing is something that shouldn't be seen by actual players if areas have been through QC…unless approved by QC. After quality control and linking to the open game, that creator shouldn't have write access to it anyway, and decisions about which helmet is the uber helmet now fall directly on admins.

-Crat
http://lpmuds.net
31 Jan, 2012, Tricky wrote in the 59th comment:
Votes: 0
Runs in…

An LPC manual - http://www.monkeys-at-keyboards.com/epit...

Runs out…

Tricky
31 Jan, 2012, Rarva.Riendf wrote in the 60th comment:
Votes: 0
Quote
and decisions about which helmet is the uber helmet now fall directly on admins

Guess you have a big 'guidelines bport guide' to address all these case you should avoid. I see a lot of wasted time from builders otherwise, unless they stay conservative in their building.
40.0/111