JTLS-GO

JTLS-GO Frequently Asked Questions

Conference Image

Almost every day, the JTLS-GO development team receives questions from clients and potential clients concerning specific capabilities of JTLS-GO. Answers to these questions can take time and effort to properly research and thoroughly and understandably write. The purpose of this page is to provide the information we feel would be of interest to everyone interested in JTLS-GO.

If you have any additional questions, or if these answers do not completely provide the desired information, contact the JTLS-GO development team directly at jtlsgo@rolands.com for more information. We will address your questions until you are fully satisfied.

Which versions of JTLS-GO are currently supported by Valkyrie?

At any point we have three supported versions of JTLS-GO up and running, and a new version in the wings. Before explain what is supported, the reader needs to understand our version numbering system. Each JTLS-GO version has a four digit version number.

Digit Explanation
1st Digit (i) This is the major version number. A change in the major version number indicates that the system concept of JTLS-GO has undergone a significant change. When making a significant change, users should expect a longer than normal time to assimilate and fully understand the new capabilities and system structure of JTLS-GO. A larger than normal database contgent changes should be expected. For example JTLS 3.0.0.0 was the version number when JTLS moved to the new web-based user interface.
2nd Digit (j) This is the main version number. A change in the main version number indicates that the JTLS-GO has signficiant new model functionality that required new data. A change in the main version number means users must upgrade their database, an automatic procedure delivered with JTLS-GO, and review these databases to insure that their scenario use the new functionality as desired and needed.
3rd Digit (k) This is the update version number. A change in the update digit indicates that JTLS-GO is being released with "bug" fixes found by our test team and other users. It is possible that a few minor functional improvements have been added to the model, but absolutely no data changes were needed. Thus, the database structure for JTLS Version 3.4.1.0 is identical to the database structure for JTLS Version 3.4.0.0. Although each user must individually decide whether to implement an upgrade version, it should be noted that as a "bug" fix release, it represents what Valkyrie Enterprises LLC believes is the most reliable released version of JTLS-GO.
4th Digit (l) This is the interim version number. A change in the interim digit indicates that an unofficial release of JTLS-GO is being used. If an individual user has a specific problem just prior to an important exercise Valkyrie Enterprises LLC may fix the issue and provide the fix on a quick reaction test cycle. The issues addressed in the interim release will be formalized and included in the next update release. Only the user requiring the quick fix receives notification of the release availability.

Given this background information, the versions that Valkyrie currently supports and has immediately available for debug purposes are defined as follows:

  1. jtlsold - This is the last bug release of the previous major version. Currently this is the JTLS 4.0 series of the system. The last version of this major release is 4.0.6.0.
  2. jtls - This is the last official release of the current major version. When an official release is prepred, we increase the update or 3rd digit of the version number
  3. jtlsrel - This is the current status of the currently available major release. Valkyrie periodically finds errors and issues with the current release and this version of the software has those problems fixed. Approximately once a quarter, we package this version of the software into a bug release and distribute it to all currently JTLS-GO customers. At that point in time, this version is moved into the jtls account. If someone has an emergency fix needed or a specific exercise related change, we make the fix here, test it, and send it out to the client that needs the emergency update of the system. When that happens, we increase the interim (4th digit).
  4. jtlsdev is the next planned major release. As soon as the database is closed on this, we will send our Beta version of this next major release to anyone that requests a preview of what will come. The version we are currently working on, JTLS-GO 5.0, is a MAJOR version, which means that the first digit is being changed.

We do urge clients to load the latest bug fixes when they are released. If this is not done, we can load any released version of JTLS-GO to help with debugging. This process takes about 48 hours to load into our jtlstest account, at which point we can help debug any reported issues. This process is fully covered under an active maintenance contract for any version of the current release. This process is also fully covered for the previous release, but only for one year after the release has been moved to the jtlsold status. After that time and for any earlier versions there would be a charge for Valkyrie to help debug the outdated version.

How does JTLS-GO handle Communications Jamming for Air and Land?

Communications Jamming Air and Land: JTLS-GO represents communications jammers. These jammers can be owned by any ground unit or naval unit. They can also be loaded on an aircraft and if you fly an Electronic Combat mission, the jammers will be turned on and affect the battlefield in the same manner that the land or naval based communications jammers affect the battle field. When turning on a communications jammer, the player must specify the type of jamming that is desired. There are three types of jamming explained below.

  1. Side Jamming- All orders to the units take longer to get to the units. All queries for information from the units take longer. the length of time depends on data. Within JTLS-GO a jammed communication, will always get through, but will take longer to get through. The idea is that a communication specialists can always work their way around jamming - even if it means sending a messenger to get the information through. The length of time delay, as with absolutely everything in JTLS-GO is data and is changeable before or during an exercise.
  2. Tactical Communication Jamming For A Specific Unit - All orders to and from the unit are delayed, but the jamming also impacts their ability to fight. Again the amount of the impact is part of the database.
  3. Internal Communication Jamming For A Specific Unit - It affects combat and the time it takes to do all internal activities, such as aircraft turn time, combat system maintenance, requisitioning supplies, loading/offloading convoys. If it takes time to accomplish the activity - it is degraded by the internal unit communications jamming.

How does JTLS-GO represent Radar Jamming?

Radar Jamming: As with the communications jamming, radar jammers can be owned by ground or naval units and placed on Electronic Combat missions. Radar jamming only affects Air Search Radars and Surface search radars detecting naval units. We do not represent radar detections of ground forces. Radars have a "power" and jammers have a "power," we compare the power of the radar signal from the radar to the object being detected and back to the radar against the power of the jammer from the jammer to the radar. We use a simplistic 20LOG power degradation function for the jammer to the radar and a 40log function from the radar to the object being detected and back to the radar. Once these computations are done, there are three possibilities described below.

  1. The jammer power at the radar site is greater than the return signal plus MIN JAMMING POWER (a data parameter). In this case, no detection is possible. Assume jammer power at the radar is 20 and the return signal power is 10 and the MIN JAMMING power is 6. 20 > 10 + 6 - no detection feasible.
  2. The jammer power is greater than the return signal but not enough to stop the detection. In this case, the radar has a jamming factor as part of its data. This factor is applied to the probability of detection - making it possible but less likely that the detection will occur. Assume jammer power at the radar is 13 and the return signal power is 10 and the MIN JAMMING power is 6. 13 < 10 + 6 but 13 > 10 - reduced detection feasible.
  3. The jammer power is less than the return signal. The jammer has no affect on the ability of the radar to detect the object. Assume jammer power at the radar is 3 and the return signal power is 10 - detection follows the normal probability of detection value. Detection is still not for certain but it is not affected by radar jamming. This still makes our stealth aircraft more difficult to detect.

Does JTLS-GO represent Military Information Support Operations (MISO)?

Military Information Support Operations (MISO): JTLS-GO still only represents PSYOP, the lesser but included capability within the new MISO definition. We represent two ways of conducting PSYOP - delivery of leaflets and the use of broadcasts, whether it represents loudspeakers, radio broadcasts or even television broadcasts.

  1. Leaflets can be delivered via aircraft, artillery or even surface to surface missile fire. Leaflets are specified for a specific faction, which represents a group of units that have a common language and set of values and standard operating procedures. There is data in the database that indicates how effective the leaflets are to the faction for which they were designed, for other faction on the same side as the designed faction, and for units on other sides with a relationship of ENEMY or SUSPECT. The leaflets are delivered to a specific unit. The unit picks up some of the leaflets - number picked up by each person is a database parameter. Those that are not picked up can be picked up by other units in the area or passing through the area. Based on the type of terrain, the leaflets will last for a database specified period. More data indicates how effective the leaflets are and they degrade the unit's overall effectiveness. As effectiveness goes down, the ability of the unit to fight degrades, the time it takes the unit to conduct internal tasks increases. The model also calculates based on the unit's PSYOP value, how many people will simply walk away, i.e. go AWOL on an hourly basis. As the number of people is reduced, the unit's ability to fight continues to degrade.
  2. Broadcasts work in a similar manner as radar and communications jammers. They can be owned by a unit or a naval unit. They can be placed on board an Electronic combat mission. Again the player must specify the faction than is being targeted. Other units can be affected based on the same data as for leaflets. In other words, units in different factions but on the same side and units on other sides with a relationship of ENEMY or SUSPECT can all be affected. Here the length of time is used along with the data to determine the impact of the PSYOP broadcasts.

Does JTLS-GO represent Enemy/Friendly Intercept of Orders?

Enemy/Friendly intercept of orders: For security reasons, JTLS-GO represents this concept on a very rudimentary level. Every side has data that indicated the probability with which the side has the ability to obtain enemy or suspect order information. We do not ask how the information is obtain. It may be because we are tapping phone lines, intercepting cell phone calls, or hearing through the proverbial grapevine in a local bar. It is a simple number probability number. If set to .05 - 5% of the orders sent to enemy units will be obtained by your side. You will get a message in the message browser summarizing the order information. you can then use this information to help determine what the enemy is planning

When pushing orders, why is the JTLS-GO situation not perfectly recreated?

The JTLS-GO order push capability was designed to automatically re-enter orders previously submitted by players, if for any reason, the JTLS-GO game needs to be backed up to apreviously saved checkpoint and replayed. It was intended to be used only to replay the orders since the last checkpoint, but numerous users have also used the capability to replay major portions of a given exercise. The order push capability does not always replay the situation exactly. The longer the period of replay, the more likely a user will see divergences in the game results.

Each critical order is saved to the JTLS-GO “.ci0” file as the game progresses. During a checkpoint this file is moved to the checkpoint directory and renamed to the “.ci1” file. Each order placed in this file has an associated time. This time does not represent the game time at which the order was sent to the game; instead, it represents the time the order should be received by the object to which it is directed. This time is held within the model as a double precision value and is saved with 13 decimal places. Still even with 13 decimal places, when the time is read in there is some inaccuracy in the time represented. Theoretically, this difference should be on the order of nano-seconds, but the fact remains that the time is slightly different than it was when originally submitted.

Since there is a slight difference in the execution time of the order, the situation in the model may be different. For example, assume that a convoy, carrying ammunition, completes its offload procedure a split second prior to an air mission order with an ASAP time arrives at the squadron. If during normal execution, the convoy offload is complete, the preferred weapons for an air mission may be available and loaded. If on the replay using the “push order” capability, the offload is not complete, the air mission settles for alternative weapons. As soon as the mission loads different weapons, the entire situation for the mission and its results diverge from the original game situation. This change affects the damage for that mission, but may also alter the damage for other missions.

For example, the alternative or replay load may have more or fewer weapons than the originally selected load. A random number is drawn for each weapon fired to determine if the weapon hit its intended target, and a random number is drawn to determine if the target was destroyed. A different number of weapons, results in the model using more or fewer random numbers to compute the damage results of a specific mission. On replay, the random numbers generated are identical to the random numbers generated during the original execution, but once the model uses more or fewer generated variates, the results can change.

Consider the following table that compares the random numbers used to compute the mission results for two missions. On the original game, each Mission A had two weapons,but on the replay it had only one weapon. Mission B had the same two weapons on both the original game and the replay game. Further assume that the Probability of Hit is 0.75 and the Probability of Damage is 0.90 for each weapon against the designated target.

Random Number Original Replay
0.39 Mission A Weapon 1 Hit: HIT Mission A Weapon 1 Hit: HIT
0.54 Mission A Weapon 1 Kill: KILL Mission A Weapon 1 Kill: KILL
0.32 Mission A Weapon 2 Hit: HIT Mission B Weapon 1 Hit: HIT
0.95 Mission A Weapon 2 Kill: NO KILL Mission B Weapon 1 Kill: NO KILL
0.09 Mission B Weapon 1 Hit: HIT Mission B Weapon 2 Hit: HIT
0.22 Mission B Weapon 1 Kill: KILL Mission B Weapon 3 Kill: KILL
0.12 Mission B Weapon 1 Hit: HIT Not needed
0.04 Mission B Weapon 1 Kill: KILL Not needed

Note that on the Replay, Mission B did not kill its first target on the replay, but did so on the original game. The divergence continues to grow. Assume that the target for Mission B was a bridge. On the original game it was destroyed. On the replay it was not destroyed and the enemy could cross the bridge and start to fight sooner. This would definitely results in a further divergence.

Although this is an extreme example, it shows the concept of why the replay can diverge from the original game execution.

JTLS-GO does use a variance reduction technique to limit the divergence. This technique is called independent random streams. Each type of random number needed by the model is generated independently. For example, the random variates used to determine if a ship detects an enemy ship is separate and independent of the random variates used to determine if an Air Mission fired weapon kills its target. Thus the Air Mission issue described above could not affect the detection of a submarine. This technique reduces the impact of the divergence but does not eliminate the described situation.

In JTLS 4.0, the design team reviewed this variance reduction technique code and found several random streams that were no longer independent. This was cleaned up. If you are running a version of JTLS earlier than 4.0, you may see divergence from one aspect of the model also affect other aspects of the model.

Is JTLS 4.0.5.0 supported by Red Hat Linux 6.x?

Currently, JTLS 4.0.5.0 cannot be supported by Red Hat Linux 6.x. The database download for JTLS 4.0.5.0 is accomplished through Perl and Red Hat Linux 6.x has a divergent version of Perl which is not not compatible. However, the non-compatibility issue has been addressed in JTLS 4.1, scheduled to be released on May 1st. A beta version will be available on February 22, 2013.

Does JTLS-GO represent Cyber Warfare?

Cyber warfare and cyber attacks are not explicitly modeled in JTLS-GO, but many of the potential results of cyber warfare can be represented by the JTLS-GO model.Cyber attacks on your capabilities by the enemy are usually represented as a Major Event Scenario List (MSEL) item, also known as a Major Event List / Major Incident List (MEL/MIL) item. The Exercise Director can implement one of several effects within JTLS-GO to model the event, such as:

  • Turning off the JTLS-GO feed to the real-world C4I systems, which would represent a compromise of the national C4I system and all of its data. After an appropriate period of time, the Exercise Director can reestablish the C4I feed.
  • Adjusting the probability of acquiring order information. This database parameter IIP PROB INTEL REPORT can be increased to represent that the enemy has infiltrated your communication system and can see routine messages being sent to your units. Raising this probability will result in more of your orders being sent to the Opposing Force side and being used by them to adjust their operations accordingly.
  • Adjusting the Communication Capability of a unit or a group of units to represent the malfunction of their automated communication systems. This will be to increase the time it takes for the unit to receive and process orders and report to higher command levels.
  • Adjust the Faction's Communication Prototype parameters, such as the threshold at which they can be jammed or the amount of time to translate orders from other faction units on your side.
  • Decrease the UT EFFECTVENESS of the units affected by the cyber attack to represent the malfunction of automated support systems, requiring less efficient means for coordinating internal unit functions. Decreasing this model parameter for a unit will result in the unit fighting less effectively and all of its timed capabilities, such as maintaining and aircraft or loading a convoy will take longer.

      • The creative application of JTLS-GO capabilities can allow for the development of additional or improved methods to simulate cyber warfare.