areas

Page: 1 2
ID:87402
 
Dec 13 2009, 10:50 pm
Not a bug
BYOND Version:460
Operating System:Windows Vista Home Premium 64-bit
Web Browser:Internet Explorer 8.0
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:I was trying to use areas to mark out where a verb should add and delete certain objects at on the map, but, it seems to only want to detect one area of that type with the code below, but the code works when using turfs and stuff instead.

Numbered Steps to Reproduce Problem:Try and make it show the locations of X area on the map, but it only shows the location of 1, works on turfs though.

1.Open Dream Maker.
2.Put the code in.,
3.Make a default sized 10*10 map.

You will notice when using verb, it doesn't work, because I tried this, even with empty project, but it didn't work.

Code Snippet (if applicable) to Reproduce Problem:
mob
    verb
        Count_Areas()
            var/Count
            for(var/area/a in world)
                Count++
            src<<"<b>There are [Count] of type /area on this map."


Expected Results:It to show there was more than 1, because it was a 10x10 map.

Actual Results:It showed there was only 1, it does it where it be /area or an area i defined.

Does the problem occur:
Every time? Or how often?Every Time
In other games?All Games
In other user accounts?Yes
On other computers?Yes

When does the problem NOT occur?When not using area, but using turf, mob, or other types, or having created multiple area types might work, but I didn't try, I wanted to use all the same area type because it all relates to the same verb though.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
I don't know, but I remember being able to use areas before to mark places as being inside buildings or outside, to make weather effects and such, but it's not working now.

Workarounds:Use multiple areas, or use turf/mob/obj or something else instead of area.

Dec 14 2009, 4:22 am
This is how areas work. If you use a default project, you automatically have one area. If you define a new area such as /area/test and add that to a 5x3 section of turfs on your map, you will have two areas: the default /area and /area/test. If you want to find out which turfs an area covers, you have to loop through each turf in area.contents.
Dec 14 2009, 5:01 am
I don't understand fully what you mean by this.

I was expecting it to work like for(var/turf/a in world) does and list every turf in the game.

Is there a reason for the different behavior in areas? It does give location of the first area, which is also a mis-leader in how it works, because you would think that would become null if it is only meant to show which types are in the game.

Also, I only want to know the location on the map for the areas of a certain type, I do not care for the turf that is onto the same location.

Anyways, this seems to be a changed behavior then, cause a resource downloaded for weather still works and it was compiled in an earlier version of byond, but one I create with the same code doesn't.
Dec 14 2009, 5:11 am
If the resource itself had changed, then there would be changed behavior worth investigating, but creating one from scratch doesn't show a change in behavior.

Each area can hold multiple turfs. You say you want to find the location on the map where an area is, not the turfs in the area, but it's the exact same thing. The turf is the actual physical location.

Further discussion of this issue really belongs in the Developer How-To forum. After acquainting yourself with areas in the DM Guide that is the best place to ask questions about how to use them.
Dec 14 2009, 6:22 am
If the resource itself had changed, then there would be changed behavior worth investigating, but creating one from scratch doesn't show a change in behavior.

I don't understand what you mean here.

Anyways, the resource used an older byond version when it was made, and it works as per my code, but when I try it in a new project, does not work even when using the same code as the resource uses.

I had ended up using objects instead to do what I wanted, as going through the contents list for an area is slightly more work, considering I already got it working using objects instead.
Dec 14 2009, 6:26 am
Turfs are not the same thing as areas, as I mentioned earlier. The fact that you're unfamiliar with how to use areas is probably why you had trouble adapting the demo (?) to your new code. I'm glad you found a solution that works for you, though.
Dec 14 2009, 6:29 am
Actually, did you not understand? I fully copied the demos exact code to a new project, and compiled, and it didn't work. It was not a matter of adapting it. I copied it exactly as it was to a new project, and it didn't work, the only explanation I could think of, is that it was compiled in a different version of byond, so it works for some reason, when a newly compiled one doesn't.
Dec 14 2009, 8:06 am
Demos are by nature not meant to be included verbatim in another project--that's what libraries are for. To use a demo in a project you must adapt it in some way, so the fact that copying the code exactly didn't work is to be expected. Really the only basis on which to assume the behavior has changed between BYOND versions is if the very same project behaves differently in a newer build. Once you're working with a new project you're comparing apples and oranges. But either way, the behavior you're seeing is not new; it's the way areas have always behaved, by design.
Dec 14 2009, 9:20 am
Maybe you did not fully read, but I copied over exactly the files into a blank project, without changing anything, I didn't copy them over to a game or anything.

It's the way maybe they should have worked before maybe, and got fixed on accident then, but it's not the way they have always behaved, I have been with byond for years, and have coded with areas before, and never before did I have to work with the area.contentes list, and also, in the demo, shows nothing to do with that area.contents list, so, it must have been working differently in another byond version.
Dec 14 2009, 10:03 am
The behavior of areas has not changed, recently or ever. Some particulars could have changed in newer versions from the old, like how at one point certan /area verbs stopped working, but what you're talking about is the fundamental way areas have always been defined. A demo copied over and no longer working, even in pristine form, could mean any number of other things, but it most definitely does not mean areas were at some point not areas. If you don't define different areas and you loop through all the areas on your map, there will only ever be one area regardless of how many turfs there are. That hasn't changed since turfs and areas were first incorporated into the language.

If there is a bug in that demo, that is if the original project itself works in a particular version but not in another, that might point to an actual bug in need of fixing. If so I would need to know which game or demo it was, and it would help to know which version it worked in and which it didn't. But once copied to another project, even a blank slate, we're talking about two different projects and comparison is meaningless. The only comparison that's worth looking at is if the very same project works in 454 but doesn't in 460, or if it works when compiled in 454 but doesn't if it's compiled in 460.

I'll gladly investigate any issue with the game/demo itself if it worked in an older version but the exact same project doesn't work in a newer version. That will require all the relevant information about the issue at hand, such as which project it is and in which way it isn't working as expected. The original source code would also be helpful.
Dec 14 2009, 10:45 am
Well, one copied over in the exact state of the original is the same as the original.

Anyways, yes, the original project acts differently if compiled from a new version, but the version it was originally compiled in works fine.

The new project and original are exactly the same copying over all the code/icons, so, it does not make sense as to why they would act differently.
Dec 14 2009, 11:05 am
Superbike32 wrote:
Well, one copied over in the exact state of the original is the same as the original.

The very act of copying it introduces a new variable into the problem, so it's not a trivial distinction. A lot also depends on the way it was copied, etc.

Anyways, yes, the original project acts differently if compiled from a new version, but the version it was originally compiled in works fine.

Feel free to send me the source for that original project and I'll compare when compiling in 454 and compiling in 460. I'll also need to know what to look for, such as what to do in the game and where to go to see the issue.

The new project and original are exactly the same copying over all the code/icons, so, it does not make sense as to why they would act differently.

There's probably some difference you haven't mentioned, either because you didn't think it was relevant or it didn't come to mind. But if there's a bug here then it's in the original project and not the new one, so if you send the original over I'll have a look.
Dec 14 2009, 11:12 am
Well, actually, I copied it over by copying code manually, and icons by opening project folder and copy+paste on the files to the new directory, then just compiled, from a blank project, the files+code were the same though, not one line changed or one icon changed.

Anyways, I will send it later today if I get a chance, the code has almost exactly what was shown above, but it instead calls a proc for the counting to take place in for some reason.

I don't know if it broke at what version, I haven't messed with areas a lot, maybe not even since 3.5 versions, so, it could have been way back then as to when it was some kind of 'changed' behavior.

It probably was un-intentionally messed up back then, but nobody had figured it was a bug, so it never got reported, but I have seen many resources like this, that use the same method as posted in the bug report.
Dec 14 2009, 11:28 am
Superbike32 wrote:
Well, actually, I copied it over by copying code manually, and icons by opening project folder and copy+paste on the files to the new directory, then just compiled, from a blank project, the files+code were the same though, not one line changed or one icon changed.

That is a somewhat different concept than an exact copy. In particular the .dme also affects what libraries are in use. A true exact copy would duplicate every file with a simple copy and paste of every file in the folder, or you could even package the source into a .zip via the DM menu and unzip it somewhere else. This is why I said you're comparing apples and oranges--the little detail that you used an unconventional copy method is significant.

I don't know if it broke at what version, I haven't messed with areas a lot, maybe not even since 3.5 versions, so, it could have been way back then as to when it was some kind of 'changed' behavior.

The fundamental way that areas work has never changed, so we can put that part of the discussion to bed. The only issue of interest is whether a project that was known to work in 454 does not work in 460, and if not then why not. When you send me your known-working code I'll take a look.
Dec 14 2009, 11:32 am
.dme does affect it, but that was copied line for line as well, so, they were the same line by line in all files, unless some file has something u can't see, which is not the case.

Also, even though it hasn't changed, doesn't mean something mostly unrelated didn't change it in some way, anyways, most of the code was already given to you, I just don't know if versions so close to each other however will yield a different result, because I don't know what version the old one was compiled with.
Dec 14 2009, 11:36 am
I'm not certain I have your code at all or which code you're referring to, so the safest course is to send the most recent code you know works.

And by all means, please compile and test in 454 to be sure it really does work first. If it does, recompile and test in 460 with the map_format changed to TILED_ICON_MAP (if necessary) and if it does fail then, then we have an issue and it's something I can take a look at. If it works (or doesn't work) the same way in both versions, then I think a bug can be ruled out.
Dec 14 2009, 12:40 pm (Edited on Dec 14 2009, 12:48 pm)
I am off of what I originally posted, now I am wondering why this will add overlays to all of that area, but it wont count up/create a certain object at the location of all the areas.

Note: To test, just make any icon for 'icon.dmi', I made a solid blue tile.

mob
    verb
        Start_Changing()
            for(var/area/a)
                for()
                    sleep(3)
                    a.overlays+='icon.dmi'
                    sleep(3)
                    a.overlays=null
Dec 15 2009, 5:43 am
This is not a code help forum. Your question is readily answered by the DM Guide, since this is a basic principle of how areas work. As I've mentioned before the comment threads to bug reports are not for idle discussion, so please limit further comments to the matter of whether (and how) your original project behaves differently in 454 vs. 460, and if you can confirm this and send me code to verify for myself I'll be happy to investigate.
Dec 15 2009, 5:51 am
The code below by your principles should not work considering it only accesses one with for(var/area/a) but yet, adding overlays does it for all areas, but, creating object for a, does not create object on all areas.

like for example new /obj/Rock(a) after for(var/area/a) does not work, I could do what? for(var/area/a)
for(var/turf/b in a.contents)
new /obj/Rock(b)

and it work, but not the same as overlays? i am just wondering why there is a different behavior in it for overlays specifically, but not for when creating new objects?
Dec 15 2009, 6:16 am
Again, the way areas work is explained in the DM Guide. This is elementary DM behavior and this is not the venue to discuss it. Stick to the topic at hand, please. Either your original project shows a change in behavior across versions or it doesn't, and if it does then that's something I can address if you send me the relevant code and provide info about what I can do to see the difference between versions.
Page: 1 2