area/layer=99
proc/Weather() while(1)
for(var/area/A) A.icon=pick(null,'Rain.dmi','Snow.dmi') //and so on
sleep(2000)
world/New()
spawn Weather()
ID:161390
 May 12 2008, 5:33 am
|
|
Hi all u might have noticed that i asked for some help on making a weather system but the outcome wasnt really what i wanted i want to now make my current weather system not to rain or snow inside its also been made so it overrides the default area how do i change it??
| |
Define an area/inside and area/outside, and only loop through area/outside to put weather on.
| |
area Now go to the map, and wherever you DONT want weather to appear, place the Inside area on top of it | |
area -- Data | |
Just a little thing: you don't need 2 area types; only either /area/Outside or /area/Inside, so you should only use one. The more flexible way would probably often be using only an /area/Inside.
| |
Sometimes I prefer if I have multiple z levels to have areas z1, z2, z3 etc and then have an area/Inside...
That way I can change the weather for each "planet" individually. | |
You don't need any additional subtypes at all. Areas could have a boolean variable determinign whether they're outside or inside. This way you can avoid making extremely similar areas under both subtypes or going through all your current areas and placing them under /area/Inside or /area/Outside, for the trivial cost of a few CPU cycles when you're changing the weather.
For the lack of better words, here's an example: consider having the area /area/outside/forest, which handles spawning forest critters in it every once in a while along with other forest-related tasks. You want to include caves in the forest, so you create an /area/outside/forest/cave. However, weather doesn't affect caves, so you now have to replicate the entire forest area functionality inside /area/inside/forest/cave (which is a long and tedious process which leads to ugly code). That could be easily avoided if you use a boolean variable, by creating the type /area/forest/cave and setting the variable so that this area would be considered "inside." | |
DivineO'peanut wrote:
You don't need any additional subtypes at all. Areas could have a boolean variable determining whether they're outside or inside. This is simply another method, in which all that difference would be to change the istype() check to a variable check. Indeed, things can be done in multiple ways, though there isn't necessarily a need to point out all of them in a help topic since after understanding the basic idea, the reader may tweak it himself, if needed. The possible issue with using area type as the validity check was worth a mention, though, since an area may of course only be a certain singel type. As with most things, which one would be better used depends. If you've got no special use for areas in the X location (ie inside/interiors) which may or may not be more limited and smaller than the other Y location, then it's slightly wasteful to have an extra variable for all area types that won't get used much. Otherwise, a variable on the respective /areas to determine this would be beneficial. This way you can avoid making extremely similar areas under both subtypes or going through all your current areas and placing them under /area/Inside or /area/Outside, Aye, it should be avoided, but it wasn't suggested here or anything. For the case of this topic, the question was simply answered, and we don't know about the OP's game's general usage of areas. In fact, they are often underused. | |
Clearly the difference is not only an istype() check. Furthermore, the answer provided should be generally the best way to create a weather system unless Chrislee requested otherwise, and dividing areas to two subtypes for the simple purpose of deciding whether they're interior or exterior is a bad, bad idea, regardless of Chrislee's usage of them.
As with most things, which one would be better used depends. If you've got no special use for areas in the X location (ie inside/interiors) which may or may not be more limited and smaller than the other Y location, then it's slightly wasteful to have an extra variable for all area types that won't get used much. Otherwise, a variable on the respective /areas to determine this would be beneficial. I agree that there are rare cases where your method may be more efficient, but robustness and readable code are more important, especially when the difference is so minor. | |
DivineO'peanut wrote:
Clearly the difference is not only an istype() check. Clearly (=P), that's the actual difference in the code (other than the actual variable definition, of course). So it's not like people would never figure it out and be able to do it themselves unless you explicitly point it out. and dividing areas to two subtypes for the simple purpose of deciding whether they're interior or exterior is a bad, bad idea, regardless of Chrislee's usage of them. Nope, the usage does decide whether this is a worse idea. But anyway, thing is, you can do this with most area-based functionality (which if you did would add up lots of boolean variables which would then require changing the implementation in favor of a better method), and I've pointed this out myself in a few area-related topics before, however what also matters is what suits you (/your game) best. | |
Clearly (=P), that's the actual difference in the code (other than the actual variable definition, of course). So it's not like people would never figure it out and be able to do it themselves unless you explicitly point it out.
The difference is that, instead of changing a single boolean variable, you have to sort all of your areas under these subtypes and occasionally replicate their funtionality, which as I said leads to multiple instances of the same code. That's bad. Oh, and who said anything about people being able to do something? Nope, the usage does decide whether this is a worse idea. But anyway, thing is, you can do this with most area-based functionality (which if you did would add up lots of boolean variables which would then require changing the implementation in favor of a better method), and I've pointed this out myself in a few area-related topics before, however what also matters is what suits you (/your game) best. As I pointed out earlier, the general best solution is using a boolean variable. As you don't know what kind of game this thread's author is making, you should point that solution instead of one that is rarely efficient. Also, I don't see any reason why using your method is best. All you've been doing is ridiculing mine. If you can't point out any reason to use that method above mine then your argument is null. | |
DivineO'peanut wrote:
Oh, and who said anything about people being able to do something? Don't put what I said out of context. Who said that you said anything about people being able to do something? It is related and the point of my post, but it seems you've skimmed my previous post, and I wrote about it there, so I'll skip it now. Nope, the usage does decide whether this is a worse idea.As I pointed out earlier, the general best solution is using a boolean variable. As you don't know what kind of game [...] Again, what decides the 'best solution' is what the game author intends to actually do, and varies according to his game's other parts and his wishes. I could easily say you're wrong here and the best solution isn't a boolean variable, but an integer from 0 to 10 that depicts that area's "interiorness" level, or how much is the interior "closed". For example, you'd set the default value for interiors to 10, but for a cave, an old shack and a ruin where there would be cracks and holes (which should allow weather to affect the area) in the walls and ceiling as well as an opening hole, you'd set it to varying levels from 5-8. This way, for normal, most interiors, it still acts the same as your original method because of the default value, however it is now more flexible and more robust method because it accounts for more occurrences such as caves and ruins, which you do not know if exist in the OP's game or not, therefore, it is 'the generally best solution', eh? Even if the OP didn't ask for all that. Also, I don't see any reason why using your method is best. It seems you're highly missing the point here. I was never arguing that "my" (was actually not brought up by me in this topic) method was the best, unlike you if I might add. All you've been doing is ridiculing mine. ...No, I haven't, so I'm going to have to ridicule your reading here. I said 'your' method was useful myself and that I've occasionally brought it up myself elsewhere. If you can't point out any reason to use that method above mine then your argument is null. I already have, but I'm going to have to announce that your argument is officially null, because you've missed the whole point. There shouldn't really have been an argument in the first place.... *officially leaves the thread* | |
Kaioken wrote:
So it's not like people would never figure it out and be able to do it themselves unless you explicitly point it out. Don't put what I said out of context. Who said that you said anything about people being able to do something?It is related and the point of my post, but it seems you've skimmed my previous post, and I wrote about it there, so I'll skip it now. You said it yourself. I didn't skim over your post, but if I missed anything you should point it out. Again, what decides the 'best solution' is what the game author intends to actually do, and varies according to his game's other parts and his wishes. I could easily say you're wrong here and the best solution isn't a boolean variable, but an integer from 0 to 10 that depicts that area's "interiorness" level, or how much is the interior "closed". For example, you'd set the default value for interiors to 10, but for a cave, an old shack and a ruin where there would be cracks and holes (which should allow weather to affect the area) in the walls and ceiling as well as an opening hole, you'd set it to varying levels from 5-8. This way, for normal, most interiors, it still acts the same as your original method because of the default value, however it is now more flexible and more robust method because it accounts for more occurrences such as caves and ruins, which you do not know if exist in the OP's game or not, therefore, it is 'the generally best solution', eh? Even if the OP didn't ask for all that. Levels of interiors isn't what was asked here. It was how to make certain places not be affected by weather. It's like asking what's the best way to calculate the distance between point XX and point YY: you could count the steps using get_step(), or simply calculate the distance using their x and y coordinates. The latter is obviously a better way, unless there's a specific case where you also need to know about everything that is between XX and YY. It seems you're highly missing the point here. I was never arguing that "my" (was actually not brought up by me in this topic) method was the best, unlike you if I might add. What I understood from your blaberring is that my method isn't always the best (which I agree with), and that it shouldn't always be used. I'm saying that my method is generally better than yours, and that you should be using it unless you have a specific reason not to. You saying that I don't know what would be best in this case is true, but seeing as we don't have enough information to be arguing about this the method that is generally better should be applied. I already have, but I'm going to have to announce that your argument is officially null, because you've missed the whole point. There shouldn't really have been an argument in the first place.... *officially leaves the thread* Unfortunately my argument isn't null (especially not "officially") unless you can explain yourself properly. I don't mind you leaving this thread, but don't go telling me this, especially when you're the one who isn't explaining himself. | |
I think we can all agree data did the best weather system like usual ^.^ thanks data u rock and ur god in my eyes now ^.^
| |
Android Data wrote:
> area Looping through every area for every zone is inefficient. Better that the zones list is an associative list, like so: world/New() That way, if you have 100 areas in 100 different zones, you aren't looping through 10,000 areas. Oh, you probably also would want to change the zones to text strings in this case, as well. Numbers might screw it up. | |
Use area only on outside and make it so only that area changes weather patterns