Can artillery damage roads and bridges? If not, maybe it will in CO2?

[henry1611]

Hi All,

I believe that an artillery bombardment in CO1 can interdict troops by slowing their rate of advance (disruption, taking cover, fatigue).

Does the CO1 engine model damage to highways/roads/trails (degrade movement rate) or bridges (make unpassable) by artillery bombardment? Put another way, do artillery bombardments have an effect on terrain types or just units (i.e., counters). I'd like to be able to cut off lines of advance/retreat and interdict supply routes by damaging a highway/road/trail or destroying a bridge itself using artillery.

If this is not in CO1, I cast my vote for it being a new feature in CO2.

[BletchleyGeek]

ORIGINAL: henry1611

Hi All,

I believe that an artillery bombardment in CO1 can interdict troops by slowing their rate of advance (disruption, taking cover, fatigue).

Yes, it does. As the German you'll find yourself quite often forced to maneuver your forces by night and launching your attacks right before dawn, in order to avoid being pinned down by arty fires.

ORIGINAL: henry1611
Does the CO1 engine model damage to highways/roads/trails (degrade movement rate) or bridges (make unpassable) by artillery bombardment? Put another way, do artillery bombardments have an effect on terrain types or just units (i.e., counters). I'd like to be able to cut off lines of advance/retreat and interdict supply routes by damaging a highway/road/trail or destroying a bridge itself using artillery.

If this is not in CO1, I cast my vote for it being a new feature in CO2.

No, arty fires don't have effects on the terrain. Your vote has been noted [:)]

[MarkShot]

The only terrain effect with the exception of blown bridges is digging in/entrenching. The engine remembers these locations and if a unit should land on that same spot, then the process will be faster the second time. But there is no overlay which shows this. However, I think with BFTB you can tell your units whether you want them to recover their prior positions if dislodged. This was the normal behavior for single units prior to the BFTB when defending. Otherwise, if wanted them to not fight their way back, you could do a DEFEND-INSITU.

[BletchleyGeek]

ORIGINAL: MarkShot

The only terrain effect with the exception of blown bridges is digging in/entrenching. The engine remembers these locations and if a unit should land on that same spot, then the process will be faster the second time. But there is no overlay which shows this. However, I think with BFTB you can tell your units whether you want them to recover their prior positions if dislodged. This was the normal behavior for single units prior to the BFTB when defending. Otherwise, if wanted them to not fight their way back, you could do a DEFEND-INSITU.

That needs to be addressed.

[MarkShot]

Yep. Go for it! If I don't hear from you in a week, we'll send in a search party or skirmish line to find you.

(At least, all authors are still living and reachable. I've worked on systems which patched themselves {in machine language} as they booted. In fact, there were patches applied to the patches. You got to love it. Way back in the dark ages, we use to leave large tracks of null bytes in executable images. These were patches areas where new assembly instructions could be written with a disk editor. Then, the actual code spot with the problem would have a jump instruction into the patch, and then you would jump back to the following instructions. It sounds easy enough, but some code in order to reduce operand size used PC relative addressing. This could mean your operands might be beyond the address field size reachable from the patch area ... oops ... of course, for standard data that would likely be needed from anywhere would be stored to fields in low memory such that they were absolutely addressable with small instruction operands.) Remember, there was no Internet, no FTP, ... distributing new images was a pain ... so, twiddling a few bytes was the way to go ... and yes, there was no write protected code and you could write self-modifying code; more often by accident than intention!

Gee ... you don't how much fun your missing working on Command Ops instead of systems that well terrified people with the phrase 32 bit upgrade long before anyone terrorized people with phrases Y2K!

[MarkShot]

BTW, before some of you were born PC meant (P)rogram (C)ounter; not (P)ersonal (C)omputer. Thus, meaning like in a cooking recipe what the current step the cook is up to.

So, for information store at Step #10 when performing Step #8:

8: Stir Fry, #10 <=== absolute addressing (you can easily move this)

8: Stir Fry, +2 <=== PC relative (this is much harder move, but too hard to explain to those who don't understand binary programming why)

Just be thankful that the Dark Ages came to an end!

[BletchleyGeek]

ORIGINAL: MarkShot

Yep. Go for it! If I don't hear from you in a week, we'll send in a search party or skirmish line to find you.

Hahaha. I think I talked too much in the previous post of mine.

ORIGINAL: MarkShot
(At least, all authors are still living and reachable. I've worked on systems which patched themselves {in machine language} as they booted. In fact, there were patches applied to the patches. You got to love it. Way back in the dark ages, we use to leave large tracks of null bytes in executable images. These were patches areas where new assembly instructions could be written with a disk editor. Then, the actual code spot with the problem would have a jump instruction into the patch, and then you would jump back to the following instructions. It sounds easy enough, but some code in order to reduce operand size used PC relative addressing. This could mean your operands might be beyond the address field size reachable from the patch area ... oops ... of course, for standard data that would likely be needed from anywhere would be stored to fields in low memory such that they were absolutely addressable with small instruction operands.) Remember, there was no Internet, no FTP, ... distributing new images was a pain ... so, twiddling a few bytes was the way to go ... and yes, there was no write protected code and you could write self-modifying code; more often by accident than intention!

Gee ... you don't how much fun your missing working on Command Ops instead of systems that well terrified people with the phrase 32 bit upgrade long before anyone terrorized people with phrases Y2K!

The real deal is going to be the year 2048, mate [:D] Self-modifying code still happens, nowadays you get the compiler sort of include that for you in order to optimize your code dynamically. There's a notion of progress in Computer Science, even if sometimes I think is a lateral kind of progress...

BTW, a book I love, where the hero is - of all things a systems programmer - is "A Deepness in the Sky" by Vernor Vinge.

[MarkShot]

How about some East/West fusion?

In 2048, you can burn program print outs at my alter and say some prayers for the dead!

[RayWolfe]

I don't think that will be possible ... you'll still be going strong, you old fraud! [:'(]

[MarkShot]

Ray,

How wonderful to hear from you!

You know I no longer live in the "Land of the free and the home of the brave". I now live in the "land of the free and home under threat of PLA invasion"?

Take care.

[Arjuna]

So why Mark haven't you started a Red Dragon Rising scenario then?[:)]

[RayWolfe]

ORIGINAL: MarkShot
I now live in the "land of the free and home under threat of PLA invasion"?

Ah, but you always liked to lived dangerously. Adrenalin being your stimulant of choice.
In my case "nurse" is still trying to keep me simmering gently.
Keep safe.
Ray

[MarkShot]

Dave,

Well after the PLA warms up on a Taiwanese amphibious landing, there is always Australia. You guys are very rich in natural resources. Also, your government recently angered them by rejecting their ADIZ as risky.

Taiwan has been quiet on this ... on one hand, I want to live my life in peace here ... on the other hand, the next PRC ADIZ may well be over Taipei. So, I kind of have mixed emotions on this.