Ok last night I had to sleep with one last problem remaining.
What I'm trying to do if certain conditions are met, is to show the contents
of list/kana2 to the user. Also at startup I'm trying to fill list/kana2 with
objects. So 2 things going on here and not sure which is not working. Could
someone take a view of my code for the needed correction?
Example code:
---------------------------------------------
mob/player
var/list/kana2
proc
StartUP() // Of course this is getting call ok
new/obj/kana2/a(kana2) // This is one way to add
kana2 += new/obj/kana2/i // This is another just trying things here
Stat()
if(conditionMet)
statpanel("Second List")
for(var/obj/O in kana2)
stat(O)
---------------------------------------------
The Second List is showing up right now, but it remains blanks.
ID:175497
 Apr 16 2003, 2:40 am
|
|
At first no.. more confussion! :)
But then in fustration, I happened upon the DM Reference over there and looked up the Appendix 5. Addendum for BYOND 3.0, something I've skimmed but never updated myself with since reading the Blue Book, something else I think I should re-read before posting anymore :) Anyways thanks to something new I discovered called parent_types! I'll be creating a new atom to server my purposes! Thanks for your thoughtful reply. LJR | |
As far as I know it's not possible to create a new atom type; DM wouldn't know what to do with it. You can however create subtypes of the existing kinds of atoms, like mob, obj, and so on.
An ordinary obj should serve you just fine if you actually are looking for just a container. Lummox JR | |
Actually, I believe it is possible to create a new atom type. It's just treated as a turf. Or, I could've just been insane that day.
| |
Lummox JR wrote:
An ordinary obj should serve you just fine if you actually are looking for just a container. As I was pondering last night huh? I think just for the new learning factor I'll still give this a try. One question if I'm going to just be using the object as a container, so I need to also ensure it is movable? holders/parent_type = /atom Or does movable allow me to move stuff into it's contents? As it is right now it acts more like a turf. | |
atom, datum, and parent_type
From the standpoint of elegance, the most important development has been the addition of object types that bring together all of the built-in DM objects. Since the atomic objects /area, /turf, /obj, and /mob are all defined at the "top" of the inheritance tree, a new construct had to be invented to allow all of these to share a common ancestor. This is a variable named parent_type. It allows an object type to be derived from some other point in the type tree. This naturally lead to the creation of various "ancestors" in the type tree. The new entries are listed below: datum //ancestor of all objects atom //ancestor of all atomic objects parent_type = /datum atom/movable //ancestor of movable objects area parent_type = /atom turf parent_type = /atom obj parent_type = /atom/movable mob parent_type = /atom/movable All object types at the top level are implicitly derived from /datum unless parent_type is pointed to something else. In the code above, therefore, the statement atom/parent_type = /datum is actually redundant. Of course, types at lower levels of inheritance are still derived from the type "above" them, just like they used to be, unless parent_type is applied. For example, there was no need in the above code to make the statement atom/movable/parent_type = /atom. The upshot of all this is that you can add properties to all objects, all atomic objects, or all movable objects by simply defining new procedures or variables in the ancestor object types. Previously, one sometimes had to resort to defining the same procedure once per atomic object type, which was silly. It also allows you to create new atomic objects that behave as "siblings" of the built-in ones. For example, you might want to have separate /player and /monster types: player parent_type = /mob monster parent_type = /mob In general, this allows you to choose between the hierarchical type tree and a more flattened out approach with more top-level or near top-level types. | |
Nope, it doesn't have to be a movable atom to contain things. In fact, a player mob sitting "on top of" a turf is actually in the turf's contents list. Similarly, the turf is in the contents list of the area it sits in.
I would recommend that you do make it a movable atom, though. Deriving it from /atom rather than /atom/movable might make DM treat it like a turf or an area, which is probably not desirable. | |
A list is not a physical container. An atom is.
The atom.contents list is a special list; adding to it changes another atom's loc var (even if the var isn't meant to be changed, like for a turf).
An atom's loc, however, can never be a list--it always has to be another atom. When I say a flower is in a flowerpot, I don't mean it's "in" flowerpot.contents, even though that's true; it's "in" the flowerpot, and the flowerpot.contents list is just a quick way of keeping track of what's in the flowerpot itself.
So since a list can never be the container for an object (as in a physical container like an atom), therefore can't be the object's loc, you can't do this:
What you really want is to create an obj and add it to a list. You can add an obj to as many lists as you want, or as many times as you want.
Lummox JR