I did not realize Bumped() was not built-in though...

But your last paragraph is more what i'm saying. You can put anything you want there, but it's not going to use it like it would a normal parameter, it's just a direct pointer.

What i mean is, if I have the proc Attack(mob/M), it won't let me use that on a turf or whatever because it's an invalid parameter.

But if I use Entered(mob/pc/M) it will still let mob/monster enter it AND it will still execute the contents as if it were mob/pc/M. The only thing I gain is a pointer to mob/pc.

I was having difficulties with this when I threw some monsters into my town to test combat. I had to rewrite every area that required a var check ( I just commented it out ) so that it wouldn't crash the proc and I could actually test it.

I noticed something else too, when my AI was wandering and the Entered() proc crashed ,the AI would stop right there with my exit message. Kind of odd eh?

"That's not what I said at all. I'm really not even sure what you're talking about."

How can you refute something you don't understand?

"Wrong. BYOND does no strict type checking until it actually goes to access the vars or procs. You could pass a turf to M and it would work fine until you tried to call M.Move(). This would result in a runtime error."

How could you pass M as a turf? It won't let me pick a turf, turf is an invalid parameter for the proc. Basically DM is a simplified version of C++, and C++ handles parameter variables at compile-time. It shouldn't even be a possibility to accomplish what you want to accomplish. If it's not an impossibility ( which I think it is ), then it should be because that's more efficient complier use. Faster executables :-)

"If you don't spawn out Move(), and one of the procs it calls ends up crashing, the whole "thread" will die. This is why it would stop for you."

I don't use Move() at all. I think it's odd that it would crash, but give me the appropriate "I Stopped moving though it's not really possible" message. Usually the entire proc terminates right then and there.

ShadowWolf wrote:

"That's not what I said at all. I'm really not even sure what you're talking about."

How can you refute something you don't understand?

What you said really had nothing to do with what I'd been talking about. I wasn't quite sure what you were saying, but it was clearly not related to what I'd been saying.

"Wrong. BYOND does no strict type checking until it actually goes to access the vars or procs. You could pass a turf to M and it would work fine until you tried to call M.Move(). This would result in a runtime error."

How could you pass M as a turf? It won't let me pick a turf, turf is an invalid parameter for the proc.

Are you confusing procs and verbs, perhaps? Verbs, when executed by a command from the client, do allow this kind of type checking on a simplistic level by letting you specify "as mob" or "as turf" or "as null|text". Although procs and verbs are basically the same in DM, the only time type is checked is on a limited basis and only when they're called a specific way.

Basically DM is a simplified version of C++, and C++ handles parameter variables at compile-time. It shouldn't even be a possibility to accomplish what you want to accomplish.

This isn't what I'd want to accomplish; I'm just saying that yes, it's possible to pass a turf to a proc that takes mob/M as its argument. DM doesn't do type checking in this regard.
Think of it this way: When calling a proc in C, you can explicitly cast a pointer of one type to another, even if the two pointers are completely different types. Sometimes you might do this to try to force-fit a call to a proc. In DM you don't have to do that, because there is no type checking of that kind.

DM is not a simplified version of C++; I'm not sure where you got the idea that it was. Its syntax has been called similar to Python. I'm not sure on that one myself, but I do know it has very little in common with C++ except for the fact that it's object-oriented. Java has a claim on being simplified C++, but DM doesn't.

If it's not an impossibility ( which I think it is ), then it should be because that's more efficient complier use. Faster executables :-)

.dmb files aren't executables--they're bytecode. DM is an interpreted language.
Basically speed is the reason that limited type casting is done in DM, which is why you might set an argument to mob/M in the first place. When you do that, you're making the assumption that M will never be a turf, so the compiler can go ahead and treat M like it's always a mob. If it finds out at runtime that it was wrong, you get a rude awakening.

"If you don't spawn out Move(), and one of the procs it calls ends up crashing, the whole "thread" will die. This is why it would stop for you."

I don't use Move() at all. I think it's odd that it would crash, but give me the appropriate "I Stopped moving though it's not really possible" message. Usually the entire proc terminates right then and there.

You might not be using Move() directly, but if you're using any of the built-in procs like walk(), Move() is being used regardless.

Lummox JR

ShadowWolf wrote:

Well, it's somewhat like Python, but not really. I mean, it's got some similarities, but it's more similar to the way C++ works. In fact, it's almost exactly the same as C++ only lacking a few different things. I think a good method of comparing it is a C++ & Python cross.

BYOND really isn't low-level enough to be compared remotely to C++. C++ is strictly typed, has a syntax that disregards whitespace, and compiles directly to an executable.

Java is not a simplified version of C++, it's supposed to be a replacement for C++.

Er... no, it never was intended as a replacement; that would be strictly impossible, since Java uses bytecode and has no capacity for low-level functions without relying on native-compiled code. Java was intended simply to be a cross-platform development language, with one goal among many being that it could be run in applet form within a Web browser.

Even saying it's a simplified version of C++ was a bit of an exaggeration on my part; it's safer to say that Java has more claim on that distinction than any other language.

Why are you bent on attacking anything I post?

It's not that I'm attacking everything you post, but that you're just posting so many thing that are outright wrong. You've said things about DM that are totally bogus and then wonder why your code doesn't work--it's because it is, in fact, wrong. And this comes from your assumption on what BYOND is based on or supposed to be like, when that assumption is at best only valid in a few places. BYOND simply isn't C++ or really much like it at all.
And then there's the above bit about Java.

I've had that discussion before with someone else about how it wasn't meant to "replace" anything. (Actually I think my point on that was argued by a different person.)

You've failed to really answer any questions, yet you commonly post things that suffer from ad hominem.

How did I not answer your questions? I at least answered the E.contents one, by explaining in depth why what you were trying to do wouldn't work.

Meanwhile, your assertion that this is all ad hominem would only make sense if I had something against you personally, or was only disagreeing with you because you're you. This is not the case. I have no problem with you; I'm simply correcting some misconceptions--apparently deeply ingrained--on your part. You've stated quite a few of them over a handful of threads, so if it seems like I'm on the attack, it's not because of you personally--it's because you're simply badly mistaken.

I'm sure there are others who can explain these same things, some doubtless with a lot more clarity than I could. I've observed that most of what you've said in error has stemmed from your particular understanding of how BYOND works, which seems to be nestled in the assumption that it's patterned off a language like C++. From my time working with DM, I can say with certainty that its passing resemblance to C++ is only that which it shares with other object-oriented languages, i.e. a superficial one. A lot of the reason for this is that BYOND is meant to be run under a particular interface, so it has functionality geared toward working with that interface, including the aforementioned verb settings.

Anyway, none of this is meant as an attack at all. You're simply looking at BYOND from a mistaken perspective. I know this because not only am I experienced with the language (and others), but I've seen other people on these forums with much more experience explain the same things to others--and I've of course had some of it explained to me. So there's no ill will here; it's just a few corrections.

Lummox JR

ShadowWolf wrote:

But Java was designed for a few purposes, one of them to be a replacement for the hairy syntax and poor design ( at the time ) of C++. C++ was often used on the Internet at first, because of the way it was designed, but things that just didn't work and over-complications within it made it very inappropriate. Also, C++ was too cumbersome to be used in extrodinarily small devices, which used ASM for a while, but now use Java.

Again, Java was never meant to replace C or C++; it's in many ways different in design. What it was meant to do was to extend the power of an object-oriented language to multiple platforms, using as little native code as possible.

I'm not sure what you mean when you say C++ was used "on the Internet"; it's been used for CGI applications of course, but then Perl is generally more common there. As far as mobile code for applets was concerned, there was nothing until Java came along; this was one of the purposes Java was meant to fill.

Other purposes were:
To maintain operability, Contrary to what you might read, you can make an OS in Java, it's been done once before. Not efficient, but possible. It only requires the same overhead as required for C++ and C.

Even if you compile the bytecode down to native code, there's more overhead than with C++ because of the way Java handles objects and pointers. If you don't compile it to native code, then your OS is being interpreted and it's slow. Plus, some native code will always be required for hardware drivers.

To finally destroy COBOL: People needed a language they could write really quick while at work to fix very small problems.

I hadn't heard this, but it sounds plausible. To my mind, though, COBOL was already on its death bed.

To become all-inclusive: Cross platform capabilities were REALLY important to SUN during it's development.

To grant usability: The ability for users to have code that was more bug-free than it's direct opposite, C++, was also a biggie.

These are probably most of the truth, although I don't think you can call C++ an "opposite". Java is essentially like C++ with single inheritance and bytecode.

If you wish to research further, go to http://java.sun.com
also, there are other sites which give non-corporate oritented information about java, which you will find if you search google for "Purpose of Java" and "Java Creation"

I think I might do that sometime; I'm definitely curious to know a little more about the language's origin.

Aside from that, I have to conceed that my knowledge of DM is not your's. I only assert that it's similar to C++ because it acts and works in a manner similar to that of C++. Now I understand it's not a compiled language or anything and all that, so there are DEFINITELY LARGE differences between it and C++, but a lot of the syntaxes are different. But all that is from my observations, and not from actual concrete proof.

I think it's similar to C++ only, as I said, in the fact that it's an object-oriented language. There are lots of those, though, and most bear a lot more resemblance to C++ than DM.
I actually haven't seen a language (in enough depth to know it, anyway) I can quickly compare to DM; it seems to defy description.

Lummox JR

I think you could probably throw Python in there too, there are a couple things that are similar with Python.

And Java doesn't require you to use Pointers & what-not for OS development. That's how it was done, which is a little by-passing, but you wouldn't use virtual class member functions when creating your OS in C++ either...