I've been trying to decide whether I want to stop using types for objs and areas, and just have some type-like variable saying what type they are. Didn't someone (Deadron?) say this was easier on the CPU? I'm not sure how
var/area/A
for (A in world)
if (A.kind == "dungeon")
would be any quicker than
var/area/dungeon/A
for (A in world)
The advantage would be that I could switch a thing's "type" while in-game, or add new "types" from in the game. And that is a nice advantage. But it would deprive me of the ability to do something I must be able to do, which is essentially add procs to single objects (currently approximated by making a new type with its own proc, then creating 1 item of that type... not the most efficient). Will "procs" ever be an object variable they way "verbs" is?
Second question... I thought there was a proc that would put a list of variables in alpha or numeric order, but I can't find anything in the reference. Since there were those couple releases where lists were coming out in alphabetical order, I assume it'd be a lot easier for you guys to make a built-in proc that did this, rather than having us code our own... how about it?
Z
ID:138284
 Nov 29 2000, 11:20 am
|
|
The advantage would be that I could switch a thing's "type" while in-game, or add new "types" from in the game. And that is a nice advantage. But it would deprive me of the ability to do something I must be able to do, which is essentially add procs to single objects (currently approximated by making a new type with its own proc, then creating 1 item of that type... not the most efficient). Wow, we're thinking along the same lines, sort of. I've spent the last couple days pondering the question of NPC AI, and I wandered into the dangerous realm of the Tuples! This is an old idea (though it has recently been given fresh life thanks to the RDF standard). The premise is that you can set up a network of information such that any fact can be expressed as two things and a relation between them. For example: sheep IS A mammal sheep HAS wool This also allows you to make inferences. If you know programmer IS A human Dr. Tom IS A programmer then you can deduce: Dr. Tom IS A human. Of course, this still makes for pretty simple facts, though you could string many of these together: A = Lord Spuzzwell KILLED Sir Tellefsley B = (A) HAPPENED AT dawn C = (A) HAPPENED BY MEANS OF a pistol D = Earl Deadronnet OBSERVED (A) But I digress. Even without any of that complexity, it sounds ideal for the type of thing you want to do, which is kind of like "multiple inheritance" -- an OO feature which BYOND doesn't support (and probably rightly so, though this is a topic of religious debate among programmers and I'm not really committed to either side). So, anyway, you could use this technique to support a hierarchy of knowledge completely separate from your BYOND object hierarchy. As for procs, you could make them global (but not recommended) or better, you might look into using the Call function. So you might end up with something like this: if(currentRoom.isa("Dungeon")) Call(/roomProc/proc/SpringTrap)(currentRoom.contents) Anyway, I'll shut up now... but I think there's a way to do something like what you have in mind. | |
On 11/29/00 3:36 pm Guy T. wrote:
So, anyway, you could use this technique to support a hierarchy of knowledge completely separate from your BYOND object hierarchy. As for procs, you could make them global (but not recommended) or better, you might look into using the Call function. So you might end up with something like this: Brilliant notion, Guy! I, too, think that the 'call' proc is the way to go here. It allows you to make all of your proc assignments dynamically, and even organize them to some degree. In the above example, and instance of the /roomProc object doesn't even have to exist in your world-- it is just used as a placeholder for the functions. An alternative approach would be to make a global /roomProc object and call things by name, eg: call(global_room_proc,"SpringTrap")(currentRoom.contents) (where global_room_proc is created globally somewhere, as in: var/roomProc/global_room_proc = new()) which might be easier since it uses strings, which may even be relayed from the user to you to make things even more dynamic. However, you should do a lot of preliminary design before delving into a scheme of this sort, since it is just asking for abuse. I am by no means an expert, but I would be glad to discuss it, as it seems like a fascinating notion. Note that this is effectively the same thing as adding a proc to an object at runtime. In that case you would be using the notation: O:dynamic_proc(). BTW, it is possible to do this by simply adding verbs to the object-- verbs are procs, after all-- you just have to restrict the range so that users can't execute them directly. I think that global procs or, better, the above object-based call() scheme is superior. | |
Okay. I avoided replying to this for a day because I didn't understand very much of it, and I wanted to have questions to ask besides "Huh?". Well, no luck there. I am not the most brilliant mind when it comes to learning new programming concepts.
On 11/29/00 4:19 pm Tom H. wrote: On 11/29/00 3:36 pm Guy T. wrote: So... how is the /roomProc object defined? And when I call those procs, what is the src? An alternative approach would be to make a global /roomProc object and call things by name, eg: Sure, I'd definitely like to call procs by name. But... how would inheritance of procs figure into this stuff? I don't imagine it'd be quite as easy to see if the room has its own New() proc, and if not, call the all-room default New() proc. Or I suppose I could always call the default one, and it would check to see if the object had its own specialized proc. But it seems inefficient to put that code in all the "default" procs. However, you should do a lot of preliminary design before delving into a scheme of this sort, since it is just asking for abuse. What do you mean by abuse? Note that this is effectively the same thing as adding a proc to an object at runtime. In that case you would be using the notation: O:dynamic_proc(). What are we talking about here, global procs? BTW, it is possible to do this by simply adding verbs to the object-- verbs are procs, after all-- you just have to restrict the range so that users can't execute them directly. How would you do that with verbs? Z | |
On 11/30/00 2:48 pm Zilal wrote:
Okay. I avoided replying to this for a day because I didn't understand very much of it, and I wanted to have questions to ask besides "Huh?". Well, no luck there. I am not the most brilliant mind when it comes to learning new programming concepts. Don't feel alone -- I have no idea what they are talking about either. I need my concepts spoon fed to me. | |
On 11/30/00 3:45 pm Deadron wrote:
On 11/30/00 2:48 pm Zilal wrote: Sorry! My post wasn't all that clear; this is a vast topic so I don't even know if I addressed the real issue. After I finish my current coding assignment (to end this new key confusion once and for all), I will attempt to construct an example for you. | |
So... how is the /roomProc object defined? And when I call those procs, what is the src? Well, it's not really defined much at all. It's a datum -- i.e., it's a top-level node, on par with the ATOM objects but without a place to go on the map. (Though, actually, you could probably put a datum in something's contents list... hmm, wonder what would happen!) As for the src, I don't know. I would guess either A) the src of the current proc or B) null. However, if you really must use src (as I really must wherever it makes sense), I think you can set it manually in the code, like so: roomProc proc/SpringTrap(list/roomContents) src = roomContents var/mob/K for(K in src) K << "A trap got you! L0053R!" Sure, I'd definitely like to call procs by name. But... how would inheritance of procs figure into this stuff? I don't imagine it'd be quite as easy to see if the room has its own New() proc, and if not, call the all-room default New() proc. Or I suppose I could always call the default one, and it would check to see if the object had its own specialized proc. But it seems inefficient to put that code in all the "default" procs. Well, you're right to a point. But at least in the example of New(), your formal object hierarchy would provide some level of separation. For example, say that your object hierarchy is something like /obj/equipment/food, and the fact that it's a cotato is stored in a tuple (or list of flags, or whatever). You know a mob, turf, or area is never going to be a cotato, and it will always fall under /obj/equipment, but you don't know if it will be a food or a weapon. Then you know that you can put the code in the New() for /obj/equipment, which at least limits the scope of the inefficiency. And there might be other ways to handle it too... I think Tom and I were both just throwing out ideas. :) However, you should do a lot of preliminary design before delving into a scheme of this sort, since it is just asking for abuse. It means we will ridicule you and say "it'll never work!" until you finally make it work and shame us all. :) Actually, I think he just means it could end up making less efficient, harder-to-read code if you tried to do everything this way instead of using some discernment as to where/when it's really appropriate. BTW, it is possible to do this by simply adding verbs to the object-- verbs are procs, after all-- you just have to restrict the range so that users can't execute them directly. usr.verbs += /bla/bla/bla(), I think... there's a sample in DM InfoCenter, called "Runtime Verbs" or something. | |
On 11/30/00 5:30 pm Guy T. wrote:
So... how is the /roomProc object defined? And when I call those procs, what is the src? Oh. I suppose *that's* what Form is. BTW, it is possible to do this by simply adding verbs to the object-- verbs are procs, after all-- you just have to restrict the range so that users can't execute them directly. Oh, well, I knew you could add verbs to things. But I don't know how that will allow me to do what I want to do (attach procs to single instances). I mean, verbs may be procs, but can you still call them with call()? Z | |
This wouldn't be any faster...my reference was probably to using that to allow guides to create new kinds of objects/mobs on the fly. But it's really not a programming morasse you probably want to descend into.
The Deadron library has a sorted list for this sort of thing...but I think it needs some work to be more useful.