I’ve started the migration of a Java application using Pulse 2.x to Pulse 3.x and I found the following breaking change:
It appears that the systems (cardiovascular, energy, bloodChemistry, etc.) are no longer accessible from the PulseEngine class. I used these attributes of the PulseEngine class to query for the value of the different data elements. I saw that there is now a PulseEngine.pullData() method that I assume can be used to do the same. Is this the only way we have in 3.x to retrieve data from the engine? Or are the systems still exposed in some way?
The change from 2.x to 3.x did remove the systems from the PulseEngine
The workflow of 2.x was
Specify the data you want from Pulse
Pulse would run, and pull that data back in an array
The Pulse Engine would then use reflection to populate CDM classes with data from the array
Users would get Pulse data via these CDM classes
This is actually pretty inefficient, since you specify the data you want, and its comes back in an array in the order you specified it, then items 3 and 4 are essentially unnecessary and only add to your run time.
The driving change for 3.x was to optimize the data exchange between C++ and Java, and provide the data to the user in a more simple fashion. The list returned contains the values of the data you requested in the units you requested.
But if you are using these CDM classes in a way where its just easier in your architecture to use a set of objects rather than an array, it would be pretty simple to create a new class that encapsulates all the CDM data containers (systems, compartments and substances) and uses reflection to push the array to the CDM classes like it did before. (Bringing back the code that did items 3 and 4 above)
But this would be adding a layer of complexity and time to your program that may not be necessary.
Is this something you are interested in?
The intent of this change was to optimize end users application of Pulse
Thank you for your prompt response. I think it makes sense to keep things at a low level in your APIs and to allow users to build whatever they need on top of that. In my case, I don’t think I need the CSM classes at all and I think I can deal with “raw” data coming from Pulse. I just wanted to know that I was not missing anything important.
The Java interface was my first inter-language interface, and the reflection power of Java let me do some very cool things. But in designing and writing inter-language interfaces for python, and C#, and supporting Unity (and hence fast game frame rates), I really found a ‘simple is better’ approach should be used to conform all inter-language interfaces to the same design (kind of support the lowest common denominator of functionality for all targeted languages). From this decision, the Java interface really got a reworking.
Hopefully this consistency in interfaces allows users to
Write more efficient code with Pulse
To easily support/transition to other languages if needed,
Allow for examples from one language be easily adapted to another language
I am sure there are still improvements that could be made to the interface, and if you run into any weirdness, questions, usability problems in using the API for your application, just bring it up here and we can work out any improvements to help make your life easier in using Pulse!
I would also be interested at how bad the transition from 2.x to 3.x is for you!
And what about PulseEngine.currentTime? Is there any way to ask the engine for the simulation time? Or do I have to keep track of every time I advance the simulation time on my side?