About the possibility of open Source code

[woos1981]

Note that 17,253 + 1,518 + 13,532 = 32,303 lines of code I’ve written since starting. Since the entire code of TOAW is about 202,000 lines, I’ve written about 16% of TOAW’s code.

Time to update this a bit, since I just completed another 7,568 lines:

"Note that 17,253 + 1,518 + 21,100 = 39,871 lines of code I’ve written since starting. Since the entire code of TOAW is about 209,000 lines, I’ve written about 19% of TOAW’s code."

I have a hunch that this might sound a little unrealistic. After the next update released that will be caused great repercussions in the gamers, It will make MAtrix Come to realize the value and potential of the game, and then they back again employed new members to made the game rebirth, anyhow thanks Bob for all your insist and hard work, You're our only hope right now.

[sPzAbt653]

omg.

[parmenio]

You're our only hope right now.

I thought I'd slipped into Star Wars for a moment there...

https://www.youtube.com/watch?v=0RDIJfoBhFU

[woos1981]

You're our only hope right now.

I thought I'd slipped into Star Wars for a moment there...

https://www.youtube.com/watch?v=0RDIJfoBhFU

[ncc1701e]

I am finishing a first Pacman game using Godot engine. 249 lines of code.
Using an engine, you won't have to worry about OSs or PCs upgrades.

[Lobster]

Note that 17,253 + 1,518 + 13,532 = 32,303 lines of code I’ve written since starting. Since the entire code of TOAW is about 202,000 lines, I’ve written about 16% of TOAW’s code.

Time to update this a bit, since I just completed another 7,568 lines:

"Note that 17,253 + 1,518 + 21,100 = 39,871 lines of code I’ve written since starting. Since the entire code of TOAW is about 209,000 lines, I’ve written about 19% of TOAW’s code."

6 years x 365 days = 18 lines of code per day. The average production progammer does around 50 lines per day. So I guess Bob isn't really a slacker.

The issue isn't how much is being done but what is being done. That's where the dictators become an issue. While a wishlist was compiled several years ago it seems to me only one person had their finger on what and when. Sadly a minor part of the game that should have been left abstract has taken front seat and has consumed so much precious coding time and even that isn't even near completion. I doubt that there will by any update within the next three years. And after that if and when the rest of the ever expanding list of features get added it will be TOAW V.

[Curtis Lemay]

6 years x 365 days = 18 lines of code per day. The average production progammer does around 50 lines per day. So I guess Bob isn't really a slacker.

This site says 10 lines per day over 250 work days per year:

https://skeptics.stackexchange.com/ques ... rogramming

And 6 years x 250 days = 26 lines per day.

The issue isn't how much is being done but what is being done. That's where the dictators become an issue. While a wishlist was compiled several years ago it seems to me only one person had their finger on what and when. Sadly a minor part of the game that should have been left abstract has taken front seat and has consumed so much precious coding time and even that isn't even near completion. I doubt that there will by any update within the next three years. And after that if and when the rest of the ever expanding list of features get added it will be TOAW V.

There will be plenty for everyone in the new update. And how long coding takes is unknowable till it's done. Apparently Jack is the only one allowed to discuss it, though. I have an NDA.

[Lobster]

I didn't sign an NDA about if you are a slacker or not. Nor did I sign one about whether or not you are doing your job. Nor did I sign one about whether or not I can post an opinion about whether or not so much is being added that a finish line is continually being pushed over the horizon. I also didn't sign one about what's in the Wishlist which is where you said you got the list for what is to be done. You are in total control of what happens and what anyone else thinks is of little importance to you.

BTW, in the Wishlist all naval is posted in section 9. It's a lot.

So if anyone want's to know what's likely to happen look at the Wishlist. NDA not required.

[Curtis Lemay]

I didn't sign an NDA about if you are a slacker or not. Nor did I sign one about whether or not you are doing your job. Nor did I sign one about whether or not I can post an opinion about whether or not so much is being added that a finish line is continually being pushed over the horizon. I also didn't sign one about what's in the Wishlist which is where you said you got the list for what is to be done. You are in total control of what happens and what anyone else thinks is of little importance to you.

BTW, in the Wishlist all naval is posted in section 9. It's a lot.

So if anyone want's to know what's likely to happen look at the Wishlist. NDA not required.

You did sign a NDA about what is explictly being done on the Dev Board. Yet you discussed it here on the main board - without even discussing it on the Development Board. Meanwhile, I can't even respond.

[Lobster]

You have discussed dev board things. But hey, you'll bend things any way you want to make yourself right so say what you please. And the Wishlist is public not dev board.

[Lobster]

9 Naval Warfare
9.1 Air units can be assigned to "Sea Interdiction".
9.1.1 Such units would interdict detected in-range enemy naval and embarked movement, only.
9.1.2 Both sides' AS units participate in above as allowed by ranges.
9.1.3 Requires handling of day/night issues (see 8.25).
9.1.4 Recommended: stable radius limit (8.1).
9.1.5 Interdiction of enemy carriers by air units from friendly carriers can trigger counterstrikes (similar to counterbattery).
9.2 Naval Surface Interdiction:
9.2.1 Similar to 9.1, naval surface units and coastal artillery units should fire at detected enemy naval/embarked units moving in their bombardment range.
9.2.2 Subject to counterbattery fire from the target naval units, of course.
9.2.3 No deployment setting is necessary – it’s automatic.
9.3 Advanced: Naval units can be assigned to "Naval Reaction". Such units would react to detected in-range enemy naval and embarked movement.
9.3.1 TF must be set to “reaction mode” (use the “L” from “Limited Reserve”) in previous player phase.
9.3.2 Chance of reaction increases closer to reacting force enemy movement gets. Players can set reaction radius limit (simpler: max of 20% of TF MPs).
9.3.3 Chance of reaction increases the more valuable the target TF is relative to the reacting TF.
9.3.4 Chance of reaction increases the stronger the reacting TF is relative to the target TF.
9.3.5 Only Carrier TFs can react to Carrier target TFs.
9.3.6 Value is the sum of all target priorities in the TF (see 9.5.1). Strength is that minus the value of any embarked units.
9.3.7 Once reaction is triggered, reacting force moves up to 10% of its MPs – stopping if in range of surface or air naval combat.
9.3.8 Once a reaction has been made the TF cannot react again that combat phase. If there were a subsequent movement phase, it would be free to make another reaction, using the same procedure. This can continue till the reacting TF reaches the triggering TF.
9.3.9 Naval combat then takes place by the reacting force, followed by counterbattery fire (or counterstrike if carrier) from the phasing elements. Loss tolerance determines if reaction continues or ends at that point. Of course, the reacting force is subject to phasing player’s naval interdiction & etc. on the way if it is detected.
9.3.10 Both sides' AS units participate in above as allowed by ranges.
9.3.11 Requires handling of day/night issues (see 8.25).
9.3.12 Alternate: Naval reaction could also work like land reserve connected with interdicting bombardment.
9.3.13 Alternate: Reaction method used by Victory Game’s “Pacific War”.
9.4 Stacked Naval and embarked units can be incorporated into (and then out of) Task Forces using the "Naval Task Force" icon. They can then move and defend against attack as a single unit.
9.4.1 Like “composite units” in 4.8, particulars of incorporated units are retained inside the Task Force unit.
9.4.2 In addition or alternatively, allow stacked naval units to receive group movement orders (like ground unit stacks).
9.4.2.1 Once 9.1 is implemented, the whole group would only have one interception trigger per hex, and such groups would defend collectively if intercepted during the move.
9.4.3 Ships moving as a group would be “synchronized”:
9.4.3.1 MP rate of faster ships reduced to that of the slowest.
9.4.3.2 Remaining fraction of ships MPs reduced to that of the latest.
9.5 Air units can choose to target only the ships in a port via popup (similar to "airfield attack" now).
9.5.1 Advanced: In addition, ship unit types are given target weights like in Pacwar. So Carriers would be highest priority, followed by BBs, etc.
9.5.1.1 Carrier Naval icon = 1500
9.5.1.2 Heavy Naval icon = 150
9.5.1.3 Medium Naval icon = 50
9.5.1.4 Light Naval icon = 10
9.5.1.5 All embarked equipment = 40 per 100 weight of embarked
9.5.1.6 So, for example, a Carrier plus 100 embarked squads would give the carrier a 97% chance of being targeted by any given fire (instead of the 1% chance it would have now).
9.6 Embarked units’ naval defense and losses modeled as if in transport vessels.
9.6.1 Durability = 20. Armor = 0. AAA = 0. Agility = 18.
9.6.2 Damage points accumulated sinks equal weight of equipment.
9.7 Sealift divided into "amphibious" that can be used for beach assaults on beach hexes, and "transport" that can only be used Port to Port.
9.8 Designer can deny practice of disembarking units in all-sea hexes.
9.8.1 Alternate: Disembarking units in all-sea hexes could be possible only when a Naval Task Force is present and set for “amphibious operation”. Such an operation turns a NTF into a temporary anchorage and a supply point.
9.9 Evacuation – a possibility to embark units from any coastal hex, but without heavy equipment.
9.10 Defensive support of land targets should be conducted only when the naval unit is set for a “support” mission.
9.11 Kamikazes:
9.11.1 Designer designated air units only.
9.11.2 Are always completely destroyed in any bombardment or combat support they participate in.
9.11.3 Proficiency value used for bombardment purposes is quadrupled (to max of 100) if used against naval targets.
9.12 Submarines:
9.12.1 Hidden unit – with similar properties to 7.22.
9.12.2 Can be assigned/reassigned to a patrol zone with center and radius.
9.12.2.1 Alternate: zone could be a sea zone instead (see 9.15 below).
9.12.3 Enemy movement into that zone can trigger a sub attack.
9.12.4 Attack strength depends upon detailed sub characteristics developed in equipment editor.
9.12.5 Subject to ASW by in-range air and naval assets.
9.12.6 Torpedoes: Anti-Naval strength only – no AP strength (can’t be used against shore targets). And different range from ship’s gun range. Can be on surface ships as well.
9.12.7 ASW strengths for surface ships/planes - usable only against submarines.
9.13 There are arcane issues with riverine units that require addressing:
9.13.1 Ground units shouldn’t automatically RBC to riverine units.
9.13.2 Riverine movement should be like “careless movement” (6.16) – no recon of adjacent hexes or even hexes entered (no hex conversion), and subject to ambush by enemy units on the river.
9.13.3 Possibly allowed to pass through enemy ground units – subject to ambush.
9.14 Sea Zones
9.14.1 Sea areas can be partitioned in some fashion.
9.14.2 Each zone can have its own seacap levels.
9.14.3 “Fixed” reconstitution choice would work for naval units (so that ships would reconstitute into the correct sea zone).
9.15 REVOLUTIONARY: Detailed ship modeling. (Armor, armament, range, speed, durability, etc.)
9.15.1 Ships would be fully modeled to function like ships instead of like floating artillery. Similar to WitP modeling.
9.15.1.1 Systems would be located in either the hull or superstructure.
9.15.1.2 Systems would include flotation (including compartmentalization), propulsion (engine & props), armament (guns, torpedoes, depth charges) & fire control, steering (bridge & rudder).
9.15.1.3 Armor would protect various systems (belt & deck armor protects hull, turret armor protects guns, and tower armor protects bridge & fire control).
9.15.1.4 Vessels would have specified tactical and cruising speeds – affected by damage to engine/props, etc.
9.15.1.5 Intermediate alternate: Ship equipment would remain just as now, but would have “damage” ratings added. Combat effects would then apply to that damage level rather than a simple kill/survived resolution. 100% damage sinks the ship, etc. Damage scales AP/AAA/Agility strengths and MP allowance.
9.15.1.6 Ship Durability, Armor, Agility, and Speed are now settable via an extension to the .eqp file. Absent that, Durability and Armor are derived from the ship’s defense strength. These parameters affect ship movement and combat.
9.15.1.7 Carriers could have more than one air unit assigned – a naval equipment parameter.
9.15.1.8 Air units assigned to a carrier could be “internalized” via 4.8 (Composite Units).
9.15.1.9 Ships can have a secondary armament – with different range and shell weight from main armament.
9.16 REVOLUTIONARY: Detailed ship combat including sinking vs. damage/repair, detailed aircraft abilities, ASW, mines, etc.
9.16.1 Ships would be subject to damage. This would cause reduction in capability as appropriate. It would require repair. Sinking would be caused by 100% damage only. Naval units would not “evaporate” as land units do. They would only be eliminated if all ships in them were “sunk”. Damaged ships would not be returned to the pools – they would have to get back to port under their own power, debilitated by whatever damage they had incurred.
9.16.2 Modeling of catastrophic hits that detonate magazines.
9.16.3 Combat against naval targets is resolved as individual shots/planes for hit/penetration/damage based upon anti-naval/shell weight vs. armor/durability.
9.16.4 Naval units never “evaporate” and naval equipment never goes to the “On Hand” pool. Units are only destroyed if all ships in them are sunken (100% damage).
9.16.5 Damage to a carrier in excess of 66% destroys any aircraft unit based on it.
9.16.6 Weapon systems would tend to impact different systems depending upon their type – bombs/shells tend to affect superstructure features; torpedoes/mines tend to affect hull features.
9.16.6.1 Alternate: Torpedoes cause more severe damage than their shell weight would imply – a x4 factor.
9.16.7 Surface combat between ships might require a special combat routine in some fashion to address things like tactical speeds & ranges, environmental conditions (night, rain, etc.), and tactical intent of the two sides (engage, disengage). Again, the WitP model would serve as a template. Disengagement would have its own procedure, which would allow the defender’s naval units to retreat some significant distance, subject to disengagement attack from the victors. Badly straggling vessels might be detached automatically.
9.16.7.1 Chance of disengagement would depend on the relative speeds – and much easier at night.
9.16.7.2 Distance might be up to 10% of the TFs’ MPs.
9.16.7.3 Direction of disengagement would be randomized in some fashion.
9.16.7.4 Multi-ship units’ speeds would be based upon the average, not slowest – to avoid one severely damaged ship from dooming an entire fleet.
9.16.8 Ships require periodic maintenance at a suitable port.
9.16.8.1 Damage can be repaired a little at sea, more in port.
9.16.8.2 Damage points can be acquired just from usage (movement, firing).
9.17 Friendly naval units no longer automatically reveal enemy shore deployments as they move by them, except for coastal gun emplacements that fire at them (and only the coastal guns would be revealed – like 8.16).
9.17.1 Embarked units must assault unrevealed anchorage hexes, even if they prove to be unoccupied.
9.17.2 Perhaps there could be some facility for shore parties that could reconnoiter under specific circumstances.
9.18 Friendly units on coastal deployments and all friendly naval units automatically detect enemy naval units near them – out to 25km by day and 10km by night.
9.18.1 Foul weather in the observation hex would affect detection.
9.18.2 Detection takes place in real time, not just during the inter-turn calculations (like the way Peak terrain works now).
9.18.3 Detection of moving naval units could trigger interdiction combat as per items 9.1 & 9.2.
9.18.4 Air units set to Sea Interdiction would conduct sea spotting during the interturn period. Range would be the air unit range subject to minimum effective plane requirement.
9.18.5 Carrier air units set to Sea Interdiction would conduct the same sea spotting, but dynamically as they move.
9.18.6 Any land terrain between the observer and target would block the detection.
9.19 Limit naval support to coastal hexes or 5km inland.
9.20 More explicit modeling of naval unit supply lines.
9.20.1 Trace to port required.
9.20.1.1 Alternate: Return to port required (by designer option).
9.20.1.2 Some form of resupply at sea feature modeled (physical supply ships or such).
9.20.2 If 5.13 effected, actual tons would have to be consumed and, if at sea, delivered by supply ships. Perhaps depots could be onboard ships themselves – requiring less frequent resupply than ground units. Tonnage limit would be a ship parameter.
9.21 Helicopters can be based on Carriers.

[Lobster]

Thank you for your time and effort. If it was not for you then TOAW would be dead and buried.

This is utter BS. If Bob were not doing it a TEAM of people would be devoting their free time to further the game.

[Curtis Lemay]

You have discussed dev board things. But hey, you'll bend things any way you want to make yourself right so say what you please. And the Wishlist is public not dev board.

I'm talking about this:

https://www.matrixgames.com/forums/view ... 7#p5002217

[Curtis Lemay]

9 Naval Warfare
9.1 Air units can be assigned to "Sea Interdiction".
9.1.1 Such units would interdict detected in-range enemy naval and embarked movement, only.
9.1.2 Both sides' AS units participate in above as allowed by ranges.
9.1.3 Requires handling of day/night issues (see 8.25).
9.1.4 Recommended: stable radius limit (8.1).
9.1.5 Interdiction of enemy carriers by air units from friendly carriers can trigger counterstrikes (similar to counterbattery).
9.2 Naval Surface Interdiction:
9.2.1 Similar to 9.1, naval surface units and coastal artillery units should fire at detected enemy naval/embarked units moving in their bombardment range.
9.2.2 Subject to counterbattery fire from the target naval units, of course.
9.2.3 No deployment setting is necessary – it’s automatic.
9.3 Advanced: Naval units can be assigned to "Naval Reaction". Such units would react to detected in-range enemy naval and embarked movement.
9.3.1 TF must be set to “reaction mode” (use the “L” from “Limited Reserve”) in previous player phase.
9.3.2 Chance of reaction increases closer to reacting force enemy movement gets. Players can set reaction radius limit (simpler: max of 20% of TF MPs).
9.3.3 Chance of reaction increases the more valuable the target TF is relative to the reacting TF.
9.3.4 Chance of reaction increases the stronger the reacting TF is relative to the target TF.
9.3.5 Only Carrier TFs can react to Carrier target TFs.
9.3.6 Value is the sum of all target priorities in the TF (see 9.5.1). Strength is that minus the value of any embarked units.
9.3.7 Once reaction is triggered, reacting force moves up to 10% of its MPs – stopping if in range of surface or air naval combat.
9.3.8 Once a reaction has been made the TF cannot react again that combat phase. If there were a subsequent movement phase, it would be free to make another reaction, using the same procedure. This can continue till the reacting TF reaches the triggering TF.
9.3.9 Naval combat then takes place by the reacting force, followed by counterbattery fire (or counterstrike if carrier) from the phasing elements. Loss tolerance determines if reaction continues or ends at that point. Of course, the reacting force is subject to phasing player’s naval interdiction & etc. on the way if it is detected.
9.3.10 Both sides' AS units participate in above as allowed by ranges.
9.3.11 Requires handling of day/night issues (see 8.25).
9.3.12 Alternate: Naval reaction could also work like land reserve connected with interdicting bombardment.
9.3.13 Alternate: Reaction method used by Victory Game’s “Pacific War”.
9.4 Stacked Naval and embarked units can be incorporated into (and then out of) Task Forces using the "Naval Task Force" icon. They can then move and defend against attack as a single unit.
9.4.1 Like “composite units” in 4.8, particulars of incorporated units are retained inside the Task Force unit.
9.4.2 In addition or alternatively, allow stacked naval units to receive group movement orders (like ground unit stacks).
9.4.2.1 Once 9.1 is implemented, the whole group would only have one interception trigger per hex, and such groups would defend collectively if intercepted during the move.
9.4.3 Ships moving as a group would be “synchronized”:
9.4.3.1 MP rate of faster ships reduced to that of the slowest.
9.4.3.2 Remaining fraction of ships MPs reduced to that of the latest.
9.5 Air units can choose to target only the ships in a port via popup (similar to "airfield attack" now).
9.5.1 Advanced: In addition, ship unit types are given target weights like in Pacwar. So Carriers would be highest priority, followed by BBs, etc.
9.5.1.1 Carrier Naval icon = 1500
9.5.1.2 Heavy Naval icon = 150
9.5.1.3 Medium Naval icon = 50
9.5.1.4 Light Naval icon = 10
9.5.1.5 All embarked equipment = 40 per 100 weight of embarked
9.5.1.6 So, for example, a Carrier plus 100 embarked squads would give the carrier a 97% chance of being targeted by any given fire (instead of the 1% chance it would have now).
9.6 Embarked units’ naval defense and losses modeled as if in transport vessels.
9.6.1 Durability = 20. Armor = 0. AAA = 0. Agility = 18.
9.6.2 Damage points accumulated sinks equal weight of equipment.
9.7 Sealift divided into "amphibious" that can be used for beach assaults on beach hexes, and "transport" that can only be used Port to Port.
9.8 Designer can deny practice of disembarking units in all-sea hexes.
9.8.1 Alternate: Disembarking units in all-sea hexes could be possible only when a Naval Task Force is present and set for “amphibious operation”. Such an operation turns a NTF into a temporary anchorage and a supply point.
9.9 Evacuation – a possibility to embark units from any coastal hex, but without heavy equipment.
9.10 Defensive support of land targets should be conducted only when the naval unit is set for a “support” mission.
9.11 Kamikazes:
9.11.1 Designer designated air units only.
9.11.2 Are always completely destroyed in any bombardment or combat support they participate in.
9.11.3 Proficiency value used for bombardment purposes is quadrupled (to max of 100) if used against naval targets.
9.12 Submarines:
9.12.1 Hidden unit – with similar properties to 7.22.
9.12.2 Can be assigned/reassigned to a patrol zone with center and radius.
9.12.2.1 Alternate: zone could be a sea zone instead (see 9.15 below).
9.12.3 Enemy movement into that zone can trigger a sub attack.
9.12.4 Attack strength depends upon detailed sub characteristics developed in equipment editor.
9.12.5 Subject to ASW by in-range air and naval assets.
9.12.6 Torpedoes: Anti-Naval strength only – no AP strength (can’t be used against shore targets). And different range from ship’s gun range. Can be on surface ships as well.
9.12.7 ASW strengths for surface ships/planes - usable only against submarines.
9.13 There are arcane issues with riverine units that require addressing:
9.13.1 Ground units shouldn’t automatically RBC to riverine units.
9.13.2 Riverine movement should be like “careless movement” (6.16) – no recon of adjacent hexes or even hexes entered (no hex conversion), and subject to ambush by enemy units on the river.
9.13.3 Possibly allowed to pass through enemy ground units – subject to ambush.
9.14 Sea Zones
9.14.1 Sea areas can be partitioned in some fashion.
9.14.2 Each zone can have its own seacap levels.
9.14.3 “Fixed” reconstitution choice would work for naval units (so that ships would reconstitute into the correct sea zone).
9.15 REVOLUTIONARY: Detailed ship modeling. (Armor, armament, range, speed, durability, etc.)
9.15.1 Ships would be fully modeled to function like ships instead of like floating artillery. Similar to WitP modeling.
9.15.1.1 Systems would be located in either the hull or superstructure.
9.15.1.2 Systems would include flotation (including compartmentalization), propulsion (engine & props), armament (guns, torpedoes, depth charges) & fire control, steering (bridge & rudder).
9.15.1.3 Armor would protect various systems (belt & deck armor protects hull, turret armor protects guns, and tower armor protects bridge & fire control).
9.15.1.4 Vessels would have specified tactical and cruising speeds – affected by damage to engine/props, etc.
9.15.1.5 Intermediate alternate: Ship equipment would remain just as now, but would have “damage” ratings added. Combat effects would then apply to that damage level rather than a simple kill/survived resolution. 100% damage sinks the ship, etc. Damage scales AP/AAA/Agility strengths and MP allowance.
9.15.1.6 Ship Durability, Armor, Agility, and Speed are now settable via an extension to the .eqp file. Absent that, Durability and Armor are derived from the ship’s defense strength. These parameters affect ship movement and combat.
9.15.1.7 Carriers could have more than one air unit assigned – a naval equipment parameter.
9.15.1.8 Air units assigned to a carrier could be “internalized” via 4.8 (Composite Units).
9.15.1.9 Ships can have a secondary armament – with different range and shell weight from main armament.
9.16 REVOLUTIONARY: Detailed ship combat including sinking vs. damage/repair, detailed aircraft abilities, ASW, mines, etc.
9.16.1 Ships would be subject to damage. This would cause reduction in capability as appropriate. It would require repair. Sinking would be caused by 100% damage only. Naval units would not “evaporate” as land units do. They would only be eliminated if all ships in them were “sunk”. Damaged ships would not be returned to the pools – they would have to get back to port under their own power, debilitated by whatever damage they had incurred.
9.16.2 Modeling of catastrophic hits that detonate magazines.
9.16.3 Combat against naval targets is resolved as individual shots/planes for hit/penetration/damage based upon anti-naval/shell weight vs. armor/durability.
9.16.4 Naval units never “evaporate” and naval equipment never goes to the “On Hand” pool. Units are only destroyed if all ships in them are sunken (100% damage).
9.16.5 Damage to a carrier in excess of 66% destroys any aircraft unit based on it.
9.16.6 Weapon systems would tend to impact different systems depending upon their type – bombs/shells tend to affect superstructure features; torpedoes/mines tend to affect hull features.
9.16.6.1 Alternate: Torpedoes cause more severe damage than their shell weight would imply – a x4 factor.
9.16.7 Surface combat between ships might require a special combat routine in some fashion to address things like tactical speeds & ranges, environmental conditions (night, rain, etc.), and tactical intent of the two sides (engage, disengage). Again, the WitP model would serve as a template. Disengagement would have its own procedure, which would allow the defender’s naval units to retreat some significant distance, subject to disengagement attack from the victors. Badly straggling vessels might be detached automatically.
9.16.7.1 Chance of disengagement would depend on the relative speeds – and much easier at night.
9.16.7.2 Distance might be up to 10% of the TFs’ MPs.
9.16.7.3 Direction of disengagement would be randomized in some fashion.
9.16.7.4 Multi-ship units’ speeds would be based upon the average, not slowest – to avoid one severely damaged ship from dooming an entire fleet.
9.16.8 Ships require periodic maintenance at a suitable port.
9.16.8.1 Damage can be repaired a little at sea, more in port.
9.16.8.2 Damage points can be acquired just from usage (movement, firing).
9.17 Friendly naval units no longer automatically reveal enemy shore deployments as they move by them, except for coastal gun emplacements that fire at them (and only the coastal guns would be revealed – like 8.16).
9.17.1 Embarked units must assault unrevealed anchorage hexes, even if they prove to be unoccupied.
9.17.2 Perhaps there could be some facility for shore parties that could reconnoiter under specific circumstances.
9.18 Friendly units on coastal deployments and all friendly naval units automatically detect enemy naval units near them – out to 25km by day and 10km by night.
9.18.1 Foul weather in the observation hex would affect detection.
9.18.2 Detection takes place in real time, not just during the inter-turn calculations (like the way Peak terrain works now).
9.18.3 Detection of moving naval units could trigger interdiction combat as per items 9.1 & 9.2.
9.18.4 Air units set to Sea Interdiction would conduct sea spotting during the interturn period. Range would be the air unit range subject to minimum effective plane requirement.
9.18.5 Carrier air units set to Sea Interdiction would conduct the same sea spotting, but dynamically as they move.
9.18.6 Any land terrain between the observer and target would block the detection.
9.19 Limit naval support to coastal hexes or 5km inland.
9.20 More explicit modeling of naval unit supply lines.
9.20.1 Trace to port required.
9.20.1.1 Alternate: Return to port required (by designer option).
9.20.1.2 Some form of resupply at sea feature modeled (physical supply ships or such).
9.20.2 If 5.13 effected, actual tons would have to be consumed and, if at sea, delivered by supply ships. Perhaps depots could be onboard ships themselves – requiring less frequent resupply than ground units. Tonnage limit would be a ship parameter.
9.21 Helicopters can be based on Carriers.

Items underlined in bold have been done.

[Lobster]

You have discussed dev board things. But hey, you'll bend things any way you want to make yourself right so say what you please. And the Wishlist is public not dev board.

I'm talking about this:

https://www.matrixgames.com/forums/view ... 7#p5002217

You've already spilled the beans about hierarchy but bend things like you want so you are right.

[Curtis Lemay]

Note that 17,253 + 1,518 + 13,532 = 32,303 lines of code I’ve written since starting. Since the entire code of TOAW is about 202,000 lines, I’ve written about 16% of TOAW’s code.

Time to update this a bit, since I just completed another 7,568 lines:

"Note that 17,253 + 1,518 + 21,100 = 39,871 lines of code I’ve written since starting. Since the entire code of TOAW is about 209,000 lines, I’ve written about 19% of TOAW’s code."

Time to update this again, since I just completed another 17,100 lines:

"Note that 17,253 + 1,518 + 38,200 = 56,971 lines of code I’ve written since starting. Since the entire code of TOAW is about 226,764 lines, I’ve written about 25% of TOAW’s code."

[woos1981]

Note that 17,253 + 1,518 + 13,532 = 32,303 lines of code I’ve written since starting. Since the entire code of TOAW is about 202,000 lines, I’ve written about 16% of TOAW’s code.

Time to update this a bit, since I just completed another 7,568 lines:

"Note that 17,253 + 1,518 + 21,100 = 39,871 lines of code I’ve written since starting. Since the entire code of TOAW is about 209,000 lines, I’ve written about 19% of TOAW’s code."

Time to update this again, since I just completed another 17,100 lines:

"Note that 17,253 + 1,518 + 38,200 = 56,971 lines of code I’ve written since starting. Since the entire code of TOAW is about 226,764 lines, I’ve written about 25% of TOAW’s code."

Thanks Bob. Your updates make us see hope again. I have a question.Do you mean 25% from the next update? Or is it part of the entire game code? When is the next update release? Thank you very much!

[Curtis Lemay]

Time to update this a bit, since I just completed another 7,568 lines:

"Note that 17,253 + 1,518 + 21,100 = 39,871 lines of code I’ve written since starting. Since the entire code of TOAW is about 209,000 lines, I’ve written about 19% of TOAW’s code."

Time to update this again, since I just completed another 17,100 lines:

"Note that 17,253 + 1,518 + 38,200 = 56,971 lines of code I’ve written since starting. Since the entire code of TOAW is about 226,764 lines, I’ve written about 25% of TOAW’s code."

Thanks Bob. Your updates make us see hope again. I have a question.Do you mean 25% from the next update? Or is it part of the entire game code? When is the next update release? Thank you very much!

I'm writing 100% of the next update. 25% is the fraction of the whole TOAW code I've now written.

[woos1981]

Time to update this again, since I just completed another 17,100 lines:

"Note that 17,253 + 1,518 + 38,200 = 56,971 lines of code I’ve written since starting. Since the entire code of TOAW is about 226,764 lines, I’ve written about 25% of TOAW’s code."

Thanks Bob. Your updates make us see hope again. I have a question.Do you mean 25% from the next update? Or is it part of the entire game code? When is the next update release? Thank you very much!

I'm writing 100% of the next update. 25% is the fraction of the whole TOAW code I've now written.

Wow, this is definitely a big news! Does this mean the next update is coming soon?

[Curtis Lemay]

Note that 17,253 + 1,518 + 13,532 = 32,303 lines of code I’ve written since starting. Since the entire code of TOAW is about 202,000 lines, I’ve written about 16% of TOAW’s code.

Time to update this a bit, since I just completed another 7,568 lines:

"Note that 17,253 + 1,518 + 21,100 = 39,871 lines of code I’ve written since starting. Since the entire code of TOAW is about 209,000 lines, I’ve written about 19% of TOAW’s code."

Time to update this again, since I just completed another 17,100 lines:

"Note that 17,253 + 1,518 + 38,200 = 56,971 lines of code I’ve written since starting. Since the entire code of TOAW is about 226,764 lines, I’ve written about 25% of TOAW’s code."

Time to update this again, since I just completed another 12,410 lines:

"Note that 17,253 + 1,518 + 38,200 + 12,410 = 69,381 lines of code I’ve written since starting. Since the entire code of TOAW is about 239,074 lines, I’ve written about 29% of TOAW’s code."