When saving a BIN sequence using X-Particles cache object, and then loading it using the PRT Loader, the particles are scaled 1/100. You need to go to the PR loader Coordinates Tab in the Attribute manager and set the Scale 100 in each axis.
When saving via the PRT saver, loading has the proper scale.
Attached a C4D file and two Particle Cache files, one from XParticles and one from PRT Saver.
If you look at the Coordinates of the “Krakatoa PRT Xparticles”, the Scale is 100,100,100 to match the size of the other.
Krakatoa PRT Loader.zip (332 KB)
Yeah, this is rather a scaling problem of the bins I guess.
I suspect that X-Particles is scaling the particle positions from Centimeters to Meters because fluid simulators in general and RealFlow in particular tend to work in Meter/Kilogram/Second (SI) units. Krakatoa does not make any assumptions about the scale though, so if your scene is in Centimeters and a particle has a position of 100,200,300, it will be exported as 100,200,300 and not as 1,2,3 to match the Meters of RealFlow. It is difficult to say which way is better - I think that X-Particles is doing the right thing scaling down to Meters because saving BIN files usually implies the intention to load back in RealFlow. On the other hand, in your case it might feel like a bug, although it might be As Designed.
FYI, for our own PRT files, we just recently added metadata to the PRT 1.1 file format that allows the automatic re-scaling of data when loading, but RealFlow does not support that 1.1 specification yet (might support it in the near future though). I don’t believe the KC4D PRT Loader supports the 1.1 spec either at this point, but if it does not, we should fix it.
What is your reason for saving BIN files in the first place? Is there anything BIN files give you PRT files don’t?
X-Particles have 3 save Cache modes:
- X-Particles (I have no idea what that is, but probably proprietary)
- Realflow BIN
- Realflow BIN (2013)
No PRT from X Particles. Maybe something you can discuss with them if you can.
In regards to my bug reports, I’m a mere beta tester and just testing whatever I come across. Most times I have no particular reason of doing anything 
Sorry for my stupid question. But I have been using C4D / KC4D for only 10 days, and haven’t even seen X-Particles yet, so you are the teacher here when it comes to C4D particle workflows. I know my Krakatoa outside of C4D though 
So my question was - are you saving to BIN files so that X-Particles could use them as cache for faster playback, or are you saving BIN files so that Krakatoa could load the data for faster rendering? In the latter case, saving using the PRT Saver as PRT sequence would potentially give you smaller files which would not have the scale issue. If the BIN files are needed for operating X-Particles though, then it would make sense to keep on using them, of course. I would also suggest exploring the X-Particles own cache format. If you are trying to cache the X-Particles for faster playback, you would not need PRTs or BINs are you could render them directly in Krakatoa, and chances are the X-Particles proprietary format would be better optimized for that purpose than BINs which are slow and bulky.
Hope this clarifies the confusion.
There is no sense in saving bin files from X-Particles for further use inside Cinema 4D. Lots of Channels go missing beside the scaling issue, which really isnt that annoying 
I would prefer to save the X-Particles directly with “our” PRT Saver anytime. I didn’t compare them to the internal compressed X-Particles format but am convinced this is the most elegant solution of a workflow.
Just be sure to tick the respective channels in the PRT saving options as well as the proper definition for them.
Thanks for the reply Boris, but I’m dead serious when I say “for no reason”
Basically, at this point all I’m doing is trying anything I can to “break” the Krakatoa - C4D bridge, in order to expose any bugs. This is what beta testing at Maxon has taught me
Very soon, when I’m more comfortable with Krakatoa, I will start making “working” particle setups, instead of trying to break it.