Functions as expected, no anomalies found.

Is there a way to speed up the export? The crude solution from #1037 was a bit faster at full decimal length (which was like 15 places), but it hangs for about a minute at just 6 decimal places with this pull

Do you actually desire to export 6 decimal places? If so I would be intrigued to hear why. It's hard for me to understand how that would be valuable.

Is there a way to speed up the export? The crude solution from #1037 was a bit faster at full decimal length (which was like 15 places), but it hangs for about a minute at just 6 decimal places with this pull

Well two things: your code from #1037 did not include the exponentialFormat calculation, which saves your code some while-loops + I just continued to use the shortDecimal method inside decimalFormat while you just formatted the string as a full float. I must say I'm not entirely sure why the shortDecimal is so elaborate and what advantage it brings to using something built-in from Java. I'll take a look at that.

But I do not see export delays longer than half a second, so I'm a bit confused why you have such huge delays? I used 'A simple model rocket' and exported all variables with 15 decimal precision and got an almost instant export.

@Sparrowhawk120 I made some changes to the doubleToString code, hopefully resulting in a performance improvement for you. Could you check with this jar file whether anything has changed for you?

@SiboVG I timed an export of Time, Lateral Dist, Lat, & Lon, and it still took 59 seconds to do an export at 6 decimal places with comma delimiting. Do you want me to send the .ork file I used?

Do you actually desire to export 6 decimal places? If so I would be intrigued to hear why. It's hard for me to understand how that would be valuable.

@neilweinstock I'm trying to start developing a visualizer for the 6DOF so I can use the Monte-Carlo method to create a landing splash zone. This would help for much larger-scale flights requiring FAA permits without the irritating monthly subscription of Rocksim Pro.
6 decimals on lat/lon gives 10cm precision so I guess it isn't too necessary (4 or 5 would suffice), I'm just working with that level of precision because I'm running these experiments on a fairly small launch field so the accuracy is useful albeit not necessary to that degree

@SiboVG I timed an export of Time, Lateral Dist, Lat, & Lon, and it still took 59 seconds to do an export at 6 decimal places with comma delimiting.

How are export times for 22.02.beta.03? And do the results differ when you check/uncheck the use exponential notation? Also: what are the export times for your code from #1037?

Oh yeah and do the results change with the latest unstable whether you export with 6 decimals or 15 decimals?

How are export times for 22.02.beta.03? And do the results differ when you check/uncheck the use exponential notation? Also: what are the export times for your code from #1037?

I'm gonna preface this by saying the following results are incredibly perplexing to me because both with #1037 and the original 22.02.beta.03 I didn't previously have much issue with exporting. I'm not sure if this is a product of running the jar with Java 17, or if something is wrong with my system in some other way.
.
.
.
In the beta without the custom places merge (22.02.beta.03) it took 60 seconds to export.
56 seconds with exponential notation on your jar file (6 decimal).
77 seconds with 15 decimals on your jar file (no exponential).

Similar behavior was observed using the code in #1037

Similar behavior was observed using both my .ork file and the "Simple Model Rocket" example

Thanks for the test results. It's indeed very strange that you have this issue. As I've said, I don't have any issues with it at all (export times all < 1 s). It may have something to do with the fact that we don't use the OpenCSV library for exporting to CSV, which may be more efficient than the custom CSV export (I know from a prior project that OpenCSV makes huge changes in delay times for reading CSVs, so maybe the same holds for writing CSVs).

I'll file a new issue for it, thanks again for bringing it up.