Objects within view dissapear

ID:1540811
 
Apr 9 2014, 6:40 pm (Edited on Apr 9 2014, 7:07 pm)
(See the best response by Ss4toby.)
Image and video hosting by TinyPic
vs
Image and video hosting by TinyPic

Hoping someone is familiar with this and knows how to fix it.

They're just objects & their location is within view exactly at the root. This happens to almost everything on the screen at some angle/distance eventually.

Using BYOND v504
Apr 9 2014, 8:25 pm
Is this .. a bug or something? or something you want to implement?

Tried turning off thread/map threads?
Apr 10 2014, 1:34 am
This could be a problem with the icon sizes. A shot in the dark, but have you tried adding SEE_PIXELS to the sight variable?

mob/sight=SEE_PIXELS


Since the trees location seems to be within view, I doubt this will fix it. However, it would be worth a try..
Apr 10 2014, 2:02 am
Is there anything different about the trees that show up fine vs the ones that don't? In exactly what conditions do the trees disappear?
Apr 10 2014, 4:12 am (Edited on Apr 10 2014, 4:22 am)
@A.T.H.K - Yup, bug. These are just objects, the only difference is that they are all "obj/rpgProp" in dm and icons/names changed at run time.

@Ss4toby - Just tried what you suggested, didn't bring any noticeable change, they still disappear. Every object, smaller & larger icons disappear at some angle/distance.

@MisterPerson - They're all the same object. No difference whatsoever, not even in definition. The condition for their disappearance is moving around them.

obj
    rpgProp
        var
            id = 0 // the id number used in saving.

            tmp/rpgProp/rpgProp // the data type that holds the icon & name it inherits.
            tmp/save_count = 0 // used for saving.
            tmp/width = 0 ; tmp/height = 0 // a record of the height and width of the obj's icon.

rpgProp
    var
        id = 0 // a unique ID number for the data type
        // the following is passed onto obj/rpgProps
        name = ""
        icon/icon
        pixel_x = 0
        pixel_y = 0

Edit Note - Something also weird is that they disappear in groups.
Apr 10 2014, 3:07 pm
Best response
Although this may be unrelated.. What map_format are you using? Default?

I'm honestly thinking this is simply a BYOND bug, but even when there are BYOND bugs I've found in the pass there is always a work around. For instance, you 'could' get the same effect you wish using turf's instead of objects (I'm assuming your trees are simply decoration). Perhaps you should make some dummy trees out of turfs and see if the same thing happens to them?

Honestly, unless someone has run across this same issue, resolved it, and happens to come along this thread you're just looking at a troubleshooting session.

Another issue I can think of (although I doubt this is the case). If you have opacity on the object, and have SEE_TURFS in the sight variable, it can cause some unusual visuals.

Your best bet would probably be to turn off map threads like ATHK suggested.

I'm sorry I can't offer any more help then simply spouting off random things.
Apr 11 2014, 4:58 am
In response to Ss4toby
The map_format is default TOPDOWN_MAP.

The work around discovered is increasing the client.view outside of the actual view of the player's screen. The downside to this is the loss in performance.

In regards to using turfs, I can safely assume it would be just fine if I were to do this. The turf's edges are all images laid at runtime and they never flicker.

No opacity on objects either & turned off map threads as well without positive results.

Right now I am here attempting to just not have to put extra effort into some troublesome work around (when by logic it should function without incident) to be honest.

Thank you for helping nonetheless, i'll keep trying with it and hopefully have a eureka moment.
Apr 11 2014, 12:23 pm


Illustrates the issue in live action.
Apr 13 2014, 6:35 am
SOLVED!

The issue was with step_x & step_y, some of my objects had step_x & step_y in really large numbers like -208/step_x and 253/step_y.

atom
    movable
        proc
            stepToLoc()
                var
                    xx = 0 ; yy = 0

                while(step_x > 32)
                    step_x -= 32 ; xx++
                while(step_x < -32)
                    step_x += 32 ; xx--
                while(step_y > 32)
                    step_y -= 32 ; yy++
                while(step_y < -32)
                    step_y += 32 ; yy--

                loc = locate(x+xx,y+yy,z)

With this procedure I ran an update on every mapped object with that and no more issues exist. Fortunately enough I had seen something similar when we had to create custom pixel movement systems, just popped up in my mind.
Apr 13 2014, 8:26 am
Why would the step_x/step_y values ever have been that high to begin with? Is this because of your custom mapping program you guys use where you can move objects around with the arrow keys?
Apr 13 2014, 12:39 pm
Yep, never would had guessed that problem in a thousand years without some scripts to run and examine XD.. Glad to see you found the problem, and now I know the potential issues oversized step_x/y can cause. For that, I thank you.

By the way, you don't need any while()'s to convert step_x/y within bounds of 32.

var/px=step_x%32
var/lx=round((step_x/32)+(step_x<0?0.5:0))//Not entirely sure if the operator is needed. If not there, 66 will return x 2 and step_x 2 while -66 will return -3 and -2
step_x=px
x+=lx


The above math seems to work.
Apr 16 2014, 4:46 am
@Ter13 - I had changed it from arrow keys to mouse controlled in order to make it more user friendly for players. The conversion from the mouse's location to the object's location created the extra step_x/step_y.

@Ss4toby - You're welcome and thank you, it does, looping is a habit I have.