Re: Map Errors

Page: 1 2
Aug 20 2008, 5:10 am
In response to GhostAnime
GhostAnime wrote:
Superbike32 wrote:
First, you shouldn't need to do this in first place.

If you want an event to happen to an /area or /turf when their bumped, you need to do that (though too bad there's no built-in Bumped()... but it's not hard to do anyways as Nao showed.

This is the hierarchy of the paths used in BYOND:
> Datum
> /icon
> /image
> // some other / I may be forgetting
> 
> /atom
>    /area
>    /turf
> 
>    /movable   //  A special group which have specific procedures that other /atom and its' decedents do not, such as Move() and Bump()
>       /mob
>       /obj

Since /mob and /obj are under /atom/movable, these three have special procedures only available to those in and under /atom/movable, such as Move() and Bump().

As such, /turf cannot use Bump() at all.

As a side note: obj != objects, obj == /obj

Second, ive never seen this code before, and don't know what all it will change.

It's pretty straight forward:

A.Bump(B) -- > A bumps into B.

So if you look at what was done in Bump(), it calls Bumped() on B with the argument of A - thus:

A.Bumped(B) -- > A is bumped BY B. This is what you want.

Third, what all types will it make transfer over to Bump() and will it error if there is no Bump() code on that item???

See the first section of my reply.

Stuff like this is very important to know.

I thought it was touched on by the DM Guide... or it may have been a tutorial... meh.

i know when i bump into things, just saying a bumped into b or b into a, that is just useless..it means nothing to me at all to see that, a code xample, and some more information would however, be useful.
Aug 20 2008, 5:18 am
In response to Superbike32
Superbike32 wrote:
your post is useless, only types of /obj will then work with bump() or with /turf as well, if /turf as well, would it call it twice with this code here, or work as usual?

No. No. No. Scrap everything you've said related to this through the entire thread, because its pretty much all wrong.

Theres no 'only types of /obj will work' or anything about turfs or anything.

Any dense /atom/movable will call Bump() when it hits any dense /atom/ by default. With the code supplied, any /atom/ will call Bumped(atom/movable/bumped_by) when something bumps into it. There are no special cases here, there are no 'situations' or something only working a certain way. This is how the above works.

Heres your testcode:
atom/proc/Bumped(atom/movable/source)
    world << "[src].Bumped([source])"

atom/movable/Bump(atom/target)
    world << "[src].Bump([target])"
    if(istype(target)) target.Bumped(src)
Aug 20 2008, 5:21 am
In response to Alathon
The istype check is unneeded as it will only call Bump if it bumped into an atom in the first place, and there's not much else to bump into anyways.
Aug 20 2008, 5:22 am
In response to Naokohiro
Naokohiro wrote:
The istype check is unneeded as it will only call Bump if it bumped into an atom in the first place, and there's not much else to bump into anyways.

Its precautionary in the case of manual calls to Bump(). Its always good practice to provide 'safe' code.
Aug 20 2008, 5:24 am
In response to Alathon
Calling Bump manually will probably cause errors if given a bad argument anyways...
Aug 20 2008, 6:22 am
In response to GhostAnime
I think you forgot the /savefile datum; nothing big though, since most people wouldn't use it like a /icon or /image.
Aug 20 2008, 6:48 am
In response to Jeff8500
im just saying, if i have a dense object, and then bump into it, will it error if no bump code is on the object, since i dont want it to do anything, or do i have to code it in a little more for it not to give runetime errors?
Aug 20 2008, 7:11 am
In response to Superbike32
In the snippet Naokohiro showed you he declared Bumped() for all atoms. Even if you don't override them to make a special event no runtime should occur because of it.
Aug 20 2008, 11:00 am
In response to Superbike32
Look here.
Aug 20 2008, 7:41 pm
In response to Lummox JR
Lummox JR wrote:
Superbike32 wrote:
Wait, are you seriously suggesting we do a major revamp of BYOND's core and change the way one of the basic functions works, breaking literally thousands of games, so you don't have to go to the trouble of writing a three-line Bumped() proc as a workaround?

No, thats why this is here, to stop you from having to do that.. Also, its not the lines more, because it does a lot more than that when u bump into the object, but anyways, its hard to maintain the code if you have literally 100 objects you want to use using the bump() code, and then all under the same section, making it much harder to find the piece of code that needs to be changed, unlike if it was under the object itself.

I take it you're not familiar with the technique I just mentioned. A common and well-known workaround for the fact that you only get an "A bumped B" message is to write a proc called Bumped(), which is called by Bump() as a default action, that says "B bumped A". It's literally three lines. This lets you break out the "X was bumped" behavior in as much detail as you like without having a monster Bump() proc.

Lummox JR

Isn't the Bumped() proc described in the DM guide?
Superbike32 have you even read the DM guide?
I may be a beginner, but what Lummox JR just said *edit: "what everyone said"* is pretty straight forward. I really don't see the point of this long winded topic of arguing against people who know what they're talking about. Out of the replies you've given on different topics, I've pretty much learned what not to do, so I guess thanks for that.
Page: 1 2