It has it's uses, but the primary reason it shouldn't be used is just because it's ambiguous. With the . operator you can be certain that what you're doing is correct, while the same can't be said for the : operator.
On an interesting side-note, before Audeuro left he did some tests with the : operator and found it's actually faster than the . operator, which confused us all, as the : operator seems like it should be slower.
Keep in mind that there's a limit on the number of images I've discovered there is never really any reason to create the same image from the same file more than once, ever. With this I have kept my image counts incredibly low. | |
Popisfizzy wrote:
It has it's uses, but the primary reason it shouldn't be used is just because it's ambiguous. With the . operator you can be certain that what you're doing is correct, while the same can't be said for the : operator. It shouldn't be used unless you are doing typechecks, or if you are using a macro of some sort that could never possibly be wrong after the initial definition. | |
Obs wrote:
I've discovered there is never really any reason to create the same image from the same file more than once, ever. With this I have kept my image counts incredibly low. Unless if you want to attach the same image to multiple objects. | |
Garthor wrote:
Obs wrote: It's the same image. | |
Images are not the same things as icons. They can be used as icons, but the purpose of images vs. icons is that images can be selectively displayed to clients. WHERE the image is displayed, then, is determined by its loc variable. Therefore, if you want the same image displayed in two different locations, you need two images with the same icon with different loc variables. If you've figured out a way to have an image have two different locations at once, I'd love to hear it.
| |
If you've figured out a way to have an image have two different locations at once, I'd love to hear it. You will not only hear it, but you will see it in action. Just give me a week or so. The method will become obvious enough. | |
There is not enough time in the day to read through this entire thread, yet I have gone through much of it. For future reference, I'll clear up an issue in this post, and hopefully set some light to a conflict or two, if they haven't yet been lit in the unread posts that I am ditching.
Xooxer wrote: No, they are not objects. Lists are certainly not objects. I don't know where you got that idea from. Mobs and objs are objects. Turfs are objects, though stationary ones. Atoms are not objects. Areas and datums are simply concepts. They aren't physical objects in the world. When in doubt, refer to the Class-Object Theorum: If C is a class definition, and I is an instance of class C, then I is an object! (a.k.a. If it looks like pee, and it tastes like pee, you're probably drinking pee.) Classes in this sense refer to definitions of a type, possibly with properties and methods (variables and procs). Therefore, if you have class /area/grassyknoll, and var/area/A references an instance of that class, then A is an object. It is also worth noting that the /list type can be considered a class (and it contains properties such as the length variable), and therefore list instances are objects. If they have different variable values, they should be different types. There is no reason to use multiple instances of the same type of area. There is no reason to use the del() operation, either. Nor is there a reason to use cmpText(), or many other features of the language. In Go, there is no reason to tenuki from a low kakari. People still do these things because their beliefs differ from your own, and there is no set-in-stone-absolutely-black-and-white standard for things like this. While it's good to encourage good practices (or at least practices which seem correct to you), it's not always best to market them as surefire facts. Myself, I'm not going to comment on the usefulness of instancing areas, because I've never bothered with it and I don't expect I will any time soon. Hiead | |
Xooxer wrote:
An object is a solid, real thing, and area is a more of an idea or concept. A rock is a thing, the space around that rock is not. An area is the space, not the thing the space holds. If you have two spaces that are the same, it doesn't matter what they hold, they can be thought of as the same space. In DM, there are no such restrictions. The only thing separating an /area and an /atom, essentially, is a location (areas don't have it). You can actually make rocks out of areas, and rightly so: If you have 1000 rock-barriers around your map, that either comes out to 1000 /obj instances or 1 area instance. Both achieve the same effect: Impassibility. I prefer the latter. Hiead | |
How nice and cryptic. Point still stands that if you change the loc of an image, then that image moves. You can't have the same image in two locations.
Well, partial exception for areas, which will display the image over all turfs in the area. They're weird like that. | |
Well, partial exception for areas, which will display the image over all turfs in the area. They're weird like that. If this is true, if one image can be applied to all turfs in an area without making multiple copies of an image, then all I've done really is reinvent the wheel. But there may be some use to what I've done anyway, since with my method you could have moving images and still only use one instance of the image. I haven't really investigated areas at all. I probably should. Would make life easier. Would help if I knew the TRUTH about areas. | |
Popisfizzy wrote:
On an interesting side-note, before Audeuro left he did some tests with the : operator and found it's actually faster than the . operator, which confused us all, as the : operator seems like it should be slower. Odd, because as far as I can see at the bytecode level the . and : operators are identical (same opcode). Perhaps using . automagically inserts an extra type check in some cases, but I haven't been able to find an example where it does that. If you've got example code that shows a speed difference, I'd like to look at it. | |
But here's another thing I want to know.
If you want to show a single instance of an image across all turfs on an area, does that instance of the image have to be defined within the area's variables, or can the area simply reference a global image instance? Example, you ahve one image graphic for every roof in the world. Can you have some areas showing the roof image and other areas hiding it without creating multiple instances of the roof image? Because that would be pretty powerful. | |
Xooxer wrote:
The only reason I can gather that Shadowdarke is creating new area instances is so he can track them as his and not part of the existing world, since his code is executed from an external library and could be combined with many sorts of games. Even then, he could have tracked his area's turfs instead, and not had to create any new instances of existing types. Actually, I use the area instances because each has a different overlay based on the degree of darkness. The new instances are slight variations on the area, not just a copy. Slipping turfs in between areas is much faster than updating the graphics for those same turfs. sd_DAL doesn't track the new instances, unless they are intended for use as an outdoor area. Games that use areas for other purposes and want to include sd_DAL can easily be updated to check if an atom is moving between darkness regions within one area type or completely separate areas. I know that's not ideal, but it's what I have to offer. And since you don't understand the situation, you aren't someone who should be listened to when it comes to knowing when it's okay and when it's not. I trust someone like Shadowdarke to know how to handle area management elegantly. I don't trust newbies to do the same. Thanks for the vote of confidence! :) I encourage experimentation on the part of newcomers, as long as they're willing to deal with the consequences of said experimentation. I'd have never known how to use the area swapping for sd_DAL if I hadn't experimented with it when I was new. For you experimental types out there, make sure you experiment in carefully controlled environments. Experimenting with your 30,000 line game could lead to inconclusive results and might just break a few things! | |
So show us an implementation of that. Keep in mind that there's a limit on the number of images and, therefore, creating too many would result in you failing miserably.