Area list getting a bit annoying.. in Developer Help

ID:139425
 
Jan 13 2011, 12:33 pm
Code:
world
    New()
        ..()
        var/list_len
        for(var/turf_check in typesof(/turf/system) - list(/turf, /turf/system))
            areas += ++list_len
        for(var/X in areas)
            areas[X] = "open"

var/list/areas = list()

proc
    select_spawn(mob/M)
        for(var/X in areas)
            if(areas[X] == "open")
                M.spawn_zone = "S[X]"
                M.loc = locate(text2path("/turf/system/[M.spawn_zone]"))
                areas[X] = "taken"
                break

If you need me to include more bits of it, just say so.

Problem description:
Well, it's supposed to file through all of the turfs under /turf/system (minus the ones removed) which would leave /turf/system/S1, /turf/system/S2, etc. The list is there so I wouldn't have to have the unnecessary variables.

The problem I have is that the player isn't being spawned and I'm incredibly tired so I don't know if the logic was off on it or not.

Thanks in advance,
-Kumorii
#1 Jan 13 2011, 2:39 pm (Edited on Jan 13 2011, 4:13 pm)
In associative lists you can not give numbers associations and it makes sense that "8=open" can never happen, instead try turning those numbers into text like so:

world
    New()
        ..()
        var/list_len
        for(var/turf_check in typesof(/turf/system) - list(/turf, /turf/system))
            areas += "[++list_len]"
        for(var/X in areas)
            areas[X] = "open"

var/list/areas = list()

proc
    select_spawn(mob/M)
        for(var/X in areas)
            if(areas[X] == "open")
                M.spawn_zone = "S[X]"
                M.loc = locate(text2path("/turf/system/[M.spawn_zone]"))
                areas[X] = "taken"
                break
#2 Jan 13 2011, 2:48 pm
In response to ExPixel (#1)
Worked like a charm!
Thank you very much, bro!
#3 Jan 15 2011, 4:58 am (Edited on Jan 15 2011, 5:03 am)
list[8] = "open" is totally acceptable, contrary to what ExPixel has said. The difference is you are using an index, not a key.

The other difference is that if the index doesn't exist, you will get a runtime error. When using a key, the index is created for you. Luckily for you, you are creating the index beforehand, and, also luckily, the key is the number of the position you're at.

Basically what you're doing is:
areas += 1, areas += 2, etc...
...
areas[1] = "open", areas[2] = "open", etc...
...
for(var/x in areas)
 world << x // outputs "open"


And since there is no association for your "open" key, that code block never executes.

If you replaced for(var/x in areas) with for(var/x=1 to areas.len), your code should work perfectly.

Personally, I don't understand why you're making this so complicated.

turf
 system
  spawn
   var/taken = FALSE


Then all you have to do is find one that isn't taken at runtime.

proc
 get_available_spawn()
  for(var/turf/system/spawn/spawn in world)
   if(!spawn.taken) return spawn

mob
 var
  turf/system/spawn/spawn = null // the spawn point we own

 Login() // or wherever you handle logging in
  ..()
  // ...
  var/turf/system/spawn/available = get_available_spawn()
  if(!available)
   src << "There is no room at the inn."
   del src

  available.taken = TRUE
  spawn = available
  loc = spawn
  // ...

 Logout() // or wherever you handle logging out
  ..()
  // ...
  spawn.taken = FALSE
  spawn = null


No lists to initialize or manage.
Simple, no?
#4 Jan 15 2011, 9:20 am
In response to Keeth (#3)
It was already working my friend, thanks to Ex.
The whole purpose of this was to avoid assigning variables for each little zone. It works great now, and no runtime errors(however I haven't tested it in a multi-player environment yet).
#5 Jan 15 2011, 9:28 am
In response to Kumorii (#4)
I know it's working. I was explaining the issue you were having to begin with.

And why exactly are you avoiding defining a variable on the zone that indicates it's in use? You aren't gaining anything by using the list method. In fact, you are only losing intuitiveness in the process.

I mean, why wouldn't you keep data pertaining to the zone ON the zone? That just makes sense.

Also makes it 300x easier to use.