kmart494

Version 1.1 fixes (hopefully) the regional language problem of saving/loading the scenario files. Also, there is rudimentary support for multiplayer games.

The readme file has not been updated since I am still working on getting the multiplayer function to work the way I envision.

So, here are a few tidbits to get you started. Use the F2 key (modify unit) to set the "visibility" of a unit. That is, whether or not the enemy can see you. Use the new "Show Sides" menu to view just Blue, Red or All sides. The File menu has a save function for a multiplayer game that will create three files: the master scenario file for the ref, Blue file, and Red file. Do not add a file extension in the save file dialog as the program will do it for you. The Blue and Red player files will only include that side's units plus any other "visible" units. Also, loading the Blue/Red files will disable certain functions such as movement, turns, creating and modifying units. In this way, the Blue/Red files are "read only" since changes to units will go through the ref anyway.

I am exploring how to limit the information a player has about visible enemy units. Sometimes you know a unit is there but not necessarily things such as speed, heading, altitude, or depth. Multiple detection will yield that information and I wanted to model that. As it is now, visible enemy units will display all information about them, including their movement tracks.

Kevin

Edit: I forgot to mention the visibility flag for enemy units is currently not saved with the scenario file. Also, you will not be able to use v1.0 scenario files with v1.1 without an easy modification. I will post more detail about that if anyone needs to use an older file with the new program.

Instead of having everyone in the world change their settings, I will use a different character as a separator. Maybe the "|" would work better (I think it's called a pipe).

That is so funny because I was going to make a joke about Steve's language settings without realizing it could be the problem. I needed something to blame, after all.

Edit: By the way, I got SimPlot to work on my 32-bit Vista computer after upgrading to the latest .Net framework.

SiimPlot was created on a 64-bit PC (Win 7) using Visual Studio. I was not aware that simple programs like this may not run on 32-bit systems. I have a 32-bit PC that I can try this on. If I have to, I can recompile on the 32-bit PC so everyone can use it.

I replayed the Dinner scenario and made frequent saves. Everything seems to be working fine. At present I cannot explain why your scenario files are not saving correctly. It looks like you used 3 minute turns, so you did not mistakenly use 30 minute turns (which would make your units go too far).

Which version of Windows are you using?

Is anyone else experiencing similar problems?

Kevin

Steve,

I could not see the image, but I copied and pasted your scenario text and ran SimPlot. It appears that the units have gone so far away that they cant be found. I also see some weird data in the movement track part of the file. I will examine it closer later tonight.

 

I like the implicit simplification you are suggesting but not detailing here. With the CIC Warfare Plotter I was headed towards uncertainty zones for "unknown" units but that becomes a real logistical nightmare for the ref maintaining the parameters of the uncertainty zone. Certainly it would be fun to add at some point but no need to get hung up on it at this stage.

 

I agree, Tony, and I am going to work on the multi-player function before going deeper into the uncertainty thing. However, I would like to share a few details of how it might work in SimPlot.

As it stands now, the ref could still provide the players with bearings from detecting units to radiating units (radar or sound). Those detected units would not be seen by the players until a hard fix is established (radar contact, visual sighting, or active sonar). It would be up to the players to imagine the uncertainty zone for themselves.

Another possibility is for me to add ESM/sonar detection lines as a display option. Let's use an airborne radar transmitter as an example. Once a ship in a task force makes an ESM detection, the ref would use a pop-up form to select the detecting and radiating units. An ESM line would then be visible to the player. Multiple ESM lines would give the player a good fix on the unit location. The player could ask the ref to create a reference point at subsequent cross-fix locations, and a little math on the part of the player would give him an idea of speed. The heading of the detected unit will be known by selecting the reference points and using the bearing button at the bottom of the screen. Keep in mind the detecting units are themselves moving and therefore these reference points will only give the player an idea of who/what/where/when/why of the radiating unit (although a pretty good one ). The uncertainty of it all is up to the player and not a burden for the ref.

Steve,

When I load the Dinner at Six O'clock scenario I see the blue icon in the middle of the screen, with the red icon in the upper left. To equalize the screen, right click at a point half way between the two units. That should allow you to see both. Also, please be aware that the info at the left side of the screen is not "see-through." If a unit is plotted behind it, you will have to right click the screen to move the unit into view.

If you think you may have right clicked yourself too far away from the units, just use the "C" key to recenter the screen. You can also try "zooming out" to see all the units.

Did you change the colors? If the background color is the same as either side, then you will not see them. You could try using the default colors just to see if they come back.

Just to sweeten things, I am mulling over how to create multi-player capability. I am thinking that three files will be needed for each scenario. One will be for the referee and shows all units and actual sides. Two more files would show the blue/red side units and other units within detection range (as determined by the ref). Also, units would have to be "perceived" by each side based on sensor, visual, or behavioral information. For example, the blue player would see all his units and detected units. But, the detected units would be assigned as "unknown" by the ref until the blue player declares they are neutral or hostile.

Players would be sent a new file for their side after every phase (unless nothing happens or changes). The program would just be used as a viewer by the players, with the ref adding and modifying units as ordered by the players.

Thank you Piotr. I am a little embarrassed about the gridlines though, since they did not work as intended. I was hoping to give the user a sense of distance when changing scales. I might replace them with a range bar at the bottom of the screen.

I created a simple plotter (SimPlot) program that automates the process of moving units on a simple x,y coordinate system. The objective is to get myself to play H4 paper rules more often by eliminating the problems of graph paper or Neptune's Cat attacks for tabletop games.

SimPlot will track time and motion of units. It will also provide range and bearing info to other units. Units can automatically follow other units that are selected as "targets." Unit movement tracks and times can be displayed in case you want to see where you have been.

How about a few screenies?

I was hoping to show the unit tracks, but it looks like Photobucket may have changed the image a bit. Anyway, the colors in the game are changeable so you can select whatever colors you like.

There is an option to display bearing and range data from a selected unit to all other units. This will make calculating detection easier.

Units can automatically follow other units by assigning them as "targets." Of course, you can still order a unit to follow a set heading.

There is a readme file within the zipped folder that has details of how to use the program. I hope that most of it is intuitive. still, I will answer any questions you may have about the program.

I forgot to mention that to get started you have to either create a new scenario (very easy--fill in the form, press OK, and then add units) or load an existing scenario. I included two simple scenarios to get you started.

SimPlot.zip

I will start a new topic per Tony's suggestion. If that doesn't work, then I will send the zipped folder to anyone that wants one.

I created a simple plotter (SimPlot) program that automates the process of moving units on a simple x,y coordinate system. The objective is to get myself to play H4 paper rules more often by eliminating the problems of graph paper or Neptune's Cat attacks for tabletop games.

SimPlot will track time and motion of units. It will also provide range and bearing info to other units. Units can automatically follow other units that are selected as "targets." Unit movement tracks and times can be displayed in case you want to see where you have been.

How about a few screenies?

Well, the image came out smaller that I wanted, so I hope you can still read it.

Selecting a unit will display additional information on the left side. The status bar buttons on the bottom will toggle other on-screen information. Never mind the grid lines for now because they are terrible.

Both aircraft groups have detected each other and the F-18 group will now fire AIM-120 missiles. Once the OK button is pressed the missiles will appear on top of the F-18 icon and will not move until next turn.

Now we got some action! I zoomed the map in so you can see how the missiles are tracking their targets. I don't have to figure out a new heading each time they move. Units can be added, modified, or removed as needed. Currently, the program supports aircraft, helicopters, missiles, surface ships, submarines, torpedoes, sonobuoys, and reference points.

I don't have a place to upload the program, and there is no download section for H4 paper rule supporting files. The best I could do right now is to email a zipped folder to anyone that wants a copy.

Thanks for the reply.

Here is a little twist on the above scenario. Let's say that the Burke has AEW support and the inbound missiles are detected before they reach the Burke's radar horizon. Does this mean that the Burke can fire on them as soon as they clear the radar horizon? I am assuming the SAMs must be directed by the launching ship, and thus the weapon directors must have a clear radar line of sight to the targets.

Last night I played a scenario where an Arleigh Burke DDG is attacked by SS-N-22 missiles fired from a Sovremenny DDG. The Sov had Helix AEW support but the Burke had no copter on board, and so detection of inbound missiles was limited to the SPY-1 radar.

Here was the problem. After the 1st move phase of an Engagement Turn the Sunburns were just outside the radar horizon of 24 nm and are still undetected. In the 2nd move phase the missiles are 6.9 nm closer. But, since the ship had no prior detection of the missiles, the Burke cannot see or fire on them in the 2nd fire phase, right?

If so, then the missiles move another 6.9 nm (1st move of next turn) but technically remain undetected until the detection phase. Now the missiles move another 6.9 nm closer(2nd move) and the burke can fire in defense (2nd fire phase). The missiles moved a little more than 20 nm during this event, leaving very little room to deal with them.

Is my interpretation of the sequence of the Engagement Turn correct?

How about some non-fiction from which to create scenarios? I recommend Inside the Danger Zone, The US Military in the Persian Gulf, 1987 - 1988 by Harold Lee Wise.

I am interested in joining the game. I have been playing Harpoon on and off since version 3. I have 4.1 and am brushing up on the rules.

Kevin