Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Bing, DotBot

Members: 0
Guests: 12
Stats
Files
Topics
Posts
Members
Newest Member
481
3,740
19,388
628
PabloL3189
Today's Birthdays
There are no member birthdays today.
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 #21 Apr 23, 2009, 8:10 am
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Kayle said:

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.

Wait, no one understands what affects or virtual rooms do? I thought that what affects were supposed to do was pretty straightforward, in general.. and I was under the impression that virtual rooms were basically supposed to be rooms which only exist when a player actually enters one of them (what the MMOs call instanced) but were actually, due to flaws in the code, effectively only a delay in walking speeds presently to give the impression of greater distances. Have I misunderstood something?
       
Post is unread #22 Apr 23, 2009, 8:50 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I think Kayle was referring to implementation, not the general idea.

quixadhal said:

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?

Well, besides the fact that you probably don't want to endlessly spawn orcs :wink:
I don't think this is that hard. The second kind of reset is simply a mob-based reset. Instead of making resets specific to a zone or room, attach it to a mob and when it dies, eventually reset it. (Note that I don't necessarily mean literally attaching it to the mob in the implementation.)
The first kind of reset is easy, just spawn a new orc every reset if there are less than three in the room.
And the other one you mentioned, the wolf one, could be achieved similarly except that the context is the zone, not the room.
       
Post is unread #23 Apr 23, 2009, 10:03 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

The problem, again, is that OLC has to be able to create and manipulate all of these things, and IT doesn't know how you intend to use them. Attaching a reset to a mob might work OK for mobs that always have to exist (IE: named mobs, quest givers, etc)... but it adds another layer of complexity to the life of the builders who have to remember which kind of reset goes where, when?

Perhaps a more useful question is.... what do resets really do? Do they really "reset", or are they instead "events" which happen conditionally, and at regular intervals?

I would suggest that there are several kinds of things we lump together as resets which are used for very different purposes.

When a mob dies, in some zones, we may want to "reset" that mob at some point in the near future to allow players to farm it. In other zones, we may not want to reset individual mobs, but we want to reset the entire zone to an original state after a group of players has gone through it.

Other resets do maintenance type things... close doors, lock locks, etc. Still others don't actually "reset" anything at all, but serve to equip/arm/load items and gear into the environment as part of the reloading/respawning of the mobs themselves.

Finally, all resets serve the dual-function of also being initialization at boot time.

Let me further comment on a design issue. If I create an orc warrior, I'll probably put some effort into describing him, maybe writing a mprog script (or even a full C procedure), and certainly want to reuse him in as many ways as I can. If resets are used to equip the mob, and they're based on room/area, I can easily give one clan of orc a certain kind of gear, and another clan can get different stuff. If they're attached to the orc itself, all orcs will always get the same gear (or the same randomized set choices), unless I create seperate vnums that are carbon copies.

Ideally, I'd like to have "resets" which also let me adjust the level/stats/etc of the mobs... not just what gear loads onto them. It would be nice to really reuse that fully described orc in the low level area AND in the high level dungeon. It would also be nice to have resets that modify more complex things, such as relinking exits (not random doors), or changing properties at certain times of day/week/season. Again, that's not what they can do now, but keep the ideas in mind.

So.... does it make more sense to scatter resets around, so that some are with areas, some with rooms, some with individual items/mobs? Or to pool them all together in one big list? Should the equipping-type resets be treated (and stored) differently than the respawning-type ones? And where, in OLC, should these live? Do we need a seperate reset editor, or should redit show you both the room-specific resets AND the area-specific ones? Maybe it can only edit the room ones, but should still show you the others?

Until the design issues of resets are clearly spelled out (which they never really have been), I don't think any implementation is going to be clear or straightforward.
       
Post is unread #24 Apr 23, 2009, 10:44 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I think we're looking at this backwards. If we want to be able to do something, then design OLC to know how to do it. Don't design something based on the current OLC's flaws. If there are different types of resets, then fine, just implement different types and deal with it in OLC.
       
Post is unread #25 Apr 23, 2009, 3:32 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


DavidHaley said:

I think we're looking at this backwards. If we want to be able to do something, then design OLC to know how to do it. Don't design something based on the current OLC's flaws. If there are different types of resets, then fine, just implement different types and deal with it in OLC.


Agreed. If we're seriously starting to talk about another reset revision, we might as well do the same thing I'm doing with Affects. Design the new system from the ground up. Figure out what we want/need it to do. And then build everything else around that new idea. And if said new idea is compatible with the current implementation, revise it, if not. Rip it out and start from scratch.
       
Pages:<< prev 1, 2 next >>