Feb 9 2014, 2:19 pm
|
|
Sir Quizalot
 |
Not at once and not literally but still thanks. Kudos everyone.
|
So are you trying to say locate(Tag) has no container. Because world var contents is a container.
I think Super Sayian X would disagree with you as he just said I was correct. everyone who has participated in this topic has literally told you this. What's more. "If a text string is given in place of an object type, the object with the same tag is found. If a container is given, only objects directly within that object are searched." It is interchangeable- key words: given in place. edit: I checked "locate(Tag) in src" compiles without error. edit: Apparently Kaiochao deleted their comment. | |
You're making this much harder than it has to be. Yes, you can specify a container. All the same rules go with it, if you do.
I'm not sure exactly what your question is, but my story is still the same. Also, world.contents is not used by default. You can test this with the following code. test_datum This should be a valid test given the fact that datums are not automatically added to world.contents upon creation. The first locate() with no container specified will find the tagged datum. The second one will not. *Edit* added a third test for clarification. This one should work. | |
Koshigia wrote:
You're making this much harder than it has to be. Yes, you can specify a container. All the same rules go with it, if you do. snip This should be a valid test given the fact that datums are not automatically added to world.contents upon creation. Not disagreeing, but... This is kinda weird to explain, but there is a difference between the explicit referencing of world/world.contents ("in world" for locate or for loops) and the implicit referencing of world as the default container as defined by the DM Reference. (no container defined, the server uses a bigger definition of world than we have access to by explicit invocation) | |
I was only clarifying the difference between world and world.contents as SQ seemed to care much for minor details.
Would you happen to know what the differences would be between "locate() in world" and just "locate()"? I wouldn't know enough to disagree, but I know that the results are the same for a instantiated datum. | |
Why isn't world.contents the same as world, or locate()'s default container- world.
The test shows locate("My Object") in world == locate("My Object") But locate("My Object") in world.contents doesn't equate to them why? Isn't world contents the same as world- in world? | |
It could be easy to assume so, but the answer is no. The only difference I know of for sure is that atoms are added to world.contents and datums are not (by default)
| |
Trying to find this. Do you mean when you define new() that datums are not added to world.contents.
atoms are added to world.contents and datums are not (by default)Is that in the guide have yet to find it in a reference. Just looked at datum. I don't see it in new Type(Args)'s reference. I think if we had a test showing for sure where Datum's go if you mean using new() procedure then I would buy it. | |
It's implied. Datums have no concept of location, so they don't meet the requirement for the world contents list. Same as strings, sounds, files, clients etc ordinarily, unless you put them in there.
| |
Okay so Datum is father of atom which the loc variable, is first defined- so Datum's wouldn't have any "location." Yet they are added to something as shown in Koshigia's example(example 1 and 3)- a "data(only) world" So, in world means: type paths in world- at least for Datums instances created. And since world contents is based on loc var of atoms their is no way a Datum may be found in world.contents. IS this correct?
| |