-
Notifications
You must be signed in to change notification settings - Fork 618
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Receiving grid transformation endpoints error using new TRNX_ID feature #8001
Comments
Thanks for the report. I will take a look. |
@rjokonski Thanks for the nice bug report (Boris Stock nominee!). Should be fixed now. It's hard to maintain backward compatibility with this one. Please confirm this is working for you. |
That's great to hear! Unfortunately I can't personally build it to test right now, but I'll see if somebody in the office can get me a build later in the week. |
We are not advertising this widely, but this may help you guys out. We are pushing up test bundles that pass firebot. See the link in FDS Release Notes. If we pass tonight, the bundles should be up in a day or two. |
That's great news. I'll check in a couple days then! |
I just checked and everything seems to work great now. Thank you. |
Thanks for reporting back. |
I was trying out the new TRNX_ID feature for stretching meshes and while it ran fine with one mesh, once I added another stretched mesh I received the following error:
Here is the file that caused the error:
This problem only seemed to occur if there are multiple TRNX records with different IDs. If I were to stack these two meshes in Z so that they referenced the same TRNX record, I did not have this problem.
I also verified that these same stretch records work correctly if I use the deprecated MESH_NUMBER field instead of the ID system as demonstrated with this file:
Perhaps I'm either misunderstanding how the TRNX_ID feature is supposed to work or maybe the parser is merging all the TRNX records together even if they have different IDs.
NOTE: I also experienced this problem with the TRNY record, but I didn't test TRNZ.
The text was updated successfully, but these errors were encountered: