ID:142111
 
Superbike32 wrote:
I have to change the type of the object to use Bump() as it doesn't call Bump() on objects, even if the object is dense...so I move it over to turf.

Bump isn't called on the object that is blocking, but is called on the object that is bumping into a dense object. Also, I believe you are using the word object incorrectly as obj does not mean object. (Since Bump can very well be called on an obj if that obj Bumps into something.)

For your suggestion, I think it's utterly pointless, especially with the reasoning you gave, but I'll wait to see other people's opinions.
if an obj bumps into another obj - exactly, im talking about mob into obj.

anyways, i sometimes move lots of things at once over to another type, like 15 or so, changing the object type of all 15, across the span of like 12 maps, it can be quite annoying.
In response to Superbike32 (#1)
Superbike32 wrote:
if an obj bumps into another obj - exactly, im talking about mob into obj.

In which case mob/Bump() is called. In Bump(), src is the moving item and the argument is the obstacle. As long as the mob and obj are both dense, you'll get a bump.

Lummox JR
In response to Lummox JR (#2)
Lummox JR wrote:
Superbike32 wrote:
if an obj bumps into another obj - exactly, im talking about mob into obj.

In which case mob/Bump() is called. In Bump(), src is the moving item and the argument is the obstacle. As long as the mob and obj are both dense, you'll get a bump.

Lummox JR

yes, but thats like the other programming languages i came from, and is why i moved away from it...the bump() should always be called under the object that was bumped into, not the one that bumps into the object, to stop it from being a long list of things under one thing, to allow for better maintaining of the code.
In response to Superbike32 (#1)
Superbike32 wrote:
if an obj bumps into another obj - exactly, im talking about mob into obj.

obj does not mean object. A mob is not an obj. Bumping into an obj will call Bump on the mob or obj that bumped into that obj, not on that obj.
You are not a master of coding, so stop pretending to be so, and take advice when it is given to you by people who know what they're talking about.
Also, I believe if this programming mistake is fixed, the entire reason behind why you need this feature is gone.

EDIT: (I'm also repeating stuff that Lummox said on accident.)
In response to Superbike32 (#3)
Superbike32 wrote:
yes, but thats like the other programming languages i came from, and is why i moved away from it...the bump() should always be called under the object that was bumped into, not the one that bumps into the object, to stop it from being a long list of things under one thing, to allow for better maintaining of the code.

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?

Lummox JR
In response to Naokohiro (#4)
Naokohiro wrote:
Superbike32 wrote:
if an obj bumps into another obj - exactly, im talking about mob into obj.

obj does not mean object. A mob is not an obj. Bumping into an obj will call Bump on the mob or obj that bumped into that obj, not on that obj.
You are not a master of coding, so stop pretending to be so, and take advice when it is given to you by people who know what they're talking about.
Also, I believe if this programming mistake is fixed, the entire reason behind why you need this feature is gone.

if say i have 100 objects i want to handle bump for from when a mob bumps into it, then its all under the mob's bump code, and not under the item, then i have to search through all of those 100 objects bump code to find the one im looking for. It would be much easier if it was under that object, because then i find it under the map editor, double click to take me to the code for that item, and edit it right there, instead of going around finding it.

if it was already handled on the object that the mob bumped into, like it really should be, then there would be no problem here.

I already know that you can do it that other way, but it makes a lot harder to find that code that you need to change through all those 100 objects.
In response to Lummox JR (#5)
Lummox JR wrote:
Superbike32 wrote:
yes, but thats like the other programming languages i came from, and is why i moved away from it...the bump() should always be called under the object that was bumped into, not the one that bumps into the object, to stop it from being a long list of things under one thing, to allow for better maintaining of the code.

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?

Lummox JR

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.

Thats why I change them, so I can more easily find them when I need to change them, instead of looking up under the 100 objects under my mob's bump() code.

This proposal is here INSTEAD of the major re-vamp breaking most or all games.
In response to Superbike32 (#6)
Superbike32 wrote:
if say i have 100 objects i want to handle bump for from when a mob bumps into it, then its all under the mob's bump code, and not under the item, then i have to search through all of those 100 objects bump code to find the one im looking for. It would be much easier if it was under that object, because then i find it under the map editor, double click to take me to the code for that item, and edit it right there, instead of going around finding it.

What you're explaining here is a failure to utilize proper programming logic. Please take that on good faith - If you want a more detailed explanation, then I suggest you post in Design Philosophy. Suffice to say that you're simply going about things in the wrong manner.
In response to Superbike32 (#7)
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
In response to Superbike32 (#6)
atom/proc/Bumped(atom/movable/O)

atom/movable/Bump(atom/Obstacle)
..()
Obstacle.Bumped(src)

There, now use the Bumped proc instead of the Bump proc. Problem solved.
In response to Naokohiro (#10)
Well, im not gonna use this way anyways, and its much easier the way i did it already, just to move it to a turf.

Which anyways, has downsides anyways, because, not all of them take up the full tile.
In response to Naokohiro (#10)
You forgot the parent procedure (..()) under Bump() >_> Think about the people who must overwrite Bump() :P
In response to GhostAnime (#12)
Haha. Sorry... I've never used that parent procedure myself...

EDIT: Fixed.
In response to Superbike32 (#11)
You're not going to use something simply because you didn't come up with it yourself?
That's a smart way to go about things...
Tell us when your game with zero efficiency and robustness comes out, so we can be sure to never accidentally fall into it.
In response to Naokohiro (#14)
Naokohiro wrote:
You're not going to use something simply because you didn't come up with it yourself?
That's a smart way to go about things...
Tell us when your game with zero efficiency and robustness comes out, so we can be sure to never accidentally fall into it.

I don't want to use it because of a few reasons.

First, you shouldn't need to do this in first place.

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

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

Stuff like this is very important to know.
In response to Superbike32 (#15)
Superbike32 wrote:
First, you shouldn't need to do this in first place.

Thats a horrible reason for any feature request for a language, unless there is a compelling reason to. As in something that is either completely impossible, ineffecient or an obvious lack in the general syntax of things.

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

That code doesn't 'change' anything. It defines a procedure that is called whenever a movable atom bumps into something.

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

Bump() is a built-in procedure, defined for /atom/movable and its children. If the procedure wasn't defined, you'd get a compiler error telling you so. The code does exactly what it says it does:

When Bump() is called (See the reference for when that happens), the /atom/ the caller bumps into has its Bumped() procedure called. Which is handily defined right above that piece of code.

The code more or less does this (pseudo code/flow):

Event -> A /mob bumps into an /obj

1) /mob.Bump() is called
2) /mob.Bump() calls /obj.Bumped(/mob)

Theres nothing to do with different types, 'transfers' or whatever else it is you're saying that I can't quite understand.

Stuff like this is very important to know.

You seem to be lacking some general concepts as far as DM goes in general - Stuff like what I just explained is pretty visible from going through things a few times. Once again, the issue is with your knowledge (or lack thereof) of the language and not the language itself.
In response to Superbike32 (#15)
Superbike32 wrote:
I don't want to use it because of a few reasons.

First, you shouldn't need to do this in first place.

Well, with that attitude, you shouldn't need to program anything to have a game in the first place.

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

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

Stuff like this is very important to know.

No, it will work fine as long as you simply use the Bumped proc, but perhaps you should learn more about coding first, if you can't understand a simple code like that.
In response to Superbike32 (#15)
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.
In response to Alathon (#16)
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?

Do you have to put each individual item there for it not to error, or if i have a dense object i dont want to do anything with when bumped into it do i still have to put any code there to make it stop from erroring?

And one code example would be nice as well.
Page: 1 2