Code I would like to see

What I know about coding and C could almost fill an entire thimble :slight_smile:
So I won’t say much. Just what I would like to see. I have played on a few different codebases, but only ran a server with Smaug and its derivatives. I would like to see a code snippet for smaug that would add a feature to deny logins in excess of a certain IP number. Like maybe you could put a line in the system data file that would specify an integer as the maximum number of connections allowed from a single IP.

Another thing I think would be useful across the board would be converter programs: a program that would read in an area file in one format and output it as a file in a different format. Such as SmaugFUSS to smaug, or from one type of system to another. It would be a separate command line linux program, not part of a mud server itself.

chown -fR us your/base*

Its pretty trivial code to only allow one connection per IP address… but why would you want it? If that’s your policy, then you can’t get families from the same house playing together, or people just hanging out and muddin’ from the same location.

I will not mention the names of MUDs I would complain about, but people abuse multiple character control to extreme excess. I have seen people who log on so many characters at the same time under one person with one client that you can’t even read the room name, because just the names of all their characters scroll the screen. On another mud, the notorious “8 packs” run about, stripping areas of their harvest with extreme computerized precision, and at times I doubt if there is even anybody at their keyboard. The people who do this use the word “solo” to mean one player, even if he is controlling 8 or more characters simultaneously, and understandably are reluctant to team with other players to run mobs. Why should they? When you ask them to form a party, they say “No, that mod is ‘soloable’.” This turns the game completely into something else: it is no longer a medieval (or whatever genre) adventure game: it is become a computer programming game, where only the players who have sophisticated MUD clients that allow them to control multiple characters simultaneously and run on scripts while they are AFK can ever have a chance to be successful in the game. This is not fair. I do not want that scenario.

On the other side of the coin, I would be shooting myself in the foot to limit IP connections to one when I don’t have any players yet! So it would be nice to be able to have an integer setting that could be changed as the playerbase changes.

I think it would be fair to set an IP limit at a small integer, say 3-4-5. That way single players could have their “porters”, healers, etc. follow their main character, or up to a few actual individuals in the same house could play together, but we would avoid the scenario of having one person control an army of characters simultaneously.

Well yeah, no point in complaining about some muds allowing that kind of multi-play. They allow it because they want client side programming to be a part of their game. For what its worth, it can be a lot of fun if that’s the game and its what the players are into.

If you don’t want to have that in your game, its certainly possible to limit the number of simultaneous connections from an address, but I wouldn’t recommend it as a way to prevent multi-playing. It would incorrectly limit common connection situations that aren’t multi-playing, like families and friends getting together at the same location to play.

I’d start with making an explicit conduct rule against client side controlled multi-playing. Stating up front to new players that multi-play isn’t welcome is going to discourage most of that behavior without writing a single line of code. Then you can move on to other code based solutions if you need to, like registered login accounts that manage multiple in-game characters and only let one join the game at a time.

One thing I would NOT do is give yourself a tune-able knob for limiting simultaneous same-source addresses. If you do that without an up-front policy toward multi-play, you’ll someday be tempted to limit the number of connections, and it’ll probably be on a day when that one multi-playing character does something to piss you off. You’ll make the change, and your game rules will be viewed and arbitrary and punitive.

I think its better to make a decision about multi-play up front (i.e. not allowed; limited to X simultaneous; or build the bot army of your dreams) and be consistent about it from the start. You can always work on server enforcement later if it becomes a problem.

Just throwing this out there… a player determined to play that many characters will likely use proxy servers, web clients, and other means to circumvent that limit. In this day and age, its borderline trivial to get around any sort of IP based restrictions.

That said, it might cut down on some elements of it, but you may be encouraging a system at that point where more technically inclined people with the know-how to get around it will have an advantage in the game over others who don’t.

I think a more elegant solution would be to place a limit on how many people can be in a group, or assist in a group, etc. That way, it doesn’t necessarily benefit someone to have a dozen characters logged on if only 4 or 5 of them can group up or offer support to one another.

As far as area conversion, that’d be nice and all, but that also would be a very case-by-case basis with respect to area formats, and ANY game that has made even trivial changes to their area formats wouldn’t find much use for such a bit of a code, so it would end up mostly just being useful for games that chose to adhere very close to stock in that regard.

1 Like

Thanks for your comments.

RahjIII, you are more optimistic than I; I’d like to think of families and friends getting together to play a game, that would be wonderful. But these days does that really happen much? I mean even when they are “gaming together” doesn’t that really mean they are on Discord, and their bodies are in separate locations? I would still like to have that “knob” though. Because one of the MUDs I was referring to has one. I don’t know if the limit is hard fixed or switchable, but that mud is limited to 8 IP logins, hence the term “8-pack”. I wrote to the guy who wrote the code asking if he would share it. He never wrote back.

One of my friends on said MUD was one of the people who would play 10 or 15 characters at a time. When they limited it to 8, he got all in a huff and left. Either he was not aware of how to get around the limit or he was too lazy to do it. Most people didn’t leave. So in that example, the policy worked.

One of the things I really enjoyed was when my Guild would do a “guild run” and get a large number of people together to go slay a big monster for desirable prizes. Limiting the size of a group might have put a damper on that. As it was, most people did not have more than 2-4 characters on and would log off the extras before a fight, because we knew that mobs would hand you your head on a platter if you tried to fight them in multi mode. Now that I am building my own areas an writing my own “mud programs” (scripts, not actual code) I know how to do that too. There is probably no solution that doesn’t have some problems, but that was what they did: set an IP limit plus programs to make mobs do extra damage to multiplayers, and it seemed to work. I just disagree that 8 is a reasonable number. I think that is too high. I have nothing against a little bit of multi-playing, just not to the extent that I have seen. Mainly what I don’t like is people who are not even there and have their groups running totally on automated scripts. There is at least one way to determine this and it has nothing to do with technology: it’s psychology. Just walk up to them and ask them. If they totally ignore you, well, what acts like a robot might be a robot.

At any rate, I’d like to see that IP limiting code to some number bigger than 1 and smaller than 8. There can’t be only one C programmer out there who has implemented such a thing. I wish I could, but I am barely able to stick snippets in the right place and type “make all”.

As far as area conversion, that’d be nice and all, but that also would be a very case-by-case basis with respect to area formats, and ANY game that has made even trivial changes to their area formats wouldn’t find much use for such a bit of a code, so it would end up mostly just being useful for games that chose to adhere very close to stock in that regard.

Too true… I’ve written converters in the past to migrate standard DIKU and our own MUD’s DIKU customisations to an XML format. The target format is extremely specific and wouldn’t have any usefulness to any other MUD.

Happens way more frequently on LO than single people multi-playing. We have a conduct rule in place against multi-play, and the MUD’s been around for so many years that our long-time players bring their kids around to play when they are old enough to type. We’ve also had a few batches of schoolkids playing in waves over the last five years, with all of them coming in from the same school computer lab during the day.

In addition to group size limiting code, you could also have several things in place that allow for an exception.

Depending on the circumstances, I could see area flags, room flags, and mob flags in place that allow for greater group size than the hard coded limit if you have specific mobs, areas, or even events that would normally call for a greater group size.

We also have a “server flag” (think things like double exp and the like) that lift restrictions on grouping, which would/could be another useful tool in having a greater control on when large groups would be permitted.

But I understand that you are looking for a plug and play sort of thing here. You have mentioned Smaug multiple times so I assume that’s the base you are working on, and spending a couple of minutes searching I couldn’t find anything.

Even if say I had such code implemented in my ROM MUD, it would still likely take a bit of technical coding knowledge to adapt it to work, as even cousin codebases have generally had enough changes made between them that there isn’t much that will easily plug right in.

@ Hades >
Yes, it is smaug. Specifically smaug-fuss 1.6, modified with snippets. On another mud using smaug, they went to considerable lengths to adjust the amount of experience you would get from leveling mobs based on IP. (For example if you have several players in a group and they are all IP1 they get bonus experience, or if they are Hobbits they get bonus experience.) How this was done, I do not know.

Yes, I realize being able to have a program do all the work of converting an area is most probably a pipe dream. I know it would be possible to do it smaugfuss to smaug, but of course I’d be going the other way. I have gone through areas by hand and “fixed” them for smaugfuss and my MUD. It is very tedious. I have gotten to the point where I think it is actually easier to just write my own, which is what I enjoy the most anyway. My next project is an insane asylum full of screaming lunatics and evil doctors. :slight_smile:

@ RahjIII >
You give me fuel for thought.
I am driven by my (bad) emotions over the unfair things I have seen people do in the past. But these were mainly geeks of 1990-2008. Before that, many if not most people played through PC’s or terminals logged into a mainframe. And we are all her operating on the premise - let us hope it is not just wishful thinking - that the text game will survive into the future. If it does, how do we know what form of connection the next generation will be using? When I was in school, using the computers to play a MUD was something you’d be punished for if you got caught. I’ll be thinking of your groups and pulling the sharper teeth out of my scripts that inflict pain and suffering on multiplayers. Your approach seems better: to make it a policy rather (or more than) something scripted into the game.

@ RhysChristiansen >

Take the following:

What I know about coding and C could almost fill an entire thimble

Combine it with the following:

Yes, I realize being able to have a program do all the work of converting an area is most probably a pipe dream.

Don’t sell yourself short. At the end of the endeavour you will find that a thimble is no longer sufficient to contain your knowledge of C. People who can code well didn’t get that way just incorporating other people’s snippets, they got that way by putting in time and hard work. Converting area files isn’t very hard, it’s just a little on the tedious side. 40% of the code already exists in the game engine when it loads the area files. You can leverage that to your advantage and then focus on the output format end of the problem.

Thank you, Sir.
I do believe if I could find the old C books from college and spent a month studying I could code some simple programs. My problem is that I am just too lazy. My passion is for building MUD rooms and areas.

Fair enough… I lean the other way :slight_smile:

If you have any intrest in writing code for my insignificant little smaug mud with 1 player,
let me know. :slight_smile: The standard distro (below level 61) building code is sadly broken, and
nobody seems to want to fix it. IP limits code is still something I would like to have. Raj says it is “easy”. I used to have a friend: Sokudon, the Pink God, who had a lot of wild and crazy ideas.
Oh, yes, I am dedicated to smaug. It is my favorite codebase.

Thanks for the offer but off an on I’ve been at our current mud for almost 18 years with 90% custom code and a MUD scripting engine superior to pretty much any other I’ve seen. Also, as I’ve mentioned in another post, we use a web-based area builder so that builders don’t need to worry about structural errors or trying to remember every flag available for an object or mobile (dropdown lists / checkboxes). Builder, Scripting

When I started 18 years ago one of the first things I did was convert our area format to XML for the versatility and flexibility that brought to the table. That meant writing a customised DIKU converter for the existing areas… I’d probably use JSON or YAML today since XML is a touch verbose, but it still gets the job done.

Lots of replies, maybe this was mentioned already.

It might be more practical to just flag individual IP’s with multiple connections, and talk it. Two individuals in an apartment would be flagged, but not blocked. I used to see high schoolers playing from the school library, that would be flagged but not blocked.

But you also run into an issue where some providers have one IP for thousands of subsribes, externally.

“Lazy” isn’t really a good reason, since snippets and suggestions can be found online. I wouldn’t bother along if you think you can’t do it.

You know, something I’ve never seen in a MUD that might be the most elegant, if very complicated to code, solution, would be to scale the mobs’ difficulty based on how many people are facing them. Sure, you’d also have to scale the rewards somewhat, otherwise people wouldn’t want to play in groups at all, but with a bit of consideration and tinkering I think it could be done.

I would like to see a code snippet for smaug that would add a feature to deny logins in excess of a certain IP number.

I could write up a Python script which would handle blocking IP addresses, and put in a C statement to run the script, which returns a True (to let the user log in) or False (to deny them).

What OS are you running SMAUG on? Python is very specific for defining paths, unless, of course, the file opened is in the same directory as the script.

Following, it is possible to embed Python in C/C++. A cross-platform script would be executed by the C procedure, called for each new connection with the parameter of a string containing the IP address in question, which would be passed to the Python script which would check the database and return True or False.

As long as it works - it works.
I am using as a host, so it is whatever version of linux
they are running. What bash command do you use to return the version?
I see they have a faq page and comments about compiling things, but I didn’t
see specifically what os version they are using. Apparently people have problems
with PennMUSH; but other then making one minor change to my Makefile I have had
no problems compiling my smaugfuss with gcc.

I wonder if the creators of smaugfuss and AFKmud are still out there somewhere?
Their websites have the “the lights are on but nobody’s home” syndrome.

Type down cat etc/*release*. That should show you all the information you need.

Here’s what it shall show you:
PRETTY_NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian etc.

more information (specifically the architecture) you could type arch and that’ll give you your processor’s spec, which in my case is armv7l.