04 Apr, 2009, Hades_Kane wrote in the 1st comment:
Votes: 0
I know some MUDs have their copyover or hotboot system setup to where over copyovers, the world will basically persist as it was prior to that.

The problem I'm having is that while we are still in development, I often code while people are on and that sometimes means frequent copyovers may be necessary. Most of the players don't tend to mind as our copyover warning automatically restores everyone, so its not normally a problem. The problem that I'm running into is that with a new crop of players, a lot of have taken to basically just spending hours farming money or items, and it didn't take long before they realized that if I'm doing a lot of copyovers, to run over to a particular area and basically camp one room away from an item they are waiting on the copyover to reload.

I'd really like to curb this, so I got to thinking that it might be in my best interest to implement something where mobs and objects don't automatically reload upon copyover recovery. I don't mind objects and mobs that are currently in game reloading, such as shops clearing out and whatnot, and I don't mind objects that exist on the ground being wiped when we copyover. I do have a "locker code" snippet implemented that will save what items over copyover and crashes (like corpses) when I might want that, but generally, I'm just trying to curb copyover meaning cheap repops for players. So, I would only like the mobs or objects that were currently existing to pop up again…

My question is, are there any snippets or tutorials out there currently that could help me with this?
04 Apr, 2009, Zeno wrote in the 2nd comment:
Votes: 0
Look over hotboot.c and hotboot.h in SmaugFUSS?
04 Apr, 2009, Lancsta wrote in the 3rd comment:
Votes: 0
I would almost add something like this

if (!fCopyOver)
{
/* Normal operation */
}
else
{
/* During a copyover */
}


Throw your area_update stuff around in that. Atleast during a copyover it wouldn't reset or update.
05 Apr, 2009, Grimble wrote in the 4th comment:
Votes: 0
Hades_Kane said:
I often code while people are on and that sometimes means frequent copyovers may be necessary.

I don't think you can blame your players for taking advantage of a situation you've brought on yourself. You should use copyover when you are done coding and testing a batch of changes (i.e., copyover should be a very rare event). If you fix your own behavior, then you won't have to deal with this "player problem".
05 Apr, 2009, Zeno wrote in the 5th comment:
Votes: 0
Grimble said:
Hades_Kane said:
I often code while people are on and that sometimes means frequent copyovers may be necessary.

I don't think you can blame your players for taking advantage of a situation you've brought on yourself. You should use copyover when you are done coding and testing a batch of changes (i.e., copyover should be a very rare event). If you fix your own behavior, then you won't have to deal with this "player problem".

Keyword being "testing". He is most likely testing these changes, thus requiring a copyover.
05 Apr, 2009, Grimble wrote in the 6th comment:
Votes: 0
Zeno said:
Grimble said:
Hades_Kane said:
I often code while people are on and that sometimes means frequent copyovers may be necessary.

I don't think you can blame your players for taking advantage of a situation you've brought on yourself. You should use copyover when you are done coding and testing a batch of changes (i.e., copyover should be a very rare event). If you fix your own behavior, then you won't have to deal with this "player problem".

Keyword being "testing". He is most likely testing these changes, thus requiring a copyover.

Then that's even worse. Don't test changes in the production server, good grief. The less stable of an environment you provide your players, the more likely you are to drive them off. You've got a situation where the players have learned to abuse something. If you put in code to prevent that, you'll alienate them. If you change your behavior instead, the situation itself goes away. It's up to you to decide how to handle it, but look at it from both sides before you do.
05 Apr, 2009, Zeno wrote in the 7th comment:
Votes: 0
Right, except MUDs are typically a hobby.

Back when I was on a MUD host and my MUD was in the development stage, I had 1 port to use. If I wanted another, I had to pay an extra $5 per month. I was not going to do that.
06 Apr, 2009, Zula wrote in the 8th comment:
Votes: 0
Which leads to the question, Do you have another port available perhaps? I made a copy of my mud code in a building folder and a running folder, then just copy your src folder back to the other folder once you've made changes tested them and then there is only 1 copyover for players
06 Apr, 2009, Grimble wrote in the 9th comment:
Votes: 0
Zeno said:
Right, except MUDs are typically a hobby.

Back when I was on a MUD host and my MUD was in the development stage, I had 1 port to use. If I wanted another, I had to pay an extra $5 per month. I was not going to do that.

If you care about the players on your MUD, then you run the MUD accordingly, hobby or otherwise. Also, there are several options that will enable a MUD to be developed and tested on a home PC, so additional hosting resources aren't needed.
06 Apr, 2009, Hades_Kane wrote in the 10th comment:
Votes: 0
I would "fix" my own behavior if there was indeed something broken or wrong with it.

I also find the implication absurd that it is somehow bad to add in code to prevent players from engaging in behavior you find counter productive to the intent of the game because it might alienate them. Why bother with rules at that point, if it might alienate someone?

For a game in development, for a game only listed here (which was only done as a means to help fill out the MUD listing here), for a game that advertises itself not open for the general public, in development, players are welcome for testing purposes only… I simply don't see an issue with running copyovers on the main port in order to test changes when the players who are connected know they are on a game that is in development, that isn't open, etc. They are allowed to play on the game because they are basically acting as play testers. What would be the point of having a test port, making a change, then asking people to log onto another port, test those changes, and repeat several times until I get something working the way I want, or to ask them to sit there on the test port while I do the exact same thing I'd otherwise be doing on the other? Really, for all intents and purposes, my main port is my test port. I think the assertion that I'm not running my game right or that I'm doing something "wrong" in such a situation is a bit ridiculous. I feel little sympathy for a player who comes into such a game and is annoyed, alienated, or otherwise bothered by active development and changes on a game that is still in development. I also have little sympathy for someone who is playing on a game in development as a play tester that is going to camp outside of a room to take advantage of a situation. Why should I have to go through the trouble of a test port when its the player abusing the situation? A little bit of code, and the problem is fixed. If in the course of testing or development, there arises a bug that we didn't see coming… should I just stand by and let them do it because "it's a situation I created" by developing and that adding in code to curb an abuse they "learned to abuse" would somehow be bad because it might alienate them? Certainly not. This situation isn't much different.

If the players don't like it, I encourage them to go find an open, more finished game to go play on. I'm not really concerned at this point whether or not I'm driving off players that expect an un-open game to act as if they are live. People know what they are coming into when they log on, and if they can't handle it, that's not really my problem.

Now, when we are getting ready to open and move out of the testing phase, I'll more than likely open up a coding port for this very purpose, but at this point, it's simply easier to go about as I have.

Off topic banter aside, if anyone else has any relevant advice to the coding issue I asked about, I'd appreciate any feedback. When I need someone to tell me how to run my game, I'll look for you then Grimble :p
06 Apr, 2009, Grimble wrote in the 11th comment:
Votes: 0
Hades_Kane said:
I also find the implication absurd that it is somehow bad to add in code to prevent players from engaging in behavior you find counter productive to the intent of the game because it might alienate them. Why bother with rules at that point, if it might alienate someone?

I never said not to plug in the holes that can be abused to gain some kind of advantage. What I'm trying to point out is that this specific issue can be addressed by a change in administrative policy. It's simply bad policy to develop and test on a port with active players. Now to address the defence you've given for this policy…

Hades_Kane said:
…for a game that advertises itself not open for the general public, in development, players are welcome for testing purposes only… I simply don't see an issue with running copyovers on the main port in order to test changes when the players who are connected know they are on a game that is in development, that isn't open, etc.

If the MUD is in a pre-production state, then why do you even care if your testers (not players) are using (not abusing) copyover side-effects?! If your testers (not players) have to adjust their expectations while the MUD is in pre-production, then it's reasonable for you to do the same.

Bottom line… I think you're seeing a problem that isn't really a problem, since it'll go away on its own once you open to the public (and copyover presumably becomes an extremely rare event).
06 Apr, 2009, Hades_Kane wrote in the 12th comment:
Votes: 0
Grimble said:
It's simply bad policy to develop and test on a port with active players.


I still don't see the correlation between bad policy and developing/testing on a port with active players that are there for the purposes of testing. Other than a player or two camping near something they are wanting to farm, there is generally little disruption in play from a copyover. Most don't seem to mind it, since I make an effort not to interrupt combat, description writing, etc. and our copyover warning generally does a restore as well. The game is in testing and development, so why shouldn't I test and develop on the main port?

Grimble said:
If the MUD is in a pre-production state, then why do you even care if your testers (not players) are using (not abusing) copyover side-effects?!

First off, it is abuse, so I don't know what your agenda is in trying to make it anything else. You called it abuse yourself earlier, and despite that, it's pointless trying to abuse (not use) semantics.

Secondly, why do I care? For the same reasons I would care if another player was harassing another, if another player was spamming, abusing bugs, botting, etc. Just because we're in testing and development doesn't mean that all sense of player conduct and good player behavior goes out of the window.

Grimble said:
If your testers (not players) have to adjust their expectations while the MUD is in pre-production, then it's reasonable for you to do the same.

This really goes back to the whole "its my sandbox" argument. As the Administration of the game, we decide what behavior and conduct we expect out of our players and if they can't follow those expectations, then they are free to go elsewhere. There's no reason to think that just because we aren't open and are still in testing and development, that I should lower my expectations for the level of conduct I expect out of the players on my game.

Grimble said:
Bottom line… I think you're seeing a problem that isn't really a problem, since it'll go away on its own once you open to the public (and copyover presumably becomes an extremely rare event).

I don't think a problem ceases to be a problem when it can only sometimes or occasionally be abused. Again, as the Administration, we setup the expectations and the rules for what is and isn't allowed in the game. If I wanted to have a copyover every 15 minutes for the rest of the game's life and I declared that no one is allowed to farm repopped items, that's my prerogative. That would be absurd, of course, but simply put, if I decide something is a problem on my game, then it is a problem. Regardless, I find it to be a problem now, and if I have it in my power to add in a little bit of code to solve that problem, who are you to chide me for it? No matter whether or not it would be a problem later on the road, that isn't what the issue is. I don't want players to be abusing the object repopping if I need to do a few copyovers in a row, and I'm here asking for advice on solving a code problem.
06 Apr, 2009, Skol wrote in the 13th comment:
Votes: 0
Hades, another things you could do…

On copyover have it 'home' the players. Or put in an area flag like 'no_copyover' that then makes any players IN that specific area go to their recall spot, THEN the copyover happens. That way you could do it on only those areas that are an issue.

The other thing would to see exactly what items they're waiting for, and see if the risk to reward on those items is simply too easy.

You could have it save player locations to a file, then reload that file and do the 'player in area' type reset when the mud boots as well (only mobs, not items on the ground/containers on the ground). But that would definitely be the most labor intensive way.

You might talk to your mud host and see if you can have a coder port though, I find it makes things way way easier. With Wolfpaw I have one with like 4 areas (so it's memory sig is way way low) and it doesn't run me anything over my normal playerport/builderport package.

I wouldn't mind approaching things from a builder-side either though, can you give more information about the things they're getting in on? Rotting keys, trapped chests, there are ways to keep the 'D00d' guys from having a cheat code sometimes heh.
06 Apr, 2009, Grimble wrote in the 14th comment:
Votes: 0
Let's take a step back, because this is going down the wrong path…

I thought your MUD was open and advised that development and testing should not be done on the production server. Problem solved. You corrected me on that, and pointed out that the MUD is in development.

I then noted that, for just this specific issue, it's not really an issue because it only exists while the MUD is in development. Again, problem solved.

I think you are having trouble deciding whether the MUD is in development and has a community of testers, or the MUD is open and has a community of players. In either case, code isn't required.
06 Apr, 2009, Zeno wrote in the 15th comment:
Votes: 0
Quote
I think you are having trouble deciding whether the MUD is in development and has a community of testers, or the MUD is open and has a community of players. In either case, code isn't required.

EoT has a community of player testers.

The best way you can test a game is to play it.
06 Apr, 2009, David Haley wrote in the 16th comment:
Votes: 0
Grimble said:
I think you are having trouble deciding whether the MUD is in development and has a community of testers, or the MUD is open and has a community of players. In either case, code isn't required.

Well, to be honest, I think you are having trouble applying a traditional software scheme to a domain that is driven by hobbyists – both from the development and playing perspective, really – and doesn't really fit those models.
06 Apr, 2009, Hades_Kane wrote in the 17th comment:
Votes: 0
A coding port, ultimately, won't be a big deal. It would honestly probably be more work to add in the copyover code to prevent objects and other things from automatically repopping than it would be to setup the other port, but I think that ultimately that would be a desirable thing to do anyhow just to minimize copyovers in general disrupting the game world, and considering that would solve this issue as well, it seems to be the best route to take all around. We've been discussing setting up another port for coding anyway, so we'll likely get around to that in the next few months, but yeah, I think a less disruptive copyover would be a good thing to have regardless.

As far as the items themselves, it tends to vary. A few players have set up scripts to run through areas grabbing loot out of chests which normally consist of things like potions or maybe some lower end gear. The particular item in question was a chunk of mythril that plays into another quest in a later area of the game. From a builder-side aspect, we have the capability to have a chest, on reset, run an oprog, and so we could have it load different items based on different conditions, or randomly altogether. We have some chests setup like that currently, as a matter of fact. I've also considered adding in a 'chest' item type that would have about 4 slots for vnum, along with another variable that would list conditions under which they would load, which might include all, random, rarity (which the first item in the list would be most common, the last considered the rarest). In fact, I've thought if I code that, it might make a handy little snippet.

But yeah, there's numerous solutions to curb this behavior, including a coding port, but I think the persisting world over copyover would be the most desirable immediate solution when other benefits from such a system is considered. I'll likely be taking a good long look at Smaug's hotboot code as Zeno suggested to see if I can convert that to work with ROM, and funny enough, the crashes I anticipate coming from such an effort will likely lead me to go ahead and create a coding port to work on this.
06 Apr, 2009, Grimble wrote in the 18th comment:
Votes: 0
Zeno said:
The best way you can test a game is to play it.

Thanks for stating the obvious, but the goals are different for testers and players. One is to find bugs, the other is to enjoy the end product of that effort.
06 Apr, 2009, David Haley wrote in the 19th comment:
Votes: 0
For hobbyist MUDs, it's rather unclear to me whether or not testers and players are disjoint sets as you seem to think they are. What you say makes lots of sense in other contexts, but just not this one I think.
06 Apr, 2009, Cratylus wrote in the 20th comment:
Votes: 0
omg run, nerdfight!

So like, I'm thinkin, yeah, test mud, who cares if the testers exploit reboots
I should be limiting to my separate dev port anyway?

But hey, if HK cares, he cares.

I think it's true that not all "enterprise solution" nomenclature and
best practices apply to muds. Agreed, granted, seconded, amended,
resolved, passed. I'm on board.

But if you're going to treat your testers like they're normal players
(trying to prevent them from "getting away with stuff" based on the
testness of the mud, for example) then for all practical purposes
you've got yerself a production mud, even if you don't call it that,
because that's how you're treating it.

I mean…unless I'm missing something, these folks are actually playing
the mud and enjoying themselves, right?

I used to ask this friend of mine what his problem was with getting
married. He'd be like "wtf i dont have a problem with it".

"Dude. You've lived with this girl for years. You guys bought a house.
You're never gonna split up. How are you not married, except that
you have a problem with making it legal?"

They got married like a year later, and now they have rings and legal stuff.
But it's the same house and same people.

Just my opinion.

-Crat
http://lpmuds.net
0.0/29