Matrix Games Forums

Remember that you also have to account for the TOE devices. These are in the sub-units but are not exposed in the editor. One has to extract using WITPAELOAD and work with excel or a database.

Correct the TOE devices of the sub unit to match the device in that slot. Best to take a look at the numbers too. They frequently are zero or some wierd number...

ORIGINAL: Don Bowen


Remember that you also have to account for the TOE devices. These are in the sub-units but are not exposed in the editor. One has to extract using WITPAELOAD and work with excel or a database.

Correct the TOE devices of the sub unit to match the device in that slot. Best to take a look at the numbers too. They frequently are zero or some wierd number...

In talking to Michael ---its not necessary for slot:slot conformity...although that would be ideal.

I'm primarily concerned whether the sub-unit consists of the same devices as found in the parent and the parent's TO&E...not necessarily whether the slot assignments match.

ORIGINAL: treespider
So I've gone through and made a hand written list of all of the parents and next to them the sub-units.

Then under the parents I've written down the device numbers.

I then cross check the parent to the TO&E - PROBLEM - some parent divisions don't match TO&E namely in devices 775/776 in addition to the aforementioned Sqd issue.

I then place a check under each sub-unit on the line for the device...if there is a mismatch I correct the sub unit.

In some instances I've found the parent assigned device 721 - 7.7 AAMG but the subs assigned device 722 - 13.2 AAMG.

This is going to take a while...

I saw the 775/776 thing too. But didn't mess with it since 775 upgrades to 776. Think one of michaelm's tweaks has it set up so that technical device mismatches are ok so long as one of the mismatched devices upgrades to the other. Then when they recombine, they bump-up and then add together (at least that's the plan).

721 and 722 are gonna be sticky, since they each only upgrade to themselves. They are unrelated devices, so they will both appear in the newly recombined parent.

If you think that's gonna take a while, just wait till you get to the Allies ... [:D]

ORIGINAL: JWE

ORIGINAL: treespider
So I've gone through and made a hand written list of all of the parents and next to them the sub-units.

Then under the parents I've written down the device numbers.

I then cross check the parent to the TO&E - PROBLEM - some parent divisions don't match TO&E namely in devices 775/776 in addition to the aforementioned Sqd issue.

I then place a check under each sub-unit on the line for the device...if there is a mismatch I correct the sub unit.

In some instances I've found the parent assigned device 721 - 7.7 AAMG but the subs assigned device 722 - 13.2 AAMG.

This is going to take a while...

I saw the 775/776 thing too. But didn't mess with it since 775 upgrades to 776. Think one of michaelm's tweaks has it set up so that technical device mismatches are ok so long as one of the mismatched devices upgrades to the other. Then when they recombine, they bump-up and then add together (at least that's the plan).

721 and 722 are gonna be sticky, since they each only upgrade to themselves. They are unrelated devices, so they will both appear in the newly recombined parent.

If you think that's gonna take a while, just wait till you get to the Allies ... [:D]

I'ze gots a system...

...another issue I've run across - TO&E says w,x,y - Parent and sub-units also have w,x,y but also add z....except z doesn't appear in TO&E.

Talked to MM and work around is to add Z to TO&E but give it 0 devices. So when parent and subs recombine they retain the number z's and do not lose them...except future losses will not be replaced as TO&E calls for 0.

ORIGINAL: treespider
I'ze gots a system...

Okey doke, I'll meet you in Vegas ..

...another issue I've run across - TO&E says w,x,y - Parent and sub-units also have w,x,y but also add z....except z doesn't appear in TO&E.

Talked to MM and work around is to add Z to TO&E but give it 0 devices. So when parent and subs recombine they retain the number z's and do not lose them...except future losses will not be replaced as TO&E calls for 0.

That was how it worked in the beginning. The OOB guys did a lot to make opening day units as accurate as possible and that meant that many divisions might have a short FldArty Regt and an indep MedArty Btty (18 75mm and 9 15cm) on opening day and finish reorganizing 4 months later with a complete FldArty Regt (24 75mm and 12 10cm, or some other such thing). The idea was let the oddball excess 15cm devices die off by attrition, since they weren't specifically TO&E devices. There was a ton of ACs and Tankettes like that and a ton of units that had a few tankettes, but lost them the next month, or whenever they redeployed.

There's a lot of units where you want to lose the extra devices when they recombine. Some of these can be identified by one of the subs (usually a dinky thing) not ariving in-game till some later date, such that one cannot recombine until that later date; usually at that time when the parent conglomerate had undergone a reorganization (or something) and the "extra" devices in the subs should indeed disappear. Woof !!!

An alternative, that Andy, Kereguelen and Blackhorse used a lot, is not to give a parent a TO&E ID number, but put a specific TO&E underneath the unit's incoming device list (show TOE check box).
[ed] btw, that's a good method for fortresses and such where the 'underneath' TOE for captured CD naval rifles is 0, so that they don't get replaced from 'production', but still allows for installation of additional stuff over time.

Gonna have to do some looking into this, now that the upgrade/recombine thing has been worked on and fixed up. Might be a few more snakes in the grass that got uncovered.

Groin. J

Here is a view of "Arid Zona" from less than two weeks ago, Saturday April 9th. Snowed about 7" the night before, disappeared during the day, then snowed about 2" in 40 minutes and the temp went down to 22F and kept the snow good until noon the next day.

ORIGINAL: witpqs
Here is a view of "Arid Zona" from less than two weeks ago, Saturday April 9th. Snowed about 7" the night before, disappeared during the day, then snowed about 2" in 40 minutes and the temp went down to 22F and kept the snow good until noon the next day.

Wow. Actually, I was just kidding about the arid wasteland. I really do like the desert and try to get out to Ocatillo every spring because it's so gorgeous. Thanks for the pictures. Is that your deck?

Yeah, Spidey. It looks like maybe device 721 - 7.7 AAMG ought to upgrade to device 722 - 13.2 AAMG. That should nip that problem in the bud. All the early Allied .30 cal AAMGs upgrade, so why not do the same for Japan? Besides, the 13.2 was pretty pervasive and the 7.7 doesn't do all that much.

That should pretty much take care of it, yeah?

Yeah, that's the deck. Nice view of a valley and mountains on the other side across it.

ORIGINAL: witpqs

Yeah, that's the deck. Nice view of a valley and mountains on the other side across it.

What part of the SoWest are you from?

Buck

I'm a Navy Reservist and went to Fort Huachuca for several weeks of training in June 2009. I was expecting the hot and arid wasteland, but was surprised that it was usually in the 90's during the day and it rained every few days. Still wouldn't want to live there though.

ORIGINAL: Buck Beach

ORIGINAL: witpqs

Yeah, that's the deck. Nice view of a valley and mountains on the other side across it.

What part of the SoWest are you from?

Buck

I'm from New England, but we're in Arizona.

ORIGINAL: bjfagan

I'm a Navy Reservist and went to Fort Huachuca for several weeks of training in June 2009. I was expecting the hot and arid wasteland, but was surprised that it was usually in the 90's during the day and it rained every few days. Still wouldn't want to live there though.

Haven't been there, but I think it's the elevation that saved you from the real heat. Down in "The Valley of the Sun" where Phoenix is you would have fried.

In DBB scenarios the 45th Base Group (ID#5674) is set to load on TF 8407 at Canton. Is this intended?

ORIGINAL: Buck Beach

In DBB scenarios the 45th Base Group (ID#5674) is set to load on TF 8407 at Canton. Is this intended?

Yes. There were ground support troops on the Pensacola Convoy and I expect the 45th Base Group stands in for them.

ORIGINAL: Don Bowen

ORIGINAL: Buck Beach

In DBB scenarios the 45th Base Group (ID#5674) is set to load on TF 8407 at Canton. Is this intended?

Yes. There were ground support troops on the Pensacola Convoy and I expect the 45th Base Group stands in for them.

Thank you. I was confused because they have the Hawaiian USAFF as there Htqrs. I'll just change them when they find a place to settle.

Buck

It has been reported that for Device 1684 12cm AA Rocket has a "0" effect it will not work. Even though this is a carryover from the original scenarios, do you have a suggestion on what value the Effect should be. Thank you.

Yeah, forgot to include it in the public Babes fixes. Sorry 'bout that. This is what we've been using for ages. It'll get into the next updates, promise [;)].

FYI, for those using this data base for their mods/game (who are detail nuts like yours truly), most of the ships underway in TFs, at the game start, still have 100% of their fuel capacity reflecting.

Not a big deal I know but I plan on adjusting them to reflect the usage to get to their present location.

Buck

bump...