ADE-GP Positioning within the GP Editor

#1
Sequence when editing.

Initial entry (What is that dot?):



Slight roll of the middle button and I see the polygon off to the right:



Clicked on the horizontal scroll slider and I now see the texture:



Zoom-out with middle-button and the polygon moves to the left:



It seems that after a zoom I need to reposition the polygon.

Edit. Sorry, this is on my development machine running XP.
 

tgibson

Resource contributor
#2
Hi,

Also on XP, using 0.35 and 1.60.4854.

I'm having the same problems - the zoom buttons or mouse scroll wheel change only the size of the object rather than the size of the entire screen, and I can't see the texture until I zoom in large enough to get scroll bars, and then move them.

The Texture Editor seems OK with added polygon textures. :)

Hope this helps,
 

tgibson

Resource contributor
#3
Once I used the Texture Editor in v 0.35 I reverted to v 0.33. Then I could use my new texture to create a polygon and it displays fine in FS. The new texture was properly copied to the texture folder. Even deleting an object in ADE stopped that texture from being copied at compile - nice job. It doesn't actually delete that texture from the FS texture folder though (which is a good thing, in case multiple airports use the same folder).

A suggestion - some things you might want to think about adding to the manual:

1. Suggest that users name their textures for ground polys starting with gp_ as you have done, to keep them all together in the FS texture folder.

2. After finishing an airport project, delete all gp_ textures from the FS texture folder and compile the airport again, in case you have deleted a GP object and now have unused textures in that folder. If the FS scenery folder contains more than one airport, compile all of the airports to make sure you have copied all the required GP textures.

Thanks,
 

tgibson

Resource contributor
#5
A problem with the new Texture Editor. I wanted my new texture to be at the top of the list, so I chose position 1 when adding it. It is indeed at the top of the list, but that *removed* the original #1 entry (gp_PatternedLines_40F) from the list and now I get a GP Editor crash each time I try to edit an object that uses that old texture (Index out of Range).

I assumed it would insert my new texture at the top of the list and all the others would move down one spot?

Thanks,
 

tgibson

Resource contributor
#6
PS. I manually replaced gp_PatternedLines_40F as #2 in the Texture_Def.txt file and now it's working fine.
 
#7
Hi,

Mine is at the bottom of the editor and apparently it works:

Forget about the rest of the picture because what is relevant only is that I managed to get the new texture in (although not really very well aligned (but that is another story).
The weird thing is that contrary to what I expected instinctively when repositioning the vertices, they stay the way they were and it is the texture that is turned the correct way:confused:.
 

gadgets

Resource contributor
#8
A problem with the new Texture Editor. I wanted my new texture to be at the top of the list, so I chose position 1 when adding it. It is indeed at the top of the list, but that *removed* the original #1 entry (gp_PatternedLines_40F) from the list and now I get a GP Editor crash each time I try to edit an object that uses that old texture (Index out of Range).

I assumed it would insert my new texture at the top of the list and all the others would move down one spot?
It should simply have been added, not replace the exiting one. This too will be fixed.

Tom, in another post, I asked you to elucidate the issues between 0.33 and 0.35. I assume the issues to which you were referring are those discussed herein. If so, no need to respond to the other post.

As for the other issues above in this thread, there is a problem with the scrollbars. (I discovered it late yesterday. Since no one was complaining, I hoped I could fix it - today - before anyone else noticed. So much for that idea!)

Also, at the moment, when you copy an object, the editor is interpreting that as a move and, hence, displaces the vertices relative to the texture (which probably shouldn't be done anyway.) Hopefully, it will be easy to fix.

Another update coming.

Don
 

tgibson

Resource contributor
#9
Hi,

Yes, it is what I described in the other thread - the zoom behavior in 0.35 is totally different than in 0.33. In 0.33 the texture and the vertices zoom together, retaining the texture mapping proportions. In 0.35 the vertices zoom, but the texture remains at a constant zoom. This causes the texture mapping to be spoiled with every zoom.

Hope this helps,
 
Top