Points inside output from env.mission.drawings DO NOT match the coords of the lines on the map - and even some are just 0,0!?

[TEMPEST.114]

Yet another thing we can't rely on.

The mission has two lines - one red, one green. The start/end lines are on airports and the 'mapx' and 'mapy' perfectly align with each line segments STARTING position, but the rest of the points don't match and some are - for some unfathomable reason - just 0,0.

Now the drawings correctly persist in the miz, which leads me to think the output that you get from env.mission.drawings is broken and giving wrong data.

DrawingsExample.lua DrawingTest.miz

[funkyfranky]

The points are relative to the origin. You have to translate them by (mapx, mapy) to get their true position.

Edited February 22, 2023 by funkyfranky

[TEMPEST.114]

On 2/22/2023 at 4:17 PM, funkyfranky said:

The points are relative to the origin. You have to translate them by (mapx, mapy) to get their true position.

 

Origin of what? Because for two consecutive points they are 0,0 and 0,0 - that doesn’t form a line, yet clearly a line is being rendered. 
 

I’m confused…

[Grimes]

Looks like a mission editor bug of some sort where it inserts an extra point into the table. Possibly with double clicking. If you choose "Select" and move the line segment points then you should find the extra point overlapped with the initial point. 

Anyway origin in this case is relative to the origin of the shape. Its more of a vector art way of saving the data. Suppose it is just going about the calculations backwards from what something like how groups are placed. What I mean is you put a group of units down, each unit has coordinates relative to map origin, if you then move the group leader it'll add the +/- XY difference in coordinates to each unit to "move" them. While with shapes each point is XY relative to the first point. if you move the shape as a whole it just updates the mapX and mapY value saying where the shape starts at. Then the renderer takes that information and renders the shape as needed. A group with 10 units needs to update 10 sets of coordinates, a shape with 1 points needs to update 1 coordinate set. 

 

[funkyfranky]

Yeah, I also just noticed the two points at (0,0) in the points table, which seems wrong as @Grimes already said.

What I meant is, that in order to get the points where you drew them you need to apply the following transformation

x=x+mapX
y=y+mapY

[TEMPEST.114]

11 hours ago, Grimes said:

Looks like a mission editor bug of some sort where it inserts an extra point into the table. Possibly with double clicking. If you choose "Select" and move the line segment points then you should find the extra point overlapped with the initial point. 

Anyway origin in this case is relative to the origin of the shape. Its more of a vector art way of saving the data. Suppose it is just going about the calculations backwards from what something like how groups are placed. What I mean is you put a group of units down, each unit has coordinates relative to map origin, if you then move the group leader it'll add the +/- XY difference in coordinates to each unit to "move" them. While with shapes each point is XY relative to the first point. if you move the shape as a whole it just updates the mapX and mapY value saying where the shape starts at. Then the renderer takes that information and renders the shape as needed. A group with 10 units needs to update 10 sets of coordinates, a shape with 1 points needs to update 1 coordinate set. 

 

 

10 hours ago, funkyfranky said:

Yeah, I also just noticed the two points at (0,0) in the points table, which seems wrong as @Grimes already said.

What I meant is, that in order to get the points where you drew them you need to apply the following transformation

x=x+mapX
y=y+mapY

Thank you both. 

 

In both cases, there were two points directly over each other - ODD that I would have mistakenly 'double clicked' at the exact point when drawing two different lines at two different times - so I think some more investigation into this as it might still be a ME bug, but after removing the 'extra' point then the 0,0 was gone and now I understand that each is an offset from the original map x and y (not clear in the documentation ) then I can now use them. Thanks.