Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Tahin]

Currently doors are structured thusly:

There is a mapping in /daemon/digging.c called "doors." This mapping consists of integer indices paired with mappings. The integer is the door's "serial number" and is used to refer to it externally. The mapping defines everything about the door, including its material, quality, decorations on both sides, and whether or not it is currently open.

The mapping that represents each room has a mapping within it call "doors." This mapping is made up of directions stored as strings paired with numbers, which refer back to the integer indices of the doors.

There is then a door object which is spawned for each door in every room and modified appropriately. These objects are the actual objects which you can look at and interact with. Currently they're just there for show.


The system's slightly overly-complex, but it's the simplest method I could think of short of doing some crazy stuff with virtual objects, and I don't want to get into that.

I'll get some more of this done on Thursday. Until then, you can use the AddDoorToRoom() and RemoveDoorFromRoom() functions in DIGGING_D to play around with the system.

Also, Zyll, if I could get you to write be a door object using your system, which stores two separate decoration arrays for each side and has the framework in place to convert to and from my system (note that RemoveDoorFromRoom() returns the door's mapping), that would be nice.

[Bluerobin]

Yup I'll get on it. 

[Tahin]

I should probably mention that I broke it and need to fix some things, so just stay out of that area for now.

[Bluerobin]

Oh good that actually makes me happy.  I was scared that I broke something.  I think I have a door that can be installed and a function to uninstall a door and they SHOULD work.  I just need to test and make sure.

[Tahin]

All right. As soon as I get my doors working properly without erroring, I'll see about implementing that. Good job.

[eerr]

Still working on names for the game.

What about :
Dwarf Colony MUD:(insert worldname here) or
MU-Dwarf Colony

[Tahin]

As far as names go, let's just stick with "Kar Unol: The Dwarf Fortress MUD" until something better comes along. If anyone has any ideas, I'm open to suggestions

In other news, I fixed the horrible errors I created with ic.c. Sorry about that. I was trying to prevent it from saving my doors along with the other objects in the room. Anyhow, I now know how to use sscanf(), which is incredibly useful. Next up: Get doors to work with various other things, and revamping the rooms so they acknowledge the presence of doors.

Question to players and staff: Should doors be targetable as "door" or simply the direction and its abbreviation? As it is now, doors can be looked at by typing something like "look north" or "look n" which is pretty standard, but would anyone be more comfortable with "look north door" being an option? My main concern is having clunky syntax like "uninstall north" which doesn't really make much sense. Allowing "uninstall north door" is at least a little nicer, but could create various issues like everything else seems to.

[eerr]

well, the parser could be updated to allow:
uninstall northern door, though
uninstall southwestern down door sounds a bit clunky, so it might require a hatch

[Tahin]

That wouldn't be a downward ladder, though, so a hatch wouldn't fit. It would be a ramp. Technically it would be southwestdownward door, actually, which despite being quite a mouthful isn't too bad. And it's not a matter of the parser. I just need to add the appropriate IDs to the door object.

Anyhow, right now I'm trying to figure out why everything loads fine as long as I'm not in the room, but as soon as I attempt to update the room with myself in it, or reboot the mud or anything else that reloads the room while I'm inside it, it only allows the first object to remain. The weird part is that I have it expressly set up to pass over players now when saving the objects, so it seriously should not be affecting it... Various weird stuff is happening with rooms with doors in them, as well. I'll look into this tomorrow.

[Tahin]

All right, fixed that issue. Now to get doors openable and so on.

[Bluerobin]

I agree with being able to refer to doors as "northern door" or "north door" and if we can abbreviate it to "swd door" it takes out the difficulty in typing.  Now if you want it to just SOUND better, I dunno what to tell you.

[Rockphed]

Did I read it right that currently the only way to open doors is to remove them?  That sounds incredibly dwarfy

[Tahin]

Nah, I've got opening working, now, though for a time that was semi-true. Currently I'm trying to get them to display their open/closed state properly when you look at them, and probably get their existence and perhaps state displaying in the room description. Then I'll see about getting Zyll's install stuff working properly alongside my door code.

Somewhere in there I should:

a) Figure out how to let one type "l n" rather than "l north" to look at a door to the north. For some reason it doesn't like single-character Ids. If anyone would like to shed some light on this subject, I'd be grateful.

b) Get the "knock" and "scratch" commands working with my doors. I love the idea of being able to scratch on a door and have someone in the other room hear it.

As I mentioned before, I managed to fix an issue where it was destroying the room's contents and then saving them by placing the save stuff in the heart_beat and just setting a variable called "save" on the room if I want to save the inventory in the next hear_beat. This means that the variable gets reset when the room gets destroyed, and thus there is no weird behavior. Might generate a tiny bit of lag if a bunch of players drop items in different rooms all within the same second, but I don't think that should be an issue.

[eerr]

digging is broken again, but this time it appears because of doors.(which shouldn't be hard to fix)

I'm assuming durability is the percent chance of damage after striking something.
my equation will use power/3+25%, placing adamantium in the indestructible range, steel weakening on 1/10 hits, and copper weakening on every 3/5 hits

aside from this, hammers can only be damaged when striking an object almost as hard.
swords, maces daggers from somewhat as hard(bone, most armour, wood),
bolts and tin silverware by anything with some resistance

infact, it might allow items to be made from almost any material, but suck if made from the wrong materials. (wooden hammer is "worse" than a wooden stick or club, use a tin sword and it cuts, but not very long)

some weapons constants
defaultpower=.5
defaultrange=?




for weapons-grade materials,
call setpower(percentage)

defaults for most materials
sharppower= 50%
bluntpower= 50%
armourpower=50%
boltpower=50%
crossbowpower=50%
crossbowrange=defaultrange (  a special defaultvalue for crossbows)


sharp 0-5 indicates increasing ability to make blades, (most materials, then obsidian, then  most metals)
traps 0-5 for trap components
hard 0-100 for blunt weapons ( 100 is a very good hammer, 0 is butter, and 50 is a rock)
density >0 , it determines damage of a blunt weapon
protective 0-5 for armour


boltsmade 0,10 (0 for false)

[Deon]

Oh I so follow you. I will definitely be a player and help anyhow I can .