Dynamic Lighting

ID:1484858
 
Jan 30 2014, 12:09 pm


Problem description: I was using FA's Dynamic Lighting system, and I seem to have encountered this RTE. I was using the day & night demo.

runtime error: type mismatch: "42x25" + 1
proc name: apply (/light/day_night/apply)
source file: demo.dm,33

Having gone to the problem child, it seems to be this:

                for(var/shading/s in range(m.client.view + 1, m))


Can anybody help me fix this? I'm actually confused as to where I should go from here on.

Link: http://www.byond.com/developer/Forum_account/DynamicLighting
Jan 30 2014, 12:37 pm
client.view is set to a string "42x25" and being it's not an even view port (where both numbers are the same thing) it's not being internally converted into a number. You can't add a number to a string in this way and expect it to work, if the view port was square it would work fine.

You'd probably have to manually handle a one-up increase of the view port, if your client.view doesn't change at all you can just pass "43x26" to the first argument of range() and be set. If it changes, you'll have to parse out the numbers, add to them and stick them back together.
Jan 30 2014, 12:40 pm
EDIT: Nadrew beat me to it, but I'll leave this post so you can benefit from my code snippets.

You set client.view to "42x25" which is a valid value, but the demo you're using doesn't support this.

Possible solutions:

1. Set client.view to a number instead of using the "WxH" format.

2. The following should fix your situation:

                for(var/shading/s in range(42 + 1, m))

3. You can use this proc and call m.client.getView() instead.

/client/proc/getView()
    var/pos = findtext(src.view, "x")
    if (pos > 0)
        var
            v1 = text2num(copytext(src.view, 1, pos))
            v2 = text2num(copytext(src.view, pos + 1))

        if (v1 > v2) return v1
        else         return v2
    else
        return text2num("[src.view]")



                for(var/shading/s in range(m.client.getView() + 1, m))
Jan 30 2014, 12:50 pm
Keep in mind Sir Lazarus, he'd be able to interact with things outside of his actual view+1 using your snippets, since you'd be effectively squaring-out the range() call, which does support the "[w]x[h]" notation just fine, he was just trying to do "string"+num and had it runtime on him. Your getView() also suffers from the same problem, consider this case;

The player can see 42 tiles wide but only 25 high, you'd be giving them access to things not only 42 tiles to the sides, both 42 tiles up and down, that's a lot of tiles the player shouldn't be interacting with.

You could use the basis of getView() to devise a proc to increase the dimensions of a non-square view and return the proper string though.

proc/addView(view_string,increase=0)
    if(!view_string || !increase) return 0 // Still works for negatives
    var/pos = findtext(view_string,"x")
    if(!pos) return view_string
    else
        var
             view_width = text2num(copytext(view_string,1,pos))
             view_height = text2num(copytext(view_string,pos+1))
        view_width += increase
        view_height += increase
        return "[view_width]x[view_height]"


Written on the fly, may need tweaking.
Jan 30 2014, 1:08 pm
Uhh...Sorry, but I don't quite understand Nadrew's second post x.x
Jan 30 2014, 1:29 pm
The demo isn't designed for non-square views.

The workaround: make sure your view is square (if you added something like client/view = "42x25" then delete it).

The simple fix: change m.client.view + 1 to "44x27" and remember to update it if you ever change client/view again.

The less simple fix that you won't need to remember to update: what Nadrew or Sir Lazarus said.
Jan 30 2014, 1:45 pm
Erk. Sorry, hit another road block. May just be me not doing things correctly, but I received this (having followed Immibis):

runtime error: The first argument to the light object's constructor must be the atom that is the light source. Expected atom, received '' instead.
proc name: New (/light/New)
source file: light-source.dm,52
usr: null
src: the day night (/light/day_night)
call stack:
the day night (/light/day_night): New(null, 3, 1)
Kboy33 (/mob): loadslot1()

CRASH("The first argument to the light object's constructor must be the atom that is the light source. Expected atom, received '[a]' instead.")
Jan 30 2014, 2:17 pm
In response to Kboy33
Did you read the error?
Jan 31 2014, 7:22 am
In response to Kaiochao
Yes, but I don't understand it.
Jan 31 2014, 7:43 am
In response to Kboy33
Which part do you not understand? Argument? Constructor?

According to the call stack, you're passing null as the first argument to /light/day_night's constructor, New().

The error also says that it's happening on line 52, so let's see what's going on around there.
Jan 31 2014, 10:20 am
In response to Kaiochao
Sorry but I don't understand ANY of the error that I posted. That was line 52 ^^.
Jan 31 2014, 10:42 am
In response to Kboy33
Actually, it looks like you're loading this light source.

Forum_account's libraries don't seem to play very nice with saving and loading (not enough tmp use, I suppose), so loading the /light of your player causes it to be implicitly created, calling its New() with default arguments, which is bad for its initialization process.

It's a tricky problem with many solutions that would probably involve modifying the library itself.
Jan 31 2014, 10:48 am
In response to Kaiochao
Erk. Do you have any alternatives that I can use? What I liked about FA's library is that it was nice and smooth (angular at that too) - not blocky. It also enabled you to use things like torches which illuminated the area you were in. I found that really appealing.