Why is view capped at 35?

Page: 1 2
ID:260963
 
Aug 25 2011, 7:15 pm (Edited on Aug 25 2011, 7:21 pm)
So I'm working on a game at the movement and I've implemented a zoom feature so the player can choose between 8, 16 and 32 for the map's icon-size variable.

The problem is that when they're at 8, a view of 35 is not enough to fit the whole screen which is really annoying and I can't think of a work around. What is going on and how can I fix this? Thank you.

P.S Yes I like to push mechanics to their limits but this is actually well within reason to ask for 50 at least. Or more cool would be to just take off the cap.
Aug 25 2011, 7:33 pm
The only work around I can think of, is screen objects. However I'm not sure if their limits allow that much distance.
Aug 25 2011, 8:21 pm
In response to Zaoshi
What do you mean?
Aug 25 2011, 8:23 pm
In response to Kyle_ZX
You could add tiles, which are outside range of 35, to client.screen at proper location, it'll look like map. However this is horrible work around for multiplayer game.
Aug 25 2011, 8:26 pm
In response to Zaoshi
Like for(turf in oview(100)), client.screen += turf?

I know that's not the code, but that method?
Aug 25 2011, 8:31 pm
In response to Kyle_ZX
Well since it already supports view of 35, you'll need to add only things outside that range.

for(var/turf/T in (view(40) - view(35))) // not sure if subtraction works here
   T.screen_loc = "[T.x - usr.x],[T.y - usr.y]"
   usr.client.screen += T
   // If it won't show contents of turf you'll need this
   for(var/atom/A in T)
      A.screen_loc = "[A.x - usr.x],[A.y - usr.y]"
      usr.client.screen += A // layers will take care of proper order


However, this will NOT work in multiplayer game. If you need this in multiplayer you'll have to copy atoms either create images. (same object cannot have two different screen_loc for different players)
Aug 25 2011, 8:35 pm
In response to Zaoshi
I'm getting a lot of errors with that and I can't seem to fix it. Please try compile one?
Aug 25 2011, 8:59 pm
In response to Kyle_ZX
Turfs don't seem to have screen_loc variable.
Forget all this... It's not only slow, but also has same limit of view(35) =/

mob/verb/test()
    for(var/turf/T in view(100))
        var/atom/movable/M = new
        M.icon = T.icon
        M.icon_state = T.icon_state
        M.layer = T.layer
        M.dir = T.dir
        M.screen_loc = "[T.x - x],[T.y - y]"
        client.screen += M

        for(var/atom/movable/A in T)
            A.screen_loc = "[A.x - x],[A.y - y]"
            client.screen += A
Aug 25 2011, 9:41 pm
In response to Zaoshi
Sorry for double post.

I just remembered there's block() proc:
mob/verb/test()
    var/const/view = 100
    for(var/turf/T in block(locate(max(x - view, 1), max(y - view, 1), z), locate(min(x + view, world.maxx), min(y + view, world.maxy), z)))
        var/atom/movable/M = new
        M.icon = T.icon
        M.icon_state = T.icon_state
        M.layer = T.layer
        M.dir = T.dir
        M.screen_loc = "[T.x - x],[T.y - y]"
        client.screen += M
        
        for(var/atom/movable/A in T)
            A.screen_loc = "[A.x - x],[A.y - y]"
            client.screen += A


However it look like a minute to complete.
Aug 25 2011, 9:44 pm
In response to Zaoshi
I added this and run it but it crashed my game. Did it work for you?
Aug 25 2011, 9:56 pm
In response to Kyle_ZX
Yes, it did work.
Aug 25 2011, 9:59 pm
In response to Zaoshi
Okay well I tried the code from both posts, just copy pasting and running them as a command from in the game and both caused it to crash.

Thanks for trying to help but it just doesn't work.
Aug 25 2011, 10:04 pm
In response to Zaoshi
Actually I tried it again and waited for about 20 seconds and it did something, didn't work though. It was like it had copied a chunk of the map and moved it northwest-ward. Bizzare stuff. Just so you know I need this to be constant so the player always sees 50 view. This means it can't have any visible delay.
Aug 25 2011, 10:09 pm
In response to Kyle_ZX
That's strange, it doesn't crash for me. But true, it's not suitable for realtime.
Aug 25 2011, 10:17 pm
In response to Zaoshi
Okay, seeing as I was talking about client & world view I thought you understood.
Aug 26 2011, 4:52 am
The only thing you could hope for is posting a feature request, I guess.
Aug 26 2011, 4:53 am
In response to Complex Robot
I guess but I'd really like someone such as Lummox to point me in the right direction.
Aug 26 2011, 5:01 am
In response to Kyle_ZX
A feature request would probably get a faster response than this forum thread.
Aug 26 2011, 5:02 am
In response to Complex Robot
Yea but I also wanted others to see this and maybe get told how I can work around it.
Aug 26 2011, 5:11 am (Edited on Aug 26 2011, 6:53 am)
In response to Kyle_ZX
You can link to the feature request and people can post comments on it there.

Anyways, I'm not really helping, but I don't think there's a workaround. (client.screen won't pan smoothly, and runs pretty slow if it's updated often.)
Page: 1 2