Stateful vs. Stateless

The first concept to understand is that MaxQ is not “stateful”. An application that uses it manages state values, such as “the current time”, or “camera location” and view. MaxQ does not create or manage state on the application’s behalf (with one major category of exceptions.)

MaxQ is stateless for flexibility

Stateless APIs are useable by a wider variety of applications than are stateful ones; stateless APIs make few assumptions about the host application’s use-cases. MaxQ does not make assumptions about how your project works, what needs to be tracked and updated, etc. MaxQ users have powerful building blocks that can be assembled to do many powerful things, but the user must conquer the learning curve, as the user builds the system.

A major exception: Kernel data, which maintains the state of planets, satellites, asteroids, etc over a range of times. For any given time, MaxQ can provide the location, orientation, etc for many objects from the data loaded into it and retained. It can even solve complex interactions between state variables to do such things as finding the times one body eclipses another.

The learning curve is not insignificant… but, it’s bigly rewarding and you’ll find yourself solving astronautical problems you never imagined and building something amazing as your reward.

MaxQ APIs (C++ and Blueprints)

To “use” MaxQ, makes API calls from either C++ or Blueprints. The two APIs (C++ and Blueprints) are 1:1 equivalent, anything available in one is available in the other. And, the application is responsible for managing any variable states between calls. This is made easier by the numerous Datatype Definitions available in MaxQ that may be used to retain data - SDistance, SAngle, SVelocityVector, etc. These data types are fully serializable and network replication-ready.