This is part 5 in my series of blog posts on RTI RID configuration tips. Check out the previous posts in this series, and stay tuned for more to come.
Part 1 – RID Consistency Checking
Part 2 – The Advantages of MTL
Part 3 – Utilize Environment Variables
Part 4 – Modularizing Your RID
Change RID parameters programmatically in HLA 1516-2000 and HLA Evolved
The RID file isn’t the only way to specify RTI configuration parameters. Many people don’t know that RID parameters can also be specified programmatically by the federate. Unfortunately there was no mechanism for this in the HLA 1.3 API, but in 1516-2000 such a mechanism was added, and the same idea was kept in HLA Evolved (though the API for it changed). In HLA 1516-2000 and HLA Evolved, the standard included a way to pass a string or series of strings to the RTI to be used in RTI initialization. Since RTI configuration is different for every RTI, the standard left it to RTI developers to determine how these strings were used. As a result, this is one of the few areas of the API that will work differently from RTI to RTI. So if your federate needs to operate with multiple RTIs, you may want to consider other configuration options or have a switch in your code based on what RTI you are using. So how can you use these strings with the MÄK RTI?
In HLA 1516-2000, these settings are specified when the RTIambassador is created. The RTIambassadorFactory::createRTIambassador function takes as an argument a vector of strings. You have a couple of options. The first is to specify a completely new RID file by overriding the RTI_RID_FILE environment variable. If you’ve created a specific file for one of your federates, this would be one way of making sure it is always loaded.
std::vector<std::wstring> args;
args.push_back(L”RTI_RID_FILE C:/MAK/vc8/makRti4.0.4/ridProg.mtl”);
std::auto_ptr<RTIambassador> rtiAmb = rtiAmbFactory->createRTIambassador(args);
That might be useful once in a while, but in my last few posts I’ve discussed ways of eliminating duplicate RID configuration, and this just adds another full RID file into the mix. It would be better to just override those federate-specific RID parameters we need to override, so that all of the federation-wide parameters will be pulled from our RID file. Not a problem, we can do that, too. (You can also do both. Simply specify a new RTI_RID_FILE in the first string, and override specific settings in the subsequent ones.)
args.push_back(L”(setqb RTI_processingModel 2)”);
args.push_back(L”(setqb RTI_enableWarningsForDisabledServices 0)”);
std::auto_ptr<RTIambassador> rtiAmb = rtiAmbFactory->createRTIambassador(args);
But maybe you read my last post about modularizing your RID into sub-RIDs. As a result, you’ve created new sub-RIDs for federate-specific parameters. You could create a new environment variable to specify which federate sub-RID to load, but that would require making sure to change the environment for each federate you start. Obviously that wouldn’t be hard to do if you setup scripts, but alternatively you could do this in your federate code. Basically we can just remove the federate-specific load command from the RID, and move it to the federate code. Now the federate itself is telling the RID parser which sub-RID to load. Notice we continue to use the ridDir variable. This is because programmatically specified parameters are loaded after the RID file settings, so this variable should already be set.
args.push_back(L”(load (string-append ridDir \”rid_loggerSpecific.mtl\”))”);
std::auto_ptr<RTIambassador> rtiAmb = rtiAmbFactory->createRTIambassador(args);
So how do you do this if you’re using HLA Evolved? Unfortunately in the current release we don’t support all of these features. Currently you can’t use the RTI_RID_FILE command to specify an entirely new file, nor can you use any command other than setqb. That means loading sub-RIDs from within your HLA Evolved code won’t work. These features will be added to RTI 4.1. In the meantime, though, you can still override any specific RID parameters you want with setqb commands. In HLA Evolved this is done through the optional local settings designator argument which is specified in the connect service call. It’s only a single string, so you can just list all of the settings one after another.
rtiAmb.connect(fedAmb, HLA_EVOKED,
L”(setqb RTI_processingModel 2) (setqb RTI_enableWarningsForDisabledServices 0)”);