I know we can already program in a work around, but I feel that, something as simple as this could really just be included and save everyone a little hassle.
We know that sometimes you need to override Bump() or Enter() because it won't work the way we want it to. Why not simply have a built in procedure that allows us to automatically check if something bumped something else (AKA a mob 'Bummped' into a spike) or if something stepped on to or into something (AKA a mob 'stepped' on a block.
Honestly I don't see why this hasn't been added in already.
ID:260836
 Nov 24 2009, 5:11 am
|
|
Ham Doctor wrote:
I know we can already program in a work around, but I feel that, something as simple as this could really just be included and save everyone a little hassle. Simply put, we can't put in convenience functions for every little thing or the language would be overloaded with them. As these are not actually relevant to every project, and easy to define yourself, there isn't really any need to make them official parts of the language. Lummox JR | |
The thing that I enjoyed about the most with BYOND, that really first got me started, was the fact that it was sometimes more often easier to understand and learn then some other languages. I feel that with the the easier the programming package, the more users we get.
If you look online, if you check the forums, there are a lot, a lot of users who have run into asking how to do this before, because it confuses them when things like Entered() don't work the way it is described in the help file. I really wish that we could have more of a community oriented opinion then having a single developer for the software saying no. It's fairly disappointing. So what if it's a 'convenience' function, we have other conveniences in the BYOND programming platform, that didn't seem to make them any less important. For the record, I know how to do this, I didn't need any help with it. This is just something I thought off off on the side while messing with BYOND today. I feel it's a convenience function that makes sense and should be added. | |
Ham Doctor wrote:
I really wish that we could have more of a community oriented opinion then having a single developer for the software saying no. It's fairly disappointing. So what if it's a 'convenience' function, we have other conveniences in the BYOND programming platform, that didn't seem to make them any less important. I think it would pretty cool to have a yay and nay system for the feature requests. So what if it's a 'convenience' function, we have other conveniences in the BYOND programming platform, that didn't seem to make them any less important. Agreed, but those conveniences probably saved more then two lines... If you look online, if you check the forums, there are a lot, a lot of users who have run into asking how to do this before, because it confuses them when things like Entered() don't work the way it is described in the help file. In fact there's a few right now. | |
Ham Doctor wrote:
If you look online, if you check the forums, there are a lot, a lot of users who have run into asking how to do this before, because it confuses them when things like Entered() don't work the way it is described in the help file. Entered() actually works exactly the way it's described in the help file. Where they run into trouble is when they get confused about which atom is being entered. There is no way they should infer the incorrect behavior from the Reference, which means they're either not reading it or not quite following it. I think the answer to this is better tutorials; writing more procs for them to get confused about won't really help them. I really wish that we could have more of a community oriented opinion then having a single developer for the software saying no. It's fairly disappointing. So what if it's a 'convenience' function, we have other conveniences in the BYOND programming platform, that didn't seem to make them any less important. I've asked for convenience functions in the past and even implemented a few myself. Mostly those were to fill a niche that either was not filled by something else (like ispath()), or was not easy to accomplish in soft code. In all cases Tom is the final arbiter of what is added and what is not. His rule of thumb on such things is that usually if a feature fills a significant need and cannot be accomplished another way (or requires huge workarounds to do it), then it's sensible to add. Otherwise not so much. Bumped() fills neither of these criteria. There is only a need for it in certain games. We not only have significant coverage of the concept in tutorials, but also a library that handles it as well. It is also trivial to implement with three lines of code. atom/proc/Bumped(atom/movable/A) I would be remiss not to also point out that adding this at this point would also require old code which defines its own Bumped() procs to be reworked--at least some of it. SteppedOn() is moot, since Entered() already fills that exact same need. More useful would be something that would trigger other objects on the same turf, like traps, but that too is not only easy to implement, but exists in a library. Perhaps that's actually what you meant, although the proc name does not necessarily imply this. But in each of these cases, we have something that 1) does not apply to all games, 2) is easy to implement and in most cases already implemented, 3) is easier to address with a simple tutorial and perhaps some Reference enhancements, and 4) is likely to introduce problems in existing code. The need is not great, and the effort involved in a workaround is infinitesimal (and provides greater control for the developer). Mind you I'm not saying no to any of this as such; but as-is, it doesn't merit changing the language. Usually this kind of thing is much better handled with a tutorial or library, and both have already been done (though more tutorials couldn't hurt). The IconProcs library for instance exists for this same reason; it does things that are useful but don't warrant changing our icon code since they can be done more easily through the library. That was created to address the needs of users who have trouble using alpha transparency easily. Lummox JR | |
Ham Doctor wrote:
If you look online, if you check the forums, there are a lot, a lot of users who have run into asking how to do this before Which isn't so meaningful. That's the same for many, many other aspects of the language, and the reason they are being asked over and over are common knowledge: aspiring developers are too lazy to put in time and effort to learn programming and use the available resources, instead resorting to bad approaches such as tweaking a ripped source, copy-pasting in code from random sources, and continually milking the forum for answers to every little question or problem they have (help vampirism), while being too lazy (or unthoughtful) to try the forum search first, of course. because it confuses them when things like Entered() don't work the way it is described in the help file. Except they do. Guess you're confused yourself. At any case, there's really no helping that newbies who skipped actually learning the fundamentals of the language tend not to understand a reference entry, especially when they tend to skim the entry or even stop reading after the first line or two (this has been unfortunately proven by experience). I really wish that we could have more of a community oriented opinion The community is free to suggest features and express their opinions of them. then having a single developer for the software saying no. This isn't an open source project. You can't make decisions for the developers. So what if it's a 'convenience' function, we have other conveniences in the BYOND programming platform, that didn't seem to make them any less important. You seem to miss that that only further empowers the notion of not adding more to prevent the language from being clogged with them (also known as 'feature creep'/'creeping featurism' or 'featuritis'). Also, the nature of the features are relevant to the decision of whether they should be added or not. Some are more likely to be used often than others, etc. I feel it's a convenience function that makes sense and should be added. If you feel convenience feature X should be made available for the sake of population Y (e.g. newbies), you can always write up a quick #define/proc that implements it and publish it as a library, or perhaps on the Snippets Database, to achieve a similar effect. | |
As for Bumped(), there's no real point in adding it in as a permanent function due to the fact that it could easily be called like so.
Cheers.