It seems that something is a little wonky, good possibility it is just me (Note: that I can only run the Eval on my workstation and my laptop 32-bit is licensed, if that makes any difference)
I have attached the scene max9 64-bit Krakatoa 1.5.1.37520 (also tested in 2010 pflow mapping seems to wirk better but since you guys donât use it, thought better to post a max9 version)
I am saving particles to PRT that have a vertex color channel. This is all okey dokey, works just fine. I add a KCM to grab the vertex color, multiply it by 255, and send it out to the MXSVector channel, PRT particle colors are reflected in the viewport.
BUT when I go back to PFlow and use the PRT loader update op to grab the MXS Vector channel I only get updated vector info for the first particle, I verified with a data op, the rest of the particles are at 0,0,0.
I also noticed a crash on playback when switching the âSave These to PRTâ flow Mapping op to continuous, loading the PRT loader and running back to the"This gets the update MXSVector" flow
Also note that the PFlow PRT Loader Channels DO not show up on xp32 max9 32, max2008 32, not sure about xp64 32-bit versions, havenât checked that yet.
*There is no such thing as âVertex Colorâ in Krakatoa. Vertex Color is synonymous to the Color Channel in Krakatoa.
*So letâs assume you saved a PRT sequence that contains the Color channel taken from the Vertex Color channel. What is the purpose of the Vertex Color Map assigned to the PRT Loader? You donât need that because the PRT Loader will show the Color Channel in the Viewport and the Renderer anyway.
*So the bottom KCM reading the Vertex Color Map and dumping into Color is the same as the default Color->Color flow, just slower (since it has to evaluate a map per particle to get the same value).
*The second KCM that copies Color to MXSVector might be needed if you want to get the Color into PFlow in Max before 2009 with Creative Extension due to the bug in PFlow that Oleg fixed later - it would lock Max if you would check the âColorâ channel in the Krakatoa PRT Loader Update operator. In 2010, it should work immediately and without ANY maps or KCMs - just load the saved Color channel from PRT and it will end up as Vertex Color in PFlow.
*There is also no need to multiply by 255 - we deal with that on the fly when using the Color channel directly.
*Also keep in mind that if you have a Material assigned to a PRT Loader, it totally overwrites anything coming up the stack, so your loaded Colors and your KCMs affecting the color would be usually overwritten by the Standard Material. In your case, the result would look the same (because if the Vertex Color Map assigned to the Diffuse slot), but this just makes it even slower (because you evaluate the map once in the KCM and a second time in the Material, while resulting in exactly the same color you loaded from the PRT already).
*Loaded my own PRTs that contain a Color Channel in the same PRT Loader.
*Disabled the bottom KCM
*Changed to top KCM not to multiply by 255 (because both Krakatoa and PFlow know that Vertex color of 1.0 means 255.0 in 8-bit world and deal with it)
*Added a Krakatoa PRT Loader Birth to the PFlow and picked the PRT Loader
*Checked Position, ID and MXSVector in the Krakatoa PRT Loader Update operator
*Changed the DataOperator to copy Script Vector to Standard Output Vertex Color channel.
*Added a Shape op and set to Box
*Switched Display to Geometry display
*Went to PF Source 01 Properties and checked âVertex Channel Displayâ > âVertex Colorâ.
RESULT: Got the color from my PRT passing through MXSVector to Vertex Color of the PFlow, showing up on the cube shapesâŚ
Since I am using a special patched version of Max 2008, I can do the same directly by checking the âColorâ channel in the Update op.
In 2010, you can do that without any problems, as well as in 2009 with the Creative Extension.
I now went through your process (using the left system to create particles), then loaded them in the right PFlow system.
Was able to reproduce the crash when enabling the MXSVector in the Update.
We will look at it next week to see what is causing it.
The crash appears to be related to the fact you are trying to use the Krakatoa PRT Loader Update without a Krakatoa PRT Loader Birth.
Once I added one, the right system produced the same particles as the left one.
There must be some channel that the Birth is initializing that the Update depends on (like the FileID channel). It crashes very consistently, so it should be easy to track down.
Thanks!
Most likely a remnant for an earlier test. It would slow it down but it shouldnât affect the output since it is the same map as the color channel. I maybe wrong though
I wasnât too clear on this since I was taking the color data and dumping it to the vector channel. I wasnât completely sure that the particle color would retain since usually a render without a color node renders the objects color.
Ok, that is sweet
Will I needed to multiply by 255 to get a proper color value for the Script Operator to control the lights color.
Will do, I have an old habit of dropping a map straight to the PRT and I obviously forgot to remove it when I added the extra unnecessary KCM.
Great! Thanks, just dropped in the PRT Birth and all is happy in the land of blinking lights
(Note: that I can only run the Eval on my workstation and my laptop 32-bit 
is licensed, if that makes any difference)