Oct 26 2008, 10:32 am
In response to Tiberath
|
|
Guy Hendricks
 |
I just had an idea to remove that possibility. First, how about the code not be precompiled, but something to meets the same end, such as encrypted. Second, make a panel of highly trusted members that have a decrypter. They look at it, decide if it's safe, then publish it (in encrypted form) if it is. Technically, anyone could implement this feature the way I've described it in this one post, since all you would need to do is encryption/decryption in the IDE, and you can now program your own IDEs. Of course, you'd have to know about encryption, decryption, and how to make a decent IDE, too.
|
Guy Hendricks wrote:
I just had an idea to remove that possibility. First, how about the code not be precompiled, but something to meets the same end, such as encrypted. Second, make a panel of highly trusted members that have a decrypter. They look at it, decide if it's safe, then publish it (in encrypted form) if it is. Technically, anyone could implement this feature the way I've described it in this one post, since all you would need to do is encryption/decryption in the IDE, and you can now program your own IDEs. Of course, you'd have to know about encryption, decryption, and how to make a decent IDE, too. This idea is far too taxing on BYOND itself. None of the help/hub/forum moderators are paid, it's all volunteer work. And I doubt any of them would like having to review everything like this that came their way. -- I just don't see a relevant need to hide source. If you're going to do something like this, you might as well just give the user the source. I personally, will never include any source that I can't review for myself, regardless of which trusted BYOND official has declared it safe. Because if I can't see it, how can I integrate it into my game? How do I know it'll work with the systems I have in place? IMO, this falls under "The Code" logic. No one specific method will work in every instance, for every person. | |
Guy Hendricks wrote:
What do you guys say? Think it's a good idea? An encryption scheme like you suggested isn't going to work out, because people will always figure out a way to decrypt whatever is encrypted and it will only serve to piss off developers who want to use a certain library. Nobody pointed out the obvious suggestion laying behind this one: built-in functionality to load, save and possibly modify .dmm files, and perhaps the ability to define a map to load upon world start. The latter suggestion may need some explanation. Currently, when the world first boots up and you want to have a custom map, you need to load it first with dmp_reader or such utilities out there. This not only causes some overhead since it's soft-coded, but it likely also calls unnecessary procedures or New() calls on objects before their initial variables have been set up according to the map. The idea is to include a world/map variable. map var (world) Default value: null When the world first boots up, the map var defines how maps should be loaded. By default, all included maps are loaded no matter what. The map variable can be used to control custom maps to be loaded. The default value is null, which disables this feature. Setting this to a file path or a list of files loads these maps sequentially. Example: world map = list("town.dmm", "house.dmm") This example will attempt to load the map named "town.dmm" if it exists in the same directory as the dmb. Once that map has been loaded it will attempt to load "house.dmm", which must also be present in the same directory. This variable can only be set at compile-time. .......................... map_alone var (world) Default value: 0 The map_alone var controls whether or not the 'map' variable should load it's maps sequentially, or if it should stop once a map has been successfully loaded. The default value is 0, which causes maps to be loaded sequentially. Setting this to 1 causes only one map to be loaded. Example: world map_alone = 1 map = list("mymap.dmm", "mymap.dmp") This example will attempt to load the map named "mymap.dmm" if it exists in the same directory as the dmb. It will only attempt to load "mymap.dmp" if the previous file was not found. This variable can only be set at compile-time. | |
I'm sort of tired of debating. Another idea I had: Being able to load uncompiled .dm code at runtime. Anyone like that idea? Don't eve ask how it'd work. Maybe:
world or
#define LOAD_DM user_created.dm
Well, any questions, comments, etc, about anything, feel free to reply. | |
That would be slower then making your own scripting engine because a scripting engine can be tailored to a games specific needs.
George Gough | |
When you say ..() is broken, in what context is that? I'd bet you're just using it incorrectly. As you noted, . = ..() seems to be working for you, which suggests that wherever you've run into problems you've forgotten to use the return value of the ..() proc. Obvious places that could be a problem are Enter() and Move(), which are intended to return a value. In a proc like Login(), though, it's a non-issue.
Lummox JR | |
Lummox JR wrote:
When you say ..() is broken, in what context is that? I'd bet you're just using it incorrectly. As you noted, . = ..() seems to be working for you, which suggests that wherever you've run into problems you've forgotten to use the return value of the ..() proc. Obvious places that could be a problem are Enter() and Move(), which are intended to return a value. In a proc like Login(), though, it's a non-issue. It was Enter() and Exit() I was using it in. "return 1" and ". = ..()" worked, but "..()" didn't work. Please explain to me what the return value of the ..() proc is. (I have a hunch you mean weather ..() returns 0 or 1, but I'm not sure) Thanks. | |
. = ..() sets the return value to the value returned by the parent. ..() only calls the parent it doesn't actually set the value of . so you end up with a call to Enter() that has no return value, killing all movement.
| |
Guy Hendricks wrote:
It was Enter() and Exit() I was using it in. "return 1" and ". = ..()" worked, but "..()" didn't work. Please explain to me what the return value of the ..() proc is. (I have a hunch you mean weather ..() returns 0 or 1, but I'm not sure) Thanks. Enter() and Exit() are both expected to return a value. Calling ..() should merely tell you if the default version of the proc will allow an atom to enter or exit. But they tell you that through their return value, so if you call ..() but don't use the value it returns, you may as well not have called it at all since neither proc actually performs any actions. (In Login() on the other hand, ..() actually does something, but doesn't return a value.) It's like if you called a proc that said "Find out who owns that object, and tell me", and then didn't bother to listen to the answer. Whatever proc is finding out that info for you doesn't actually do anything except ask. Whereas in the Login() case, ..() is actually doing vital setup work, but it isn't expected to send anything back. When you override Enter(), remember that BYOND is using it to ask whether it's okay for an atom to enter another atom's contents. It's expecting you to send a value back. If you don't, then it assumes you sent back null which is a false value. Lummox JR | |
If you do something like this:
turf/Enter(mob/pc/m) Nothing is returned. You're only calling the parent proc, not storing its value, or returning its valuse. You'd have to do one of the following: turf/Enter(mob/pc/m) | |
Note that with the second one if you change the value of . again, you'll return whatever you changed it to.
| |
Probably it should simply be pointed out that '.' is a built-in variable name which can generally be used like any var, but it is also automatically used for the return value of a proc if it gets to its end without returning explicitly with return first (and also if you don't specify a value with return, it will behave as if you've put 'return .').
myproc() | |
Okay, I've got it now. "." is a variable. I understand now. Actually, no I don't. Why make a variable "."? Might as well make the verb header-thingy lolololol.
mob But I digress. Point is, I get it now. Yay! | |
Guy Hendricks wrote:
Okay, I've got it now. "." is a variable. I understand now. Actually, no I don't. Why make a variable "."? Might as well make the verb header-thingy lolololol. For the record, these are two totally different things. Just guessing, "." was probably named for two reasons: 1.) Judging by the current var naming rules, "." could be used without taking the name of a var someone might want to use, and 2.) They probably wanted people to know that it was special, so they gave it a special symbol. | |
I look at it like a file tree. . is the current directory, and .. is the parent. Which is why 'cd ..' works at all.
| |
Audeuro wrote:
Guy Hendricks wrote: In Visual Basic and some other languages, a function returns a value by setting a var whose name happens to be the same as the proc. In DM that'd be like setting "Enter = 1". Syntactically that's kind of a pain to work with, and Dan wisely did not go with that route, but having a var that means "This is what the proc will return unless a return statement with an actual value is encountered" turns out to be very useful. I'm sure the name . came about because in a DOS or UNIX file system, . is the current directory and .. is the one above. Hence ..() for the call to the parent proc. Lummox JR | |