Bug description: Aprons are not in the same position in the built package compared to where they where placed in the editor. (this issue is getting a bit tiresome…) Please refer to the images below
Repro steps: Created a PRECISE apron matching a PM, for example, and check its position in the built package
I have also noticed that whenever I open the project (Without anything of the project in my comm folder) the PM gets loaded twice, and one instance of it has almost the exact offset the aprons (Or the PM??) has in the built package. If I re-export the PM, or re-build the package in the scenery editor, the duplicate version is gone and the offset too (it lines up perfectly with the aprons again)
Please, can this be fixed and looked at again and once and for all. These UV shifting or Apron shifting issues have been going on for ages now and it’s impossible to accurately place them and make a scenery look like you want if everything is all over the place and different in the version everyone else gets compared to what one has designed in the editor.
I actually don’t think it’s the Aprons that are shifting but the PM instead. I did some further testing and added a new part where the PM fades away so it make the underlying aerial imagery visible. This addition made it clear that it’s actually the PM that shifts ad not the aprons.
Built package: PM lines are offset to the left of the aerial
Thank you for the project, I reproduced the issue and logged it.
However, for your second issue :
I only encountered the issue once.
The thing is, we do not cache PMs or aprons in the project, so my guess is that it might be related to the in-game cache.
I tried to download the package again, extract it, and reproduce the behavior, but I could not.
Do you get this behavior every time you open the project? When you say you “open” the project, do you mean that you only open the project without loading the BGL yet?
What happens if you load the BGL and move the PM? Is the duplicated PM still there?
Also, what happens if you reload a second time the BGL?
I have definitely seen the second issue occur to me. If the PM is moved the duplicate stays in place. It happens with Scenery Objects as well.
I have tried to find a workaround and replicate it, but the issue is inconsistent. Sometimes I load the BGL while in the main menu, and that helps. Other times building the package and reloading the BGL does the trick.
Hi @Boris Thanks for testing and I am glad you were able to repro it! I hope you can fix it as this would more or less break the scenery if the PM doesn’t align with the aprons. I am looking forward to this being fixed
As for the second issue, I have to be honest, as long as the shifting is fixed I don’t really care about duplicate PM after loading the scenery. It would be nice if fixed, but defo not priority. It has being going on for a long time now, but I never reported it because, like I said, it’s not too big of a deal and there are other more pressing issue. But now that I noticed the shift I thought it might have something to do with it so I included it in the report. The only thing that really affects the product is the shifting at the end of the day. However, to give you some more information, the answers to your questions are:
I get this behaviour every time(like really, it is extremely consistent for me) I load the project. Meaning, when I click on “open project” and then open the xml the whole scenery loads (more or less as if it was in the comm folder) without loading the .bgl
If I load the .bgl everything that has loaded disappears for a few seconds and then comes back. The PM is then duplicated as shown above.
When I move the PM, the duplicated one that has been loaded after opening the project stays in place, and the PM loaded from the BGL moves.
If I turn off the visibility of the PM loaded in the editor it disappears, but the previously loaded one stays in place.
If I reload the .bgl a second time more or less nothing changes. The whole scenery just gets reloaded as it would when you open a bgl
I made a video showing the complete flow to illustrate the issue. Maybe that explains everything a little bit better. I also commented on what I am seeing/doing so might be worth watching with audio
I added this to the issue I created. We are not sure yet what is going on, but this will be reviewed and I will let you know once I have more info to share.
For the first issue, the apron shifting position, this is by design, as there will always be small margins of error in the placement of aprons and projected meshes. This is related to how they are stored in the code and this cannot be changed.
At this point, the only thing you can do to mitigate the issue is to remove the green texture under the aprons.
Regarding the second issue, you can enable the “View only current package” option, which may fix the behavior.
I don’t even know what to say to that to be honest. How can it be by design to have something a developer manually places to move away from its intended position? Very frustrating… I have tried hard to think of why you wold have done something like this. Is it performance? And if so what benefit does it have? Because I cannot see how offsetting a PM by 10cm has a performance benefit. I am not trying to be witty here, I am really interested in this as I constantly want to learn new things about game development so I am really curious as to why this would be a design choice.
This is not a small margin of error. We are talking roughly 10 centimetres here…
the green would have been removed anyways. It is just a guide for myself so that I know exactly where to draw the aprons. But that exactly is out of the window anyways since the game shifts the PM. lol
Even if the green is removed, what good does it do? There will still be a 10 cm gap?! I cannot comprehend how this is a thing. Also, it is only the PM that shifts. Always the same amount, always in the same direction. And only in this scenery we are currently doing. This did NOT happen for our last project. So it doesn’t feel like a random margin of error, it’s a consistent offset. These two are very different from one another.
Is there a possibility to somehow load the built projected mesh in the editor and then I draw my aprons on top of that since the aprons themselves don’t move? What I mean by this is: is there a way to make the editor not overwrite a package in the community folder?
Since the offset is always consistent, if I were able to paint the aprons with the built package PM as a reference this would be more or less solved. Not a good solution, but at least a wonky workaround for this puzzling design choice.
I have also found I run into the issue of meshes being left behind when I move them in the scenery editor if I rename the root directory of the package so the Community package is named differently from the project built package.
