Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
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
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, DotBot

Members: 0
Guests: 6
Stats
Files
Topics
Posts
Members
Newest Member
477
3,705
19,232
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » 'Prop' code.
Forum Rules | Mark all | Recent Posts

'Prop' code.
< Newer Topic :: Older Topic > Read on...

Pages:<< prev 1 next >>
Post is unread #1 Sep 15, 2003, 8:47 am
Go to the top of the page
Go to the bottom of the page

Xorith
The Null Value
GroupAFKMud Team
Posts254
JoinedFeb 23, 2003

Alright... I didn't want to go on too much about this, as it's something I've not seen done before. *grins*

Basically I had the idea while working with another type of MUD codebase... it was to provide something more real than just room descriptions to describe a room. While room descriptions would not be made useless, they'd not be as required.

Here's the idea.

Take an object. Strip out a lot of the bulk in the object struct. Leave it only with an ID number, name, short description, long description, and extra descriptions. Even have a few places for some values to be used in conjunction with programs they will also support. What you have is a stripped down object. When in a room, the prop's long desc appears like a line of text in the room description. However, it's not an object that you can get. You can examine it... perhaps even write a few commands to interact with it... and like I said I'd like programs on it. But it's there to add dimension to the game.

My biggest example is this: You have a forest area. If you were to make 20 differet types of trees, shrubs, and the like and have those props scattered about the area, it'd give enough to look at. Most players don't stop and read every detail while slugging it out with a creature. You could also then allow a prop - say a tree - allow for a player to use an axe, chop it, and change it's state. Now you have a stump and an object called a 'wooden log'.

Now here's the problem I'm having. I can write all this... but what would be more efficient? Just make a new object type to suit my needs, or make an entirely new structure? See, props can be universal. If you have a 'wildflower' prop, you could use it in more than just one area where you'd have wildflowers. Also I don't think a prop would need as much memory as an object as it won't need ALL of the properties an object needs... However, would it just take more memory to write a new structure?

Any input would be great. ;)

I've got big plans for this idea. I can do a lot with it... *grins* (Imagine props + sector types = 'auto' areas?)
       
Post is unread #2 Sep 22, 2003, 1:24 am
Go to the top of the page
Go to the bottom of the page

Snowleaf

GroupMembers
Posts12
JoinedApr 13, 2003

I like your idea. It would make locations more dynamic. I'm not sure how much overhead that would create though. Right now you enter a room, it dumps a description to you. With various props in a room, the game would need to keep track of what state each prop is in? Or maybe it would change a prop where a prop called "A large patch of wildflowers grows here" would turn into "a freshly picked wildflower" or generate x number of freshly picked wildflowers causing your "large patch of wildflowers" prop to turn into a "small patch of wildflowers" prop and finally into "a patch of stems where wildflowers once grew." prop.

From what it sounds like, creating an object type would be the easier method if you want people to interact with your props. Certain items with the prop item type flag will appear as part of the room description, where as if they didn't have the prop item type, they would appear as they appear now.

Would your props need some type of priority code so they are displayed in the order you wish? If you had a bunch of run down homes in a bad part of town you might have a run down home prop sitting in the room which displayed "This rundown home looks like all the others on this block. The living conditions aren't fit for livestock, much less people, but the poor make due with what they can get." followed by a pile of rags prop which would add, "A pile of rags lies in the corner, obvious gathered and piled to be someone's bed", followed by a table prop. "A makeshift table stands here, erected out of bits of scrap wood".

I would think you'd want some kinda priority so that your home prop would appear first, followed by the next prop, and so forth.

If that's the case, maybe a new structure would be require rather than altering the existing object structure.

Although now that i look at your post again I see you want to make the props room fixtures that people can't get, just look at. A new structure might be best. Then you can specify additional stuff like the ability to get a wildflower from a "patch of wildflowers" prop by telling it the number of available wildflowers to be picked, it's "picked wildflower" object VNUM,and the prop VNUM of it's next state of existance "large patch" to "small patch", "tree" prop to "stump prop" and creating LOG object in the room.
       
Post is unread #3 Sep 22, 2003, 5:00 am
Go to the top of the page
Go to the bottom of the page

Xorith
The Null Value
GroupAFKMud Team
Posts254
JoinedFeb 23, 2003

Actually, you brought a good point up.

If it were just an object type, and I used existing objects, then in AFKMud we'd have a nice bit of object value fields to use with them. One could be for priority, another for state tracking, and so on. This would also make it easier when it comes to putting programs in.

I want them to be fixtures... but I also want them to add more to the game. Take, for instance, a quest. Your quest is to go out and gather some wood for a fire. You'd walk out into the forest and there'd be a bunch of 'wood' props in the rooms. Using the keyword progs I've installed, the prop could interact with someone typing 'gather wood'. Perhaps if the branches are large, then it'd require the player to be carrying an axe or something, again using progs.

But you gave me the idea that I've been looking for on another issue. Player houses! I hadn't thought to use these in this way, but I was always curious how one could allow a player to buy a house and not have to worry about an immortal building it for them. Also, not giving them access to building commands which could be potentially dangerous. ;) If there were some prop objects that they could choose from for their rooms, then it'd describe them... they could customize it all, but it could still be 'controlled'.. so you wouldn't have someone with a description reading 'Yo. This is my home dog.' or something equally distasteful. ;)

As for the state of the props and looping through... I can see how current objects could be used for this as well. The note system uses extra descriptions on note objects to display the note's text. Something similar could be done with props. All you'd have to do is write a function that loops through the room, finds an object set 'TYPE_PROP', and then grab the objval that holds the current state of the prop. Then simply loop through the object's eds for _0_ or _1_, and so on. You could even do this to include examining it... I also note the nifty objval#($o) == ## ifcheck...

The only thing left to wonder about is the number of props one area could ever need, and wether or not to find a way to make props global to reduce redundant objects.

-- X
       
Pages:<< prev 1 next >>