Wire: egpOrder buggy/confusing to use

Created on 10 Sep 2016  路  5Comments  路  Source: wiremod/wire

Can't figure out how to make it so two boxes created before a few other objects can be reordered to be infront of them.

EGP:egpClear()
EGP:egpBox(1,vec2(100),vec2(130,65))
EGP:egpBox(2,vec2(100,165),vec2(130,65))
EGP:egpColor(1,vec4(255,127,127,127))
EGP:egpColor(2,vec4(127,255,127,127))
for(I=0,3){
    EGP:egpCircle(I+3,vec2(100)+vec2(I%2,floor(I/2))*130,vec2(10))
}
EGP:egpOrder(1,7)
EGP:egpOrder(2,8)

I tried various variations of orders to get both boxes on top, however only one ever works, commenting out egpOrder(1,...) makes the only second box on top, otherwise only the first box is on top. So there is either some non-obvious way to make it work or a bug preventing multiple reorders.

I am aware of how it gets clamped here, but i cannot seem to find a solution to put BOTH boxes infront of the circles, apart from switching up the creation order.

Watching the client side, it seems only one message to change order goes through to the client, so there might be a error on the sending side but i cannot figure out where/how it gets called/triggered.

Bug EGP

Most helpful comment

I tested using the code in the OP and it worked fine as far as being able to place the boxes above the circles. The issue was the boxes were transparent, so I had to make them not transparent to see that it actually worked. However, it doesn't work entirely. If you want to move the green box above the red box, well, you can't (might be able to with some timers and other trickery). The reason is that the server's and client's RenderTable become different after trying to order the objects in this way, due to the way it does the ordering. Just bad implementation, really. On the server, it changes the order immediately, but on the client, it steps through each edited object and changes the order for that object during the iteration, which means the order in which the egpOrder function is called is different for server/client. I'll attempt to fix it,

EDIT: yeah the way the order thing is implemented is completely fucked. Obviously, I had no clue what I was doing when I created it lol

All 5 comments

Duplicate. See #1057.

I wouldn't call it duplicate, it only "works" under very dubious circumstances which are in no way obvious.
See my example, i cannot find a way to make 2 things "on top", apart from bypassing egpOrder alltogether.

Also that Issue is only labeled as Enhancment and has had no activity for almost nine months.

@Divran I can't tell if this is a bug or it's just the egpOrder API is so bad that it looks broken - can you figure it out and then either close this or not?

I tested using the code in the OP and it worked fine as far as being able to place the boxes above the circles. The issue was the boxes were transparent, so I had to make them not transparent to see that it actually worked. However, it doesn't work entirely. If you want to move the green box above the red box, well, you can't (might be able to with some timers and other trickery). The reason is that the server's and client's RenderTable become different after trying to order the objects in this way, due to the way it does the ordering. Just bad implementation, really. On the server, it changes the order immediately, but on the client, it steps through each edited object and changes the order for that object during the iteration, which means the order in which the egpOrder function is called is different for server/client. I'll attempt to fix it,

EDIT: yeah the way the order thing is implemented is completely fucked. Obviously, I had no clue what I was doing when I created it lol

Thanks for investigating.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CaptainPRICE picture CaptainPRICE  路  3Comments

CaptainPRICE picture CaptainPRICE  路  3Comments

TAbdiukov picture TAbdiukov  路  5Comments

Etothepowerof26 picture Etothepowerof26  路  5Comments

CSGKCJDBCPQ2K8 picture CSGKCJDBCPQ2K8  路  7Comments