View Full Version : Comring Arrays

06-28-2012, 05:01 PM
Is there a way to send an array of data using a comring? I have a list of vectors I would like to pass to a plugin but I am not sure how to go about it. Worst case scenario I can create ~300 arguments for the comring (to send) and place one axis value in each, but I would much prefer a cleaner way to go about sending it. Also, is there an easy way to see how many bytes a string is using? Any help would be greatly appreciated.

internalPoints = array containing list of lets say ~100 vectors
example: internalPoints[1] = <2.4,25,43>

what i would like to do (not sure if a string is suitable for use with arrays):

here is what I could do but wouldnt be ideal:
mycode=comringencode(@"f#300"@,internalPoints[1].x,internalPoints[1].y,internalPoints[1].z.... etc

06-28-2012, 06:36 PM
I wouldn't worry so much how the actual code looks... as long as it works.

But if you don't like the many arguments, then perhaps restructure the code and place all values in an organised array and you'll only have one argument. Ie comringencode(@"f#300"@, allmy300floats). But then you loose the vector data types features. There is no way to eat the cake and keep it (in lscript), unfortunately.

Be that as it may, if you do a search you'll probably encounter writings from a few who have put (lscript) comring through its paces and found it buckles under pressure. It simply cannot handle heavy loads (nor ping-pong). Specifically, if I remember correctly, it was likely the amount of messages passed around that eventually caused the ring to simply stop working. But if I were a betting man, I'd bet the amount of data per message will have (arbitrary) limits aswell. There is also the documented fact that LW will not wait for received messages to be processed. Alot of packets or amount of data sent means alot of to unencode and process before use - this alone (especially at 300 unique values) may take longer than LW wishes to wait. (You'll have to test what the limit might be). Perhaps globalstore then is a better fit - although go easy on the number of keys, as it spams the windows registry. Or use files, trying to keep the read and writes to a minimum.

If you want better communication with less proprietary solutions and hassle switch over to python or c sdk! If you don't care about a slight code stink, it's as simple as placing the code for all plugins in your comring system in the same file(s) and creating a global variable that all of them can access. The only drawback is that you wont be able to mix sdks with this solution as you can with comring. If the communication is for internal use only, this drawback hardly comes into play, as you'll likely code all parts using the same sdk. It's mainly if you yourself want to implement different parts using different sdks, or let others access your ring with the sdk of their choice.

PS. One printed character (ascii) commonly takes up one byte. So I think you'll be safe using whatever string.size() or .count() gives you. (Maybe add one extra character.)

06-28-2012, 06:48 PM
I really need to dive into the Python SDK stuff, it seems it would bypass so many limitations although it would take longer to write scripts. Thank you for the info Dan, it is very helpful :thumbsup:

06-28-2012, 07:01 PM
NP. I'm sorry I'm so often the bringer of potentially bad news. I'm a glass-half-empty kind a guy, I guess... atleast when it comes to LW.