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, DotBot

Members: 0
Guests: 5
Stats
Files
Topics
Posts
Members
Newest Member
481
3,733
19,360
618
Micheal64X
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » Overland with Archery
Forum Rules | Mark all | Recent Posts

Overland with Archery
< Newer Topic :: Older Topic > evil!!!

Pages:<< prev 1 next >>
Post is unread #1 Jan 31, 2004, 8:03 am
Go to the top of the page
Go to the bottom of the page

DjNiVeK

GroupMembers
Posts12
JoinedDec 14, 2003

Alright, I tried alot already, and it didn't work, so maybe you guys know...
When standing on an overland map, and do the following:

throw east
You throw A small shuriken east.
Your pierce -tears- someone!


You -wound- someone!
You -=injure=- someone!
You dodge someone's attack.
*continuing fight*


You start fighting someone who isn't in the same room as you (well, techiqually, he/she is). I need to get rid of this really annoying bug, since you can hit people on the other side of the map with it. Next to that, you can't target a person since you can't see the person. It's getting really annoying
Help plz?

-edit-
I changed the bowfire a bit. Throw is like 'fire' from the archery snippet
       
Post is unread #2 Feb 1, 2004, 10:27 pm
Go to the top of the page
Go to the bottom of the page

Xorith
The Null Value
GroupAFKMud Team
Posts254
JoinedFeb 23, 2003

This is a bit tricky.

You could go through your combat and skills and throw in map checks if you'd like. The Overland isn't perfect..

There's really no 'easy' way to do this. I thought for a moment to add a line in get_char_room, but I'm not sure how much that'd screw up.

Sam? Thoughts?

-- X
       
Post is unread #3 Feb 2, 2004, 3:27 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Ugh, yes. The overland system isn't the best, but for now it's all we have

Hrm. I'm not sure exactly how to solve something like this. Archery on the overland should be possible - but only within perhaps a few coordinate spaces of the target ( suspend your thoughts on distance for a moment ). So making it check for being right on target wouldn't really work. It would need to involve some sort of radius check, but you'd still run into the "someone" problem until they could close distance. Which leads to another thing - tracking on the overland
       
Post is unread #4 Feb 3, 2004, 5:59 am
Go to the top of the page
Go to the bottom of the page

DjNiVeK

GroupMembers
Posts12
JoinedDec 14, 2003

I was thinking of making something like a constant distance on the map you can fire/throw stuff to. And when it 'hits' the victim, check his/her/its x and y and compare it with the x and y of the one who fired/threw it. If it's in the radius, let it hit, but the part when it starts the fight should be left out.
       
Post is unread #5 Feb 3, 2004, 2:41 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Hmmmm, I've been thinking about the overland map system here.

It occurs to me that many of the problems with communication, combat, etc stem from the fact that each continent is really just a single room. All the rest of the code is setup to use a "room" as a container which limits scope of visibility to the various routines. I know a good amount of them have already been special-cased, but it might be simpler to work in the other direction.

Namely, allow virtual rooms for the overland maps, where each player/npc gets their own room. As they move about the map, it updates the coordinates of the room, and checks for overlap, moving the player/mob into the overlapping room if it happens -- thus allowing the usual code rules to apply for random encounters/messages/etc.

Benefits:

Less special-case code... say/whisper/kill/give/get/put/drop/etc... all work as usual. Movement has to be special cased, and if you drop an object on the gound it may be "gone" as soon as you move (unless you want to buffer it for N rooms of movement).

Room generation is possible, thus allowing text-based descriptions that work off the map. I've seen the results of such code, and it's no worse than "You are in a grassland, you see grass in all directions with a tall mountain range far to the north!". It would certainly give brief/verbose some real usefulness!

Tracking/archery and similar skills would be possible based on looping through all the pc/npcs on the overland and doing coordinate comparisons.

Pitfalls:

Bit of a rewrite, and much of the current special-case stuff would have to go away.

Radius effects (tracking/archery/earthquake/shout) would HAVE to loop through pc/npcs to work properly.

Would need an overland bit for the room flags (already there?)

Teleport effects would need an extra step... if the chosen destination is overland, randomize a coordinate too. If the source is overland, what percent chance to still be on overland? else people would almost always zip to a normal room based on the law of averages.


Dunno... I certainly don't have any code ready-to-go for this, but what does everyone else think of the idea?

Samson would have a better idea of how the cost of such a conversion would weigh in against the cost of adding more special case code as it is now!
       
Post is unread #6 Feb 10, 2004, 10:39 am
Go to the top of the page
Go to the bottom of the page

DjNiVeK

GroupMembers
Posts12
JoinedDec 14, 2003

It looks nice, and sounds pretty good, but I wouldn't know where to start to be honest...
       
Post is unread #7 Feb 10, 2004, 4:10 pm
Go to the top of the page
Go to the bottom of the page

cynshard

GroupMembers
Posts95
JoinedNov 19, 2003

I'd sure like to know if this overland conversion is/is not being considered by Samson ( Or anyone else ). Currently I'm planning a 'locomotive' module and a change of that magnitude would have major impact on the basic design. Not to mention, how much simpler it would be to do many things.
*waits*
       
Post is unread #8 Feb 10, 2004, 7:21 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Samson has no plans to be making such sweeping alterations to the overland code. For he has little time to devote to such large amounts of work these days. The idea sounds nifty and all, but the whole system would need to be redone to handle carrying around your own room with you and I'd rather not just have the overland be devoid otherwise because you moved and the room is no longer available.
       
Post is unread #9 Feb 12, 2004, 2:06 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Heh, not quite what I meant, but yes, it would be a pretty sizeable chunk of work.

Another variation on this doesn't tie the rooms to players at all. but rather that rooms would only exist as players (or mobs) wandered through them. The system I had started to work on ages ago used a timer that got decremented whenever the game driver went through its tick update code, and reset whenever a person/mob touched the room. If it got to zero, the room was flushed (along with any objects that might be there).

I used an alternate exit flag to signify that this exit wandered into virtual space, and a hash table to track coordinates to rooms mappings, so when going to generate another room, if it already existed, you'd just use that one. If the room existed and wasn't flagged virtual, the exit was a normal one.

The advantage to this idea is that rooms DO linger for a bit, so if you drop things (breadcrumb trail?) they'll still be there for some time. To control memory use, you might adjust the time downward as the number of virtual rooms grows, so someone running all over the grid will not have rooms lingering very long. Since the descriptions should be quasi-static (based on terrain, I'd assume), the only thing lost will be items dropped in the room.

I'll tuck this one in filing cabinet for when I have a buttload of time again, but I wanted to toss the idea out in case someone else was more ambitious than myself.
       
Pages:<< prev 1 next >>