Cav taking city in 61'?

[Pdubya64]

Well, this is sobering news Gray, but not really unexpected. I think modification of existing code base with "new" modules (I assume AGEOD uses a version of C) is one of the most challenging of tasks for a programmer. So many variables and combinations to consider.

About the only thing I can think of would be a function or subroutine that keeps track of changes to data states, calls, etc. and logs them. Might help with backtracking to find where the new portions of code are breaking the old ones. I'm sure some of this is already in the debugger function, but...

Anyhoo, hang in there Gray. I bet some kind of solution can be come to by Pocus in time. Thanks for what you do bud!

[Franciscus]

@Generalissmo:

I am referring to this post by Gray:

The problem is not with the changes themselves, it's the shared commonality with the new game code that is killing this update. Each time they fix/change a specific broken area of the AACW.exe executable they reassemble it with new code designed for the new games, introducing new unrelated bugs into the process. (...)

.

If this indeed is the case (and I think that it happens indeed sometimes) it shouldn't ! I suspect, for instance, that the executable file we tested, for example, in the last RC (21 ?) of 1.14 is not the same that was released, and in the final process of compiling (or whatever is the correct term) new bugs were introduced, bugs that did not exist in the beta public testing (but I may be wrong, of course )

[Generalisimo]

@Generalissmo:

I am referring to this post by Gray:

.

If this indeed is the case (and I think that it happens indeed sometimes) it shouldn't !

Well, that's a side effect of the backport capabilities of the engine... sometimes you get part of the new code into the old games when you update the engine... that's inevitable.
The only way to avoid that is to "freeze" the AACW.exe (making it the "final engine for AACW").

[Generalisimo]

Well, this is sobering news Gray, but not really unexpected. I think modification of existing code base with "new" modules (I assume AGEOD uses a version of C) is one of the most challenging of tasks for a programmer. So many variables and combinations to consider.

About the only thing I can think of would be a function or subroutine that keeps track of changes to data states, calls, etc. and logs them. Might help with backtracking to find where the new portions of code are breaking the old ones. I'm sure some of this is already in the debugger function, but...

Anyhoo, hang in there Gray. I bet some kind of solution can be come to by Pocus in time. Thanks for what you do bud!

No, they use Delphi.
Without getting into much details, are you familiar with OOP? ... thanks to that is how they "unplug" an old module and replace it with the new one reducing the "risks" of failure to minimun... but there is always a % of risk that something gets broken in the way, not matter how "pure" you were with the OOP theory... specially with old games that have more than 2 years old.

[Gray_Lensman]

deleted

[PhilThib]

If this indeed is the case (and I think that it happens indeed sometimes) it shouldn't ! I suspect, for instance, that the executable file we tested, for example, in the last RC (21 ?) of 1.14 is not the same that was released, and in the final process of compiling (or whatever is the correct term) new bugs were introduced, bugs that did not exist in the beta public testing (but I may be wrong, of course )

Remember our team is small and we work on a single piece of code engine. This unfortunately creates the trouble you have known recently, and also affects us internally.
We could only escape this with more staff, more time and more funds...all of which is impossible

The only way to prevent this would mean to freeze once and for all the AACW code, and no longer provide any patches for it (beyond data / graphics ones). Personally, that's my recomendation, but I want to listen to the community before taking a decision.

It would not mean the game would be 'extinct'...just that improvements should be reserved for and when an AACW2 is made

[PhilThib]

BTW, my stress level is quite low, but my disgust level with the AACW.exe bugs is working against any desire to continue database rework until that file is brought up to the standards we all expect from AGEod.

Pocus will make a point on this, but IMHO, the AACW code should be frozen once and for all.... that would allow you to continue modding on a 'known' working basis and would save us also great amount of time. ... and last but not least, we would stop seeing post complaints about the code stability (and the corrolary request for 'improvement')

Future AACW code should come ONLY as part of an AACW2 project.

[Nikel]

as I deleted the 1.13 patch after it was installed, where might I procure it again should I decide to revert back to it?

Try not to stress Gray! All will be well in the end, I have no doubt.

Hope this helps, remember to uninstall completely

http://dlh.net/cgi-bin/dlp.cgi?lang=eng&sys=pc&file=aacw_v113b.zip&ref=ps

[Franciscus]

Pocus will make a point on this, but IMHO, the AACW code should be frozen once and for all.... that would allow you to continue modding on a 'known' working basis and would save us also great amount of time. ... and last but not least, we would stop seeing post complaints about the code stability (and the corrolary request for 'improvement')

Future AACW code should come ONLY as part of an AACW2 project.

For what it's worth, I agree completely. I would only humbly ask for a final effort to correct the bugs introduced in 1.14.

[MrT]

agreed.

[caranorn]

As long as AACW-II is an option under consideration I'd have little problem with freezing AACW engine updates. I probably still wouldn't be installing any purely community run mods though. There are lost of things that could use fixing concerning the database (old errors that I'm pretty sure were reported two years ago are still in there today, though I'd agree that they are mostly cosmetic (1st Viginia Cavalry for instance)), for that I'd still prefer an officially sanctioned team rather than individual modders...

Was going to ramble about modding at this point, but I'm a bit bitter right now and did not appreciate some remarks I got here in the forum last week. Guess I just learned to work with the database, but I'll be doing that for my own enjoyment only as it takes up time I'd better use on other game projects...

[Gray_Lensman]

deleted

[gekkoguy82]

Hope this helps, remember to uninstall completely

http://dlh.net/cgi-bin/dlp.cgi?lang=eng&sys=pc&file=aacw_v113b.zip&ref=ps

Thank you Nikel, I will grill a steak in your honor this weekend!

[Gray_Lensman]

deleted

[bigus]

This above *NoCapture* bug will have to be fixed for v1.14a along with the objective flag graphic glitch posted previously. If we can get these items reworked and providing no NEW issues arise, I would be quite content to have the game engine itself "locked".

Agreed! The cavalry rework has to be fixed (if broken by code) or this Patch is useless.


After that I suggest "lock the code". The Historical accuracy mod can then be used to post all OOB and event updates.

Note: This game has come a long way since I first played in 07. The dedication of the programmers in patches and code changes has always been first rate! The game still has a long way to go in respect to order of battle changes etc, but I think the community can handle this. However, the game code has to be stable if it is going to be the final version. lets have a stable version before you go out.

[soundoff]

<snip>


After several hours of testing, it appears the presence of a depot in the city structure allows for the taking of the city structure itself (by early cav units) regardless of the side being played. This was not previously the case when it was finalized in the later v1.14 public beta releases.

Sadly I have to accept its a bug that should be fixed but how I wish the above was the way it was designed to work.

[Big Ideas]

The person who tried to capture Bloomington MO with the early war cav used a region that probably had heaps of CSA loyalty- so you would expect the cav to RECAPTURE that region. The test was flawed.
I did a test on Norfolk VA with CSA loyalty 25% and union 75%. On turn 2 the cav from Charleston arrived day 6 and couldn't attack. All day three the same- no attack or taking of a city loyalty to the enemy.

The Bloomington MO game must have had the ST Louis Massacre event which put all the MO in high CSA loyalty thus allowing the CSA Cav to retake a friendly/loyal city.

BI

[Big Ideas]

here is another experiment. 50-50 loyalty of Harpers Ferry WA.
this time the CSA cav did attack.
also the loyalty changed to 53% after attack.

[Big Ideas]

here is CSA cav moving onto York 100% USA loyalty after taking Harpers Ferry
the cav attacked the militia but couldn't take the city.
there was a batte but couldn't capture the city.
also note that Cav can destroy rail.
also the second screen shot was taken after a turn's rest as cohension was getting low and I wanted them to be able to attack Harrisburg. But the two previous turn the cav was in assault mode.

[Big Ideas]

in the final test -though similar to the Norfolk VA test.
moving to attack Harrisburg where loyalty is 100%USA.
also the cav moved through Lancaster while on assault orders but didn't attack empty city.
CSA cav attacked the militia but couldn't capture city. depot intact
still couldn't capture empty city on next turn. depot intact though could destroy rails

So I would suggest that the early war cav cannot take cities that are disloyal to your CSA's side- similar to the USA's resrictions. It is just that the Bloomington MO test was in a loyalty friendly region and the test was void or flawed.

BI

[MrT]

thats a really intresting and dare i say it, historically correct outcome?

[Nikel]

Thank you Nikel, I will grill a steak in your honor this weekend!

lol

Do not forget some healthy vegetables


Enjoy them

[Big Ideas]

I didn't do it for an historical re-enactment- I was trying to show that the restriction on earlier war cav is working WAD. And that the people who posted about regions in MO (or any rebel loyal region) with early war cav capturing cities were flawed in their experiments and their results should be void. I'm sorry if my screen shots are unclear -but I don't know how to reduce their size to fit on the forum's screen width. But if you read my entries and look at the files then you should come to the same conclusion that this is working properly for both sides. You just need to consider the loyalty of the region your cav is attacking.

[MrT]

I think we all understood the patch to mean total no capture with early cav, but this result is better than the design we had orginally expected to recieve?

Or thats my opinion at least.

[Gray_Lensman]

deleted

[oldspec4]

My two cents..I have no problem w/ the loyalty effect on city capture ( I actually like the concept); and also agree that the AACW.exe executable should be locked down.

[enf91]

My two cents..I have no problem w/ the loyalty effect on city capture ( I actually like the concept)

+1. After all, Indians and raiders have had the same restriction since I don't know when, so essentially early cavalry used as raiders function as the unit of the same name. Of course, early cavalry have the best land scouting in the game, so they might be put to better use in advance of armies.

[Gray_Lensman]

<deleted>

[Gray_Lensman]

deleted

[arsan]

No doubt, a fix for this "not standalone" depot blowing possible woudl be the best.
But if not possible to do... I certainly would preferred the "bugged" *no capture* early cavalry kept in game (even with standalone depots kept out of harm) than going back to the previous rampaging cavalry situation.

Because... how many standalone depots exists/are created on the first year of the camping?? Maybe 2 or 3 at most??
The "bug" will have a very limited effect.
But the rampaging lone cavalry regiments blowing tracks and taking empty towns up to Minessota or down to New Orleans are a much more "noticiable" problem IMHO

Just my 2 cents!