TonyE

Not neccessarily. The game tracks distances in a fictional unit called a DU (distance unit). There are 6211 DUs per nautical mile. That said the game processes at most once per game second and some actions occur less frequently (sensor sweeps generally 30 seconds except sonar at once every 5 minutes, launcher ROF checks every 10 seconds, weapon checks for acquisition are more dynamic in nature depending upon intercept time so you can make a roughly try statement that they are checked every game second). Making that long story shorter, even though the map has a limited granularity, that is a much broader granularity than the game mechanics. It may be that a fudge factor needs to take the map granularity into account in terms of the challenges of a human plotting a torp drop run but not in terms of the game's internal distance granularity.

Killing them is easier but I'd certainly listen to well formed arguments to make them taxi and go back into the Readying pool. My answer is the same as Brad's and I'll add this raises a micro-management issue for me. I get the RTS feel when I think about an engineer unit. Abstracting it into the installation seems more Harpoonish to me. Still I'd definitely like to be shipping in SeaBees someday so the door is definitely not closed forever.

Welcome Akula . I won't be changing aircraft ready times as part of runway damage/repairs. That's a big huge wish for some day down the road, the biggest challenge being teaching the AI how to deal.

I had thought for sure I had seen 'Vertical only' runways in the recent past, or are you referring to undamaged runways? True enough, the 8 runway lengths have different names in different battlesets/databases. The code reads any runway at an installation cannot be reduced below size 3 (0=no runway, 1=small helo, 2=large helo). Whether size 3 is STOL or VTOL or ??? maybe change between battlesets and databases.

My opinion of where we're at in the discussion: Damaging runways and reducing their length is already implemented in a reasonable fashion. Antirunway ordnance applies chRUNWAY crits according to the formula weaponDP/16 = crits. 1 crit = 1 cut. If there aren't enough crits to reduce runway length the damage is still stored (ex. one chRUNWAY crit spread across four runways will not reduce runway length of the installation, but if you get three hits the next attack you now have four total and runway length drops by one level). Currently a runway cannot go below STOL size (the two smaller are large and small helopads The code examination did not reveal whether non-antirunway weapons can reduce the size of a runway. First glance suggests they cannot. This would be a great theory for someone to test in the game. [*] Use of damaged runways Early consensus is to let planes land at damaged runways, anyone against the idea raise your voice. Planes will not be able to take off from an installation with runway size less than that required for the plane. # of runways, do we want to reduce the quantity of takeoffs per 30 seconds for partially reduced runways (ex. two runways at installation, 1 cut so in reality only 1 VLarge plane could take off per 30 seconds instead of the normal 2)? I vote no since it makes my life tougher. Probability of losing aircraft doing takeoff/landing at damaged runways? I like the idea, we need rules developed. [*] Repair of runways Brad listed some believable numbers for repair times. Work with that given the above. How can that be tied in with the below (i.e. the idea that more extensive damage multiplies repair time)? Repair speed influenced by installation size was mentioned. In tandem with repair speed how does multiple runways at the installation affect speed? My thought is that we'd have installation DP tiers (i.e. 1000 DP installation can repair 1 cut per 4 hours, so 4 runways with 1 cut each would take 16 hours to fix). [*] Repair of DP damage at installations - let's leave this for another adventure and focus on the runways for now.

Agreed, actually I know a destroyed installation will not be able to conduct repairs.

Runway criticals may be caused by any weapon, they are more likely to occur with antirunway weapons. The criticals are what reduce the runway length. The base is the only entity with damage points, the individual runway(s) do not have damage points, they only have a length. Any weapon with a non-zero DP will apply damage to the base. General DP damage is not repaired at all in the game. I think that started from the idea of Harpoon being a naval wargame and DP damage would for the most part be fixed in port (structural damage). Criticals generally have a chance of repair (your broken weapons mount might be repaired, rudder fixed, etc.). I tend to think DP damage should be repairable at installations. How's that for floating a big idea?

Just discussing this with Brad on IRC... It should be possible to create a detectable yet not always visible airfield in the Installations annex by making it a type Fixed SAM. They are not visible until detected yet have all of the other capabilities and limitations of installations (such as runways of db designer specified number of size).

I'm not saying I disagree but should a Tu-160 or B-2 be able to land at a runway that was once VLarge but is not bombed to VTOL size? It seems wrong to me but allowing it certainly provides the most opportunity for the AI to live and fight another day.

Good question. Need more codespeak here. The code does not currently keep track of # of damaged runways but we certainly know how many runways an installation has. Those of you beta testing know that the saved game format is in flux so yes, we can add a field to the code that denotes # of runways damaged. An alternative would be correlating damage % to # of runways out of commission. In either event we need rules on damaging the individual runways (one could distribute bomb hits randomly via a die roll). We don't currently model aircraft damage, so that's probably not an option. Total loss is a possibility, but we probably don't want the AI using a damaged airfield without paying any attention to the potential risk. More thought needed here. For reasons of code nightmares and programmer sanity we will avoid at almost any cost the idea of destroying planes that are in the process of taking off or landing. Yes, that means a way to game the system (launch everything when a strike is incoming). However, I have to admit affection for the idea of a chance that planes scheduled to take off from a damaged runway or landing at a damaged runway will be destroyed. That can be accomplished before that horrible interlude during launch and landing. Again we'll need rules to determine % chance of planes being lost. I'm liking the discussion so far and a number of items I hadn't considered have been raised and that makes me very happy!

Yay Harpoon!

Putin wants to sell some guns eh

I'm interested in hearing how airfield damage and repairs should happen. Obviously we already have damage occurring including reduction in runway size. However that doesn't prevent air operations in the way you might expect. Please suggest your rules for: 1. Repairs (ex. one runway size increase per 12 hours if die roll of ##) 2. Effects of damage (planes requiring runway size x cannot land or take off from runway damaged to size x) a. Planes in the air divert to nearest friendly airfield ... Thanks! I'm mainly asking because this shouldn't be a terribly difficult thing to implement (runway repair and related effects) and I need something to get my coding flowing again after my time was monopolized by other projects.

Should be

Submarines follow their courses (well, minus the jinking and weaving and bobbing). If the sub or any other unit on the sub's side detects an enemy and that enemy comes in range, the sub may fire at it whether the sub itself detects it or not. That's how I expect it to work anyway.

Good questions Altitude does affect ECM range to the extent of the radar line of sight. The radar ON only affects active jamming which in the game is defined as jamming pods with a range > 0. So if The pod lists Horizon or 0 as the range it means you have a point defense jammer that will work to reduce the PK of weapons targeted at that individual unit whether the radar is turned on or not. There is no home on jam code in the game.

I haven't had a chance to delve into the code (and it is unlikely I'd find the right tidbit in less than hours of time) but my recollection is that the behavior you are seeing for submarines is correct. Surface groups should tear off after detected opponents (many scenario authors don't like this). Land groups were meant not to but a certain programmer after me set them to act like surface groups and I haven't undone that yet so I expect they'll still chase as well.

Welcome back! The following thread/topic should get you started on the jamming: http://harpgamer.com/harpforum/index.php?showtopic=2574 In short they indicate that unit's radars are being jammed to some extent (which if you turn on ECM logging via the command line you could see more numbers). A jammer must have its radar on in order to jam, that is the on/off switch. Refueling has a long ways to go (as do most things despite it being a 20 year old game) but it works perhaps more reliably now than ever and that is a start!

That is great and I've never heard of it before!

Hi Pete, that is a misleading door in this case. The ideal route is to find the original installer and if you are lucky you still have enough information to make http://www.findmyorder.com/ happy. If you get through that gate it will let you install the game anew, including the registry entries and possibly hidden maga.mg file that you need for the serial number check to work. If that doesn't get you anywhere, post back and we can try the next thing. At least we'll keep you a little busy until Matrix responds.

Pete, sorry I don't have TOAW to compare notes. Do you need to register in order to download patches or to play MP or ???

Does it seem a little strange that the military is saying no more talks and not Our Dear Leader? That was my first thought anyway.

Definitely going well for you, and heading off the challenges nicely, thanks for sharing and am looking forward to more.

There is a size limit to the scenario file, not a memory limit (well, in the recent versions of the game anyway, 2008.044 and newer). My vague recollection is that it is not a hard limit but hovered close to the same size in each case. I'd be happy to take a quick look if you want to zip and upload the scenario file here or zip and e-mail to hc3@harpgamer.com.

One reason we've had so much snow in MN this year is the warmer temperatures than usual. It doesn't snow much when it is colder. Usually we have most of January very cold (our snowiest month historically is March) and hence little snow but this year we've had significant snowfalls each month and there was no long extreme cold in January.