Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, Yahoo!, Majestic-12, Bing

Members: 0
Guests: 8
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
Today's Birthdays
Evoru (32)
Related Links
» SmaugMuds.org » General » Coding » Modernization Concerns
Forum Rules | Mark all | Recent Posts

Modernization Concerns
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2 next >>
Post is unread #1 Apr 20, 2009, 6:10 am
Go to the top of the page
Go to the bottom of the page

6Dragons
Fledgling
GroupMembers
Posts48
JoinedNov 23, 2008

I would fix resets to work properly before going onto modernizing other things.
I mean you guys might not notice how irritating it is when you have to copyover
to get them to work, or mobs dont repop, but if you are running a mud with
players, it makes smaugfuss less viable to want to use as a codebase. I am
thankful Remcon fixed it for me.
       
Post is unread #2 Apr 20, 2009, 8:09 am
Go to the top of the page
Go to the bottom of the page

dbna2
Sorcerer
GroupMembers
Posts600
JoinedDec 2, 2008

I have to agree.
       
Post is unread #3 Apr 20, 2009, 11:48 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Resets will get fixed when a solution that doesn't mean intertwining with 10 thousand other things is offered up. I think Kayle and I made it pretty clear we didn't want such an invasive fix to the problem. There *HAS* to be a better solution. Unless it can be demonstrated beyond a shadow of a doubt that Remcon's fix is the only way.

And on that subject, if you intend on waiting for myself or Kayle to come up with it, you may be waiting a long ass time as we both have other things on our agendas as well.
       
Post is unread #4 Apr 20, 2009, 2:02 pm   Last edited Apr 20, 2009, 2:05 pm by 6Dragons
Go to the top of the page
Go to the bottom of the page

6Dragons
Fledgling
GroupMembers
Posts48
JoinedNov 23, 2008

I just brought it up, because FUSS = Fixed up smaug, I didn't think
starting new things like affects that could bring more bugs was what
FUSS was about. I mean resets is a key function for a mud, not
something like trap code that may or may not get used. Heh, starting
new stuff without fixing old stuff sounds like something I would do to
my own code, and I have but didn't think you guys did that. I am
happy with the fix I have from Remcon, it works beautifully. It doesn't
matter to me if you guys fix it or not, just thought for the new admin it
would be something you would want to aim at to attract people to using
smaugfuss. Sorry for bringing it up if you guys don't want to bother
with it, it is your project, I'm just mainly a lurker.
       
Post is unread #5 Apr 20, 2009, 3:20 pm   Last edited Apr 20, 2009, 3:34 pm by Kayle
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

It isn't that we don't want it fixed. It's that we don't want to make resets look the way affects do now. Affects are a convoluted mess of intertwined spaghetti. I won't let Resets become that. Traps are a bug. They need fixed. They don't get used now, because they're hard to use. The goal of the trap overhaul is to make them work, and make them easier for builders/players to use. The goal of the Affects(Effects) overhaul is to make them easier for beginning admins to use, and expand the functionality of the system, while removing the convoluted mess of intertwined spaghetti. Traps and Affects/Effects have drawn an active interest. Resets don't draw a lot of attention for whatever reason.

As an aside, I'm getting ready to swap out a Server in a 4-Star Hotel while the hotel is still open and running. Plus, I have my own base to finish writing. There's currently a list of things to do for the FUSS Project, and I work on them as I have time. Sorry if I can't just churn something out overnight for you.


[Edit:] Also, split this off from the Affects since it has nothing to do with the actual overhaul itself.
       
Post is unread #6 Apr 20, 2009, 11:38 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I don't understand why resets are so complicated. Maybe I should take a look some day and see how things are set up. I'm sure there's a relatively simple and clean solution especially if we have access to C++ data structures to cut down on data structure noise. I can add that onto my 2 bazillion item todo list... :tongue:
       
Post is unread #7 Apr 21, 2009, 9:08 am
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

What's the problem exactly? I'm using FUSS and the new reset system on a live MUD which has players every single day and there isn't a problem.
       
Post is unread #8 Apr 21, 2009, 9:30 am   Last edited Apr 21, 2009, 9:40 am by 6Dragons
Go to the top of the page
Go to the bottom of the page

6Dragons
Fledgling
GroupMembers
Posts48
JoinedNov 23, 2008

This is the problem

http://www.smaugmuds.org/index.php?a=topic&t=4012&p=17319

You have to kickstart resets with copyover when you install new areas.
Now the above does fix the reset issues so that everything resets correctly.
It however doesn't make it work to well when deleting resets and lots of other
crazy things. Don't have to if you use that fix. But to do Remcon's fix you
have to change hotboot.c to LOP hotboot. Remcon could explain why, I
don't remember what he said. Zeno if you don't have those problems let
me know.
       
Post is unread #9 Apr 21, 2009, 12:15 pm
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

I have to hotboot when I install an area anyway, since I add it to area.lst. So I haven't seen a problem.
       
Post is unread #10 Apr 21, 2009, 1:42 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

So wait. Let me get this straight. The problem isn't that resets don't work, it's that they don't work when switching the area from prototype to fully installed? If that's the case then it sure seems like there should be a much easier way to resolve this issue since I know for a fact that the actual reset system does work since it ran on Alsherok for quite some time before becoming a Smaug snippet even.
       
Post is unread #11 Apr 21, 2009, 1:52 pm   Last edited Apr 21, 2009, 2:06 pm by 6Dragons
Go to the top of the page
Go to the bottom of the page

6Dragons
Fledgling
GroupMembers
Posts48
JoinedNov 23, 2008

Never mind then, if you fail to read all this then I guess you don't miss
what you don't know about.

http://www.smaugmuds.org/index.php?a=topic&t=4012&p=17319
       
Post is unread #12 Apr 21, 2009, 2:13 pm
Go to the top of the page
Go to the bottom of the page

kiro_san
Fledgling
GroupMembers
Posts23
JoinedJan 27, 2007

Wasn't the actually problem one of mobs spawning? And not spawning, and resets getting messed up after you delete one or something along those lines?
       
Post is unread #13 Apr 21, 2009, 2:28 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

6Dragons said:

You have to kickstart resets with copyover when you install new areas.

6Dragons said:

Never mind then, if you fail to read all this then I guess you don't miss what you don't know about.


Or, perhaps you could stop throwing in confusing information that completely changes the meaning of what you're communicating. Then maybe I won't have to "miss what I don't know about". How exactly that works when I specifically called out Remcon's fix for touching so much stuff is beyond me.
       
Post is unread #14 Apr 21, 2009, 7:13 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

DavidHaley said:

I don't understand why resets are so complicated. Maybe I should take a look some day and see how things are set up. I'm sure there's a relatively simple and clean solution especially if we have access to C++ data structures to cut down on data structure noise. I can add that onto my 2 bazillion item todo list... :tongue:


In the original DikuMUD, resets were zone based. Each reset entry in the zone file had the zone it belonged to, a time value for how often to reset, a mode (disabled, no-players, always), and the command itself.

Like all DikuMUD elements that had variable arguments, the programmers didn't know about parsers or dynamic allocation, so they share the same arcane v1, v2, etc... that objects/resets/etc have.

The way resets were used to setup complex environments worked fine before the advent of OLC, as one hand edited the files and tested them to be sure they worked properly, tweaking as needed. OLC had to automate the process, and frankly did a poor job in many cases.

Here's a short example from my game:
#34
Deserted Mansion~
3499 11 1
... snip ...
M 0 3437 1 3455 * aggresive sentinel rat in nest
M 0 3435 1 3436 * giant bat
O 0 9212 1 3422 * puts candles in various spots
O 0 9212 1 3427
O 0 9212 1 3438
O 0 9212 1 3442
O 0 9211 1 3455 * rats nest
P 1 9213 1 9211 * gold in nest
S


Zone "Deserted Mansion"[#34] spans rooms (#3231,#3499)
It resets every 11 minutes, if no players are present
There are 29 Commands defined:
...snip...
[ 21] Load Mobile "A giant rat"[#3437] to "Rat lair"[#3455]
[ 22] Load Mobile "The giant bat"[#3435] to " The Attic"[#3436]
[ 23] Load Object "a tallow candle"[#9212] to " Sitting Room"[#3422]
[ 24] Load Object "a tallow candle"[#9212] to " The Dining Room"[#3427]
[ 25] Load Object "a tallow candle"[#9212] to " Bedroom"[#3438]
[ 26] Load Object "a tallow candle"[#9212] to " The Den"[#3442]
[ 27] Load Object "A large rat's nest"[#9211] to "Rat lair"[#3455]
[ 28] Put Object "A pile of gold coins"[#9213] into Object "A large rat's nest"[#9211]


Pretty straightforward, load a bunch of mobs and a handful of objects, in the last room, load a pile of gold coins and stuff it into the rat's nest object, but only if the rat's nest actually reset. The zone itself resets fairly often, but only if there are no players present, which means they can't camp it for gold.

Also of interest:

M 0 3009 1 10 * umbro the warrior w/equip
E 1 3029 10 5
E 1 3030 10 6
E 1 3031 10 8
G 1 3025 100
P 1 3012 3 3025
P 1 3012 3 3025
P 1 3003 6 3025
E 1 3032 10 16
L 1 3010 1 * kiele the ranger w/equip


[ 13] Load Mobile "Umbro the Warrior"[#3009] to "Beginnings..."[#10]
[ 14] Object "a chainmail vest"[#3029] is Worn on Body by Mobile "Umbro the Warrior"[#3009]
[ 15] Object "a horned helm"[#3030] is Worn on Head by Mobile "Umbro the Warrior"[#3009]
[ 16] Object "a pair of metal plated boots"[#3031] is Worn on Feet by Mobile "Umbro the Warrior"[#3009]
[ 17] Give Object "a leather sack"[#3025] to Mobile "Umbro the Warrior"[#3009]
[ 18] Put Object "a stick of salami"[#3012] into Object "a leather sack"[#3025]
[ 19] Put Object "a stick of salami"[#3012] into Object "a leather sack"[#3025]
[ 20] Put Object "a bottle"[#3003] into Object "a leather sack"[#3025]
[ 21] Object "a longsword"[#3032] is Held by Mobile "Umbro the Warrior"[#3009]
[ 22] Load Mobile "Kiele the Tracker"[#3010] to "Beginnings..."[#10], led by Mobile "Umbro the Warrior"[#3009]


This shows loading and equipping a group, The first mob is loaded, gear is equipped and loot is put into containers, then the next group member is loaded and set to follow the leader.
----
Ok. This works fine. When OLC was added to later codebases, whomever wrote the OLC code had problems trying to figure out how to rewrite the resets to handle items being equipped or nested inside each other. I don't know why, it doesn't matter. Point is, it was broken. One of the things SmaugFUSS did was to rewrite the reset system and move away from the more complex zone-based resets to room-based ones. This allowed resets to be merged into the room editor, making their management simpler, and only losing a small bit of functionality for zone-wide events.

One of the issues though, is that if you have a room-based reset that loads 3 orcs, and they wander out of the room.... you have to keep track of the fact that they are still present and not load 3 more. That's because you don't *really* mean to have 3 orcs in the room... you want 3 orcs in the zone, but you have to load them in SOME room, since there are no area-based resets to say "load an orc into a random room in this zone".

I don't think it's so much an issue of data structures, as much as an issue of the concept of a reset wanting to live with the thing it applies to, but also having to know about the environment it is being applied in. OLC is the monkey wrench here.
       
Post is unread #15 Apr 21, 2009, 9:29 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Quix hit the nail on the head.

The code for resets may not be a complex beast, but getting them to work perfectly with all the ways to work with them is where headache comes from.

You not only need something easy to work with from an OLC perspective, but you also need something that's easy to modify by hand in the shell should it come to that.
       
Post is unread #16 Apr 22, 2009, 8:10 am
Go to the top of the page
Go to the bottom of the page

kiro_san
Fledgling
GroupMembers
Posts23
JoinedJan 27, 2007

So reset can't just check the mob list to see how many of type vnum exist? Or would assigning say a serial number to each generated mob make things easier to check up on? ... Sounds kinda hefty...
       
Post is unread #17 Apr 22, 2009, 12:16 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I wasn't asking for a description of how they work in general, I know that already :tongue: What I meant is that I don't understand why it has to be so complicated. Everybody's talking about them like some horrible thing intertwined everywhere; I'm just not sure why that has to be that way.
       
Post is unread #18 Apr 22, 2009, 5:07 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Another ungodly beast that no one wants to touch are Virtual Rooms. But unlike Resets, which are simple enough, virtual rooms are by no means a simple beast. And like affects, no one really understands exactly what all they do. Or how to fix them.
       
Post is unread #19 Apr 22, 2009, 11:35 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

kiro_san said:

So reset can't just check the mob list to see how many of type vnum exist? Or would assigning say a serial number to each generated mob make things easier to check up on? ... Sounds kinda hefty...


The trick is... how do you distinguish (easily) between a reset which wants 3 orc guards to be in room 3001 at all times, and a reset that wants 3 orc guards to be roaming the hallway, and they happen to load into room 3001 when they start up? Sure, you can use two different mobs and have one set to guardian (no wandering), but that's side-stepping the issue.

Also, in my game, I have resets that load wolves into the grasslands if (and only if) there are fewer than 12 wolves in the zone. I have multiple resets that do this, because I don't want them to always start in the same room, but I also don't want to pick a totaly random room.

If you use room-based resets, to avoid this issue you have to make each reset scan the entire mob list and count matches by vnum and zone. If you use area-based resets, that one is easy, but making sure a particular room always has N mobs requires you to check current location of each mob in the list. Either way, you're going to end up being somewhat invasive.

Serials are probably only helpful if your game is persistent, although they would make it simpler for wizards to manipulate a particular instance of a thing. IE: Instead of the old "at 37.orc look" game, you could just have your mwhere command list vnum, location, and ID, which coudl be used via "at 37F3#orc look" or something.
       
Post is unread #20 Apr 23, 2009, 6:42 am
Go to the top of the page
Go to the bottom of the page

kiro_san
Fledgling
GroupMembers
Posts23
JoinedJan 27, 2007

Thats what i meant with the serial number. Each zone could have a certain number of serials/ID nums to assign to resets. When/if the reset spawn something it has the same serial, and it would check it against all the mobs or items in the zone(depending on what type of reset it is) to see if the proper number exists. A problem with that would be the number of serials ID's available. But that would be pretty easy to solve.
       
Pages:<< prev 1, 2 next >>