Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 06-15-2002, 12:03 AM   #1
visko
Member
 
Join Date: May 2002
Posts: 98
visko is on a distinguished road
Send a message via ICQ to visko Send a message via AIM to visko
This is a concept that has probably been thrown around a lot by various people; a friend of mine and I have been playing with the concept for a while now, and said friend has actually developed the server-side code, or so he says. I have yet to actually see it.

I'd like to see if anyone is interested in building a fairly comprehensive template onto which coders can fill in the blanks and in so doing, allow their version of the PTP to check for all data that is normally stored in their pfiles. This kind of code could (theoretically) have some really cool ramifications on MUDding in general, and I personally would love to be able to build up characters on multiple MUDs, run inter-MUD clans, and so on.

Anyone interested in at least throwing a few ideas around, and looking at the ramifications of such a patch?

-Visko
visko is offline   Reply With Quote
Old 06-15-2002, 02:49 AM   #2
thelenian
Member
 
Join Date: Apr 2002
Posts: 122
thelenian is on a distinguished road
The problem with this is you would need to have some kind of secure shared secret on all MUDs that implement this protocol. If all transmitted in plaintext (which I strongly suspect), this would easily allow someone to spoof you with a man-in-the-middle, or simply impersonate a trusted server... if your PTP even has trusted server authentication of some sort.

I'm assuming that, by allowing intermud clans, you also give the PTP daemon the access permissions necessary to update the pfiles. If you do, someone could easily spoof all the MUDs on your network and completely wipe your pfiles... and there would be nothing you could do about it.

Something like this is a security nightmare, and probably not quite worth the hassle.

Don't get me wrong, stuff like this is a cool in concept, but it just happens to be very difficult to translate into reality. If you're really serious about going ahead on this project, I would suggest that you change it to PTP over SSH2, at which point much of the security concerns are eliminated. Resolving the race conditions that will arise, however, is the hard part.
thelenian is offline   Reply With Quote
Old 06-16-2002, 10:33 AM   #3
Kallian
New Member
 
Join Date: May 2002
Posts: 9
Kallian is on a distinguished road
This would best be implemented, imho, as an app on a centralized server whose only purpose was to store and transfer pfile information.

This seperate server would filter IPs and only allow participating muds to connect to it, as well as using a password for that individual mud, controlled by the individual mud admin and another password for the aforementioned server itself, which could be rotated on a regular basis if desired.

So overall, you'd need to be connecting from the IP of your mud, provide your mud's password, and provide the server password as well. This is relatively secure, triple-authentication scheme, that I would be comfortable using, if I was into this sort of thing.
Kallian is offline   Reply With Quote
Old 06-16-2002, 05:39 PM   #4
visko
Member
 
Join Date: May 2002
Posts: 98
visko is on a distinguished road
Send a message via ICQ to visko Send a message via AIM to visko
Developing some kind of encryption/unencryption code would be necessary of course, as would some coded safeguards to keep people from editing a pfile, sending it over to another MUD legitimately, and then taking the place over with insane weapons and armor.

As for transfer issues: a generalized PTP for all codebases was Meric's idea, but I take a much more conservative ideal. If we can just make the template and allow similar/same codebases to fill in the blanks for themselves, we can save a lot of trouble. Also, the way we originally talked about this problem, we would just have the code not implement anything it couldn't understand. If an object had an item_type that wasn't compatable with anything in the game, the object was stored but not loaded into memory. Keeps everything simple, and allows the players to jump from one MUD to another without worrying about whether a vampire works on a raceless world.

Obviously the concept isn't a snap to plan out or create, but once it's done and debugged, I think it has a lot of really nice potential for the community. This would take quite a bit of perserverence though, and I don't know if anyone's really up to something like this atm. Keep me posted, and keep the arguments coming. The more ground we can cover here, the less we have to worry about in practice

-Visko
visko is offline   Reply With Quote
Old 06-17-2002, 10:42 AM   #5
Cerise
Member
 
Join Date: May 2002
Posts: 34
Cerise is on a distinguished road
The embermud team is currently researching and developing something along those lines. I haven't taken a peek at it yet myself but I'm sure it sounds like great fun.
I'm not sure if they are giving any information about this new project but you can try looking at: http://www.embermud.org
Cant hurt to look.
Cerise is offline   Reply With Quote
Old 06-17-2002, 12:39 PM   #6
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

It sounds like an interesting idea, but it has a few problems that need to be overcome:

First, the stats that the playerfiles accumulate need to be compatible across all of the participating game systems.  I can foresee this happening with one mud that's simply distributed everywhere else and code changes work in tandem, but not really with seperate muds that may have entirely different ways of doing things.

Second, you'll need some mechanism for keeping the system fair.  I shouldn't be able to start a mud, mess with my pfile and make my player invincible, and then go to other muds and have an invincible character.  So there's got to be some sort of cabal of people that review the caliber of admins and games that are allowed to participate.  This problem might be mitigated if you used a central server to dictate starting stats for the various pfiles, and you could run checks on the pfile database to see if one player mysteriously jumped levels.

Third, the authentication for these systems must be secure.  But this is easy to accomplish by simply using an SSH tunnel, as thelenian noted.

Overall, I think the idea is excellent in terms of writing a "distributed" mud world.  Many more problems arise, but those are really questions of implementation that can be solved with enough effort.
Yui Unifex is offline   Reply With Quote
Old 06-17-2002, 12:48 PM   #7
Thoric
New Member
 
Join Date: Apr 2002
Location: Toronto, Ontario, Canada
Posts: 29
Thoric is on a distinguished road
Send a message via ICQ to Thoric
What is the purpose of this pfile transferring?

MUD pfiles aren't generally compatible unless you have the same area files.

A better solution (in my humble opinion) would be a mechanism to "switch" into a character on another MUD.

You would have a much easier time coming up with creative reasons for why you have a different body (and different eq) in different worlds than the administrative issues of trusting other MUDs, and pfile compatability problems.

It could work like this...

You have a world travel spell where upon casting it would put your character into a special location temporarily to protect it, and then put you in control of a character on the other MUD (via a new connection, or through some IMC-type interface system).
Thoric is offline   Reply With Quote
Old 06-17-2002, 05:18 PM   #8
visko
Member
 
Join Date: May 2002
Posts: 98
visko is on a distinguished road
Send a message via ICQ to visko Send a message via AIM to visko
I'm not sure exactly what you mean by "taking over another character in another world", Thoric, but to answer both you and Unifex...

The basic idea is that this protocol at the user level (the mud transferring the pfile) just sends it over to another mud, or sends it to a database processing server. I would personally prefer code in each MUD that interprets the different player files from various MUDs, but the end result is this:

A filter-like program that would be added to each time another MUD joins the group of MUDs running their version of the PTP checks which MUD the pfile is coming from. Based on a list of differences in stats, gold usage, hp, mana, move, etc. this program modifies those characteristics up or down. Anything in the pfile that can't be used is stored for later use on MUDs where it would apply. Skills that a player might automatically have on one MUD are not just given to the player; obviously, when you travel to a different land, you have to learn their customs and practices the hard way.

Pfiles could get pretty large after a while of travelling to different muds, but there are already patches out allowing pfiles to be gzipped for more efficient HD storage.

The other problem is security; problem admins, problem players with shell acces, etc. Quite frankly, there is no code I can think of that's going to stop a stupid admin from wreaking havoc on a system like this. At that level, the admins who are already in on their PTP group will have to make decisions based on the integrity of the people who are requesting admittance into their MUD system. This also has the effect, possibly, on having like codebases stick together, or at least have different code bases working on the same basic ideas so that they transfer to more MUDs.

The code itself is going to be complex, but it's fairly straightforward once the most obvious problems have been discussed and worked with. A lot of the things that are coming up in this thread are really good problems, and it took the two of us a few months to put all of these onto the table. However, the end result of the conversation was that this isn't just something you patch into your MUD and go with; this requires a bit of time and a good bit of energy to implement and maintain well. But once the code is out there, I think everything will be just a tad easier.

-Visko
visko is offline   Reply With Quote
Old 06-18-2002, 01:36 PM   #9
Thoric
New Member
 
Join Date: Apr 2002
Location: Toronto, Ontario, Canada
Posts: 29
Thoric is on a distinguished road
Send a message via ICQ to Thoric
What I meant by "taking over a character on another MUD" was that your character on another MUD would be based on information that MUD keeps on you, not the information your home-base MUD keeps on you (other than plain vanilla stats, race, class, etc).

When you "travel" to the other MUDs, the home-base MUD would only transfer vital information across, and not transfer your whole pfile.

Those other MUDs would do their own storage of your character. The home-base MUD shouldn't have to maintain stats on your character on other MUDs. This also protects those MUDs against home-base fudging with those stats.
Thoric is offline   Reply With Quote
Old 06-18-2002, 03:44 PM   #10
visko
Member
 
Join Date: May 2002
Posts: 98
visko is on a distinguished road
Send a message via ICQ to visko Send a message via AIM to visko
The only problem we came up with when we entertained that idea was storage space and character continuity. If a character gains really cool equipment or hp bonuses that would greatly aid him/her on another mud, but those things don't transfer, then the whole point of allowing characters to use multiple MUDs to progress becomes moot, and you have a completely RP-like reasoning for the thing; travelling to distant worlds to talk to other people.

The other problem, storage, is something that may or may not be an issue. With hard drives becoming very cheap and mudservers gaining GB worth of extra hard drive space now, storage quotas are going up, and with their rising, storage issues go away. Still, it would be nice to not have to worry about having the entire pbase of 15 different muds stored in your player directory.

-Visko
visko is offline   Reply With Quote
Old 06-18-2002, 04:43 PM   #11
Thoric
New Member
 
Join Date: Apr 2002
Location: Toronto, Ontario, Canada
Posts: 29
Thoric is on a distinguished road
Send a message via ICQ to Thoric
So you want experience gained on external MUDs to count on your home MUD and/or vice-versa?

I think there will always be problems (or potential for problems) with that situation.

How do you deal with the problem of naming?

What if the player name already exists on the external MUD?
Thoric is offline   Reply With Quote
Old 06-18-2002, 05:49 PM   #12
visko
Member
 
Join Date: May 2002
Posts: 98
visko is on a distinguished road
Send a message via ICQ to visko Send a message via AIM to visko
If the name already exists, it prompts you for an alternate name. That will be the one you use on that mud at that moment. Primary name stored in the file, secondary name used on that mud. If necessary, multiple alternate names can be used.

As far as experience and everything else porting to another mud, yes, it would. Any MUD that entered into the goup would have to accept that older players from other muyds would be logging onto their mud and causing havoc. If you're in a step, you're in all the way.

This isn't something that every mud is going to want, and it's more likely that newer muds will try this in an attempt to pool pbases. But although this does require more work on everyone's part, the end result could be 500-3k players all knowing and playing with each other in huge multiple worlds, building very large intricate clans and alliances.

The ends just have to justify the means, and the code aspect doesn't play a role there. At that point, it's just getting enough good admins together to make it worthwhile.

-Visko
visko is offline   Reply With Quote
Old 06-18-2002, 06:00 PM   #13
Dre
Member
 
Join Date: Jun 2002
Location: the Netherlands
Posts: 65
Dre is on a distinguished road
Heya,

Been watching this thread a while now. I've heard most of my doubts come forward already.
A new one just rised though. What would be the actual advantage of this code above combining those muds you speak off? They have to make code standards for them to work, so why not combine the muds. You also say it's mostly for new muds to pool together the player bases, why not build a new mud together then? Or incorporate one in the other.

Why do you want to make it an external tool?

Of course the idea of getting alot of people involved with each other is great. But what if they all come together on one mud that was intentionally made for 100 people max and now will have 300 people, the admin should improve his server etc just in case everyone wants to visit his mud to fight a battle, and then everyone moves over to another mud?

I'm sorry if I miss the point you are trying to make

Greetings Dre
Dre is offline   Reply With Quote
Old 06-19-2002, 01:02 PM   #14
mhc
Member
 
Join Date: May 2002
Location: Linköping, Sweden
Posts: 31
mhc is on a distinguished road
Anyone remember UnterMUD and UberMUD... ?
mhc is offline   Reply With Quote
Old 06-20-2002, 02:17 PM   #15
Teelf
Member
 
Join Date: Apr 2002
Location: Seattle
Posts: 32
Teelf is on a distinguished road
I think it would solve a lot of problems if some sort of "standardized" pfile was agreed upon.  The powers that be would decide on the variables to include and what they represent. They would set a scale for each.  Example:  They could include an unsigned int for experience and set its scale from 0 - 1,000,000.  

Each MUD could inteperet this standardized pfile anyway they choose.  Example:  10,000 exp from the standard is equivalent to 2,500 exp on my mud.

Each MUD would write a function to convert from and to the standard.  That way invidual MUDs could handle problems such as characters having the same name in any way they choose.

As a side note, MXP has the ability to invisibly relocate a user to another server automatically.  That might come in handy in conjuction with something like this.
Teelf is offline   Reply With Quote
Old 06-28-2002, 10:56 PM   #16
SoEnSo
New Member
 
Join Date: Apr 2002
Posts: 10
SoEnSo is on a distinguished road
Okay along time ago me an my buds were actualy talking about how todo this, it was when we first discovered IMC, this was waaay back, we figured if we developed a system like that, it would work..

But we never got into the building phase of it.

You see, the problem with it wouldn't be the player file, thats not a problem, the playerfiles would just store the information of the objects/clans whatever all in ur pfile, it would never really leave your system.

but the problem that would be, would mainly be the security, and the design of the hub... Then the compatability issues. As when your playing the other mud, you'd have to beable to access their commands, inwhich, you would most likely loose functionality to your own muds info. So for each mud online you'd have to write an interpreter for it, so that you'd beable to access the other muds data, and your own. This is what i'd like to call.. The pain.. As writing this would basicaly cause your mind to melt. Each new mud would require an intreter.

Now what about muds like.. Godwars, where you can't be killed unless your decapped.?? There again, more problems arise. Your player, meets on a Rom, with a player from a Godwars.. Now you gotta decap... Theres allot of compatability issues..

So once again, each mud thats online that has 1 simple difference, would require its own interpreter.


Anyways, we came to this conclusion at the wee hours of the morning. Its just my 2 cents, but fact is.. thats how it is.
SoEnSo is offline   Reply With Quote
Old 07-03-2002, 07:44 PM   #17
visko
Member
 
Join Date: May 2002
Posts: 98
visko is on a distinguished road
Send a message via ICQ to visko Send a message via AIM to visko
I disagree, SoEnSo...

The fact is, the player file just stores information, as you said. The thing is, that information will be interpreted differently by each MUD by default. So on a GW mud, a ROM player would have to be decapped to be killed, and on a ROM, a GW player would be killed without the need for decap. The characteristics of the player would be adjusted by the PTP server-side code to allow for fair interaction with the game in between MUDs, as Teelf was kind enough to point out, and after that the player is at the whim of the coder who built the place.

Yes there will be compatability issues with stats/skills, as people have already mentioned. Those will have to be dealt with as the protocol progresses, one issue at a time.

I may be missing something, but I don't understand why you believe what you do. Could you give me an example that would show more clearly what you are thinking?

Thanks,
-Visko
visko is offline   Reply With Quote
Old 07-06-2002, 10:28 PM   #18
Robbert
Member
 
Robbert's Avatar
 
Join Date: Apr 2002
Location: #### Paso, Tx
Posts: 89
Robbert is on a distinguished road
Send a message via ICQ to Robbert Send a message via AIM to Robbert
Interestingly enough, this same concept is what began the TCP/IP protocol - a method of communication interaction between systems which spoke their own internal languages.
Robbert is offline   Reply With Quote
Old 07-18-2002, 01:06 AM   #19
 
Posts: n/a
Quote:
Originally Posted by
At that level, the admins who are already in on their PTP group will have to make decisions based on the integrity of the people who are requesting admittance into their MUD system.  This also has the effect, possibly, on having like codebases stick together, or at least have different code bases working on the same basic ideas so that they transfer to more MUDs.
One wonders though, assuming that hypothetical level of cooperation between mud admins, why they don't just merge their efforts into a single game? ;-)
  Reply With Quote
Old 07-19-2002, 11:03 AM   #20
Loriel
Member
 
Join Date: May 2002
Posts: 49
Loriel is on a distinguished road
Ignoring all the technical and security problems involved in this proposal, I would like to question the benefits that it offers.

As I see it, any high level/experienced player on mud A can use this system to jump straight into mud B with a similar high level, without going through the process of "learning the mud".

This does not seem to me to be a good idea in general - having an ignorant high level player wandering around is going to be bad for both that player and the rest of the playerbase, who are going to be at risk from his mistakes, and jealous of his instant elevation to such high status.

It seems to me that it's only likely to work well if the muds involved are very similar in nature - not only in underlying codebase and player interface, but also in theme and quality of playerbase - which provides an incentive for 'copycat' muds rather than original thinking.
Loriel is offline   Reply With Quote
Reply


Thread Tools


PTP (pfile transfer protocol) - Similar Threads
Thread Thread Starter Forum Replies Last Post
Why not exploit the telnet protocol? erdos Advanced MUD Concepts 53 05-16-2012 12:00 AM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 06:18 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2014