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, Yahoo!, Sogou

Members: 0
Guests: 5
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » Thoughts on limitations
Forum Rules | Mark all | Recent Posts

Thoughts on limitations
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 May 17, 2009, 10:03 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Was wondering if anyone had a good idea for dealing with a major limitation in muds caused of course by the way things are handled. If you had 2 portals in the room and 3 on hand only the 2 in the room and the 3rd on hand is usable for example. The limitation is more or less caused by the way things are checked etc...

get_obj_here checks in this order
objects in room
objects in inventory not being worn
objects in inventory being worn

get_obj_world checks in this order
get_obj_here
full list

Ostat for example uses get_obj_world and based on how things are you might not see everything like you want even if you used like 1.portal and 2.portal and only have 2 portals in the world and one was put inside the other using the fill command while one was on the ground. All it ever shows is the one actually in your inventory. I've thought about a lot of different ways to handle it, but in the end it comes down to always sacrificing convenience and performance for all of them being accessible. So any one have a good thought on handling it correctly while not sacrificing the ease of use?


Things I've considered so far:
Checking all objects for each thing and just limit them to the things your checking.
(loose performance and some convenience since the orders would be to where they were in the list as apposed to room > inventory etc...)
Creating a new hash for all objects using their name.
(Less of a performance loss as the prev but still same as far as convenience)
Keeping counts so all of them are accessable.
(Well now this one is a bit more complicated, but as it goes through the list it uses a counter for each part to see if there is a match which
is why if you do 2.portal and there are 2 on the ground the precede and make 2 in inventory inaccessible. You would then be able to do 1.portal (in room) 2.portal (in room) 3.portal (1.portal in inventory) 4.portal (2.portal in inventory) 5.portal (3.portal in inventory), But you still end up with alot of issues when trying to allow convenience with ostat/oset (checking rooms first and then inventory so they are setting the ones closer to them and most likely the one they are going to look at to see the change take affect) because when it turns around and uses the full list 6.portal (in object list) could be 2.portal in inventory so it is indeed a puzzling one on best way to handle it all.)

Thoughts or suggestions on it?
       
Post is unread #2 May 18, 2009, 11:24 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I would break it into two steps: one to list all things that match a string, listing a unique identifier next to each object (say, the pointer). Then, allow normal commands to identify objects by this unique identifier.

This way, you can exactly refer to an item, without having to worry about getting the wrong one based on weird things like list orders or other implementation details.
       
Post is unread #3 May 18, 2009, 3:15 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Well with lots of things it groups the display which would make that more of a pain to deal with when it comes to lots of things
       
Post is unread #4 May 18, 2009, 3:48 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Well, you have to define what the problem is first then. :wink: You can treat a group as one thing or as several depending on what you're trying to do. You then display one or several identifiers. I'm not terribly sure why groups are so special, because the normal behavior is to split one thing off when you manipulate the group, and the group as a whole counts as a single "thing" for the purpose of counting things.
       
Post is unread #5 May 18, 2009, 4:07 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Yes the actual grouping and ungrouping that might work my point is that in like look for example it not only lets it group stuff it actually takes the time to group the items by name also. You might have a few portals in the room with different contents in each one (so it doesn't actually group them) but in do_look it would just combine them for the display.
       
Post is unread #6 May 18, 2009, 4:24 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Well then make a command that doesn't group them for when you're doing this kind of imm work. Or don't group them in do_look if it matters. I guess I'm not seeing what the big problem here is. :thinking:
       
Post is unread #7 May 18, 2009, 4:39 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

FWIW, you will probably have to custom tailor things for each set of commands, since some things will want to show everything, and others won't. Just try to keep the interface consistent, so that things are always listed in the same order.

For example, if you had 5 apples, one in your inventory, one in your hand, two on the table in the room with you, and one more elsewhere, you'd want 3.apple to always refer to the same one. It might be that only immortals can access 5.apple, since it's out of scope for mortal commands, but it gets confusing if a player complains about a bug in 3.apple, but if an imm tries to look at it, it ends up being 4.apple for them.
       
Post is unread #8 May 18, 2009, 5:05 pm   Last edited May 18, 2009, 5:10 pm by Remcon
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Well see I had also thought of doing it something like that and that's how I ended up here and asking about all this.

The way everything is set up for it is different and sometimes you don't need to check all objects and other times you do but first you check local objects (in room, inventory, worn) and then the full list. The problem is that there is no real way to maintain how it is while actually making them all accessible at the same time. You could always toss through the full list but then you run into it taking alot longer then it should on a big mud it could be fairly laggy. Then you also would have to limit the output based on what you were looking for. Like why would I need to go through the full list if I just want to check inventory items. Yet, if I check inventory items then the counts globally would be different for everything. Am I the only one that has taken the time to actually test the bug and consider how to fix it.

It's about to the point of just saying forget this one, because I've yet to figure out a good solution that allows the problem to be fixed while still allowing it to only check what you want and show the actual stuff you want it to. Almost every way I think of, I can think of issues with. I could just leave it like it has been all these years.
       
Post is unread #9 May 19, 2009, 4:04 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Remcon said:

The way everything is set up for it is different and sometimes you don't need to check all objects and other times you do but first you check local objects (in room, inventory, worn) and then the full list. The problem is that there is no real way to maintain how it is while actually making them all accessible at the same time.


Why not? It just requires that every bit of code which searches for a matching object run through a single API. I would think it's very rare that you'd want to search for far away matches before local ones, so checking the local lists first is probably the right thing to do.

So, establish a fixed ordering that you always scan with. For the sake of argument, I'll toss out "equipped, inventory, room, zone, global". Now, the user types "info 7.apple". If he's holding an apple, that's 1. If he's got on in his inventory, that's 2. We're not up to 7 yet, so scan the next layer out until you either find the 7th, or have scanned the highest level list that command/player has access to.

Of course, to do that, you have to be sure you keep track of the ones you find so they can be skipped over in the next list, but just remembering their addresses is probably good enough. If the player was an immortal, he'd scan all the way out, whereas a regular player would probably stop at the room level.

There are a couple of weird gotchas I suppose.... If I'm hoding an apple and type "get 1.apple", it may be counter-intuitive that it would say "You're already holding that!", but that just means you probably should have just said "get apple" instead.
       
Post is unread #10 May 19, 2009, 7:28 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Why not? It just requires that every bit of code which searches for a matching object run through a single API. I would think it's very rare that you'd want to search for far away matches before local ones, so checking the local lists first is probably the right thing to do.

Yes, or if you have commands that you want to behave differently, just make those commands skip the local search and go straight to the global search. (This could be a boolean flag to the command, for example.)

Ideally commands would be contextualized. For example, "get apple" would never look at things in your direct inventory because that couldn't be what was meant. Similarly, "drop apple" wouldn't look at anything except for things you could actually drop. Perhaps the API could take flags for all the various categories (equipped, inventory, etc.) that all default to true, and you could turn off things if it made sense to do so.
       
Post is unread #11 May 19, 2009, 9:56 am
Go to the top of the page
Go to the bottom of the page

tphegley
Magician
GroupMembers
Posts176
JoinedMay 21, 2006

Something like:

get apple would be true for on ground whereas get apple duffel would default to inventory unless you get apple duffel ground

       
Post is unread #12 May 19, 2009, 10:05 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Well, sure, you can add further contextualization based on the command.
       
Pages:<< prev 1 next >>