Matrix Games Forums

ORIGINAL: sPzAbt653

Found it in the What's New -

If the line connects to multiple supply points of variable values then the strongest one is broadcast over the line.

Correct. And that means that if the Axis side wants to have different FSLs in France, Russia, and Italy, the designer would have to keep the rail nets separate.

We noticed in D21 that in northern Finland, where we purposefully made supply horrible, that there was now no supply. I could guess that this is because of the movement factor calculation included in 3.4 supply rules. Not a problem at all, just mentioning it because if anyone made a scenario that included horrible supply, if they run that scenario under the 3.4 'new supply' rules, it might go from horrible to, um ... more horrible. In that case a supply point adjustment can be done, or maybe running the 'high supply' option? I haven't tried that.

ORIGINAL: sPzAbt653

We noticed in D21 that in northern Finland, where we purposefully made supply horrible, that there was now no supply. I could guess that this is because of the movement factor calculation included in 3.4 supply rules. Not a problem at all, just mentioning it because if anyone made a scenario that included horrible supply, if they run that scenario under the 3.4 'new supply' rules, it might go from horrible to, um ... more horrible. In that case a supply point adjustment can be done, or maybe running the 'high supply' option? I haven't tried that.

You could also adjust the supply radius, or I'm sure that there are a bunch of other options. I'd also hope that even though there's no supply, the units are still in supply.

Ralph

Question re. Saving in XML

In section VI. "INTERNATIONALIZATION AND CUSTOMIZATION"

The File pulldown has Open/Save Map in XML and Open/Save Game
in XML options (must not be in Force Editor).

Does this work while in scenario edit mode, while playing the game or both ?

It would be good to have a the XML version of the save file which contained all the data for the save in single file ( would make building utilities much easier

Cheers
Anthony

ORIGINAL: Anthony
Question re. Saving in XML

In section VI. "INTERNATIONALIZATION AND CUSTOMIZATION"

The File pulldown has Open/Save Map in XML and Open/Save Game
in XML options (must not be in Force Editor).

Does this work while in scenario edit mode, while playing the game or both ?

It would be good to have a the XML version of the save file which contained all the data for the save in single file ( would make building utilities much easier

Cheers
Anthony

It works in editor mode. It may work with single player games too, I don't remember. It doesn't work with PBEM, but I'm pretty sure that you can export the OOB for your side in XML.

I'm hoping that these help encourage utilities. After the next patch, I may try to write an open source editor for the OOB, the map would be hard because it would need the graphics files which are copyrighted, but it may be possible to write an editor for the rest of it that's easier to use than the current one.

The scenario viewer uses a module I built that exports XML in the same format from an .SCE file, so it's practical to work with sce files as well as XML files as long as you're doing .Net.

Ralph

I just noticed in build 173 that exporting/importing the OOB (no changes) would cause side 2 (only) to appear to be 'read-only'. I cannot selected a unit on the right pane. Sorry about the bad pic quality, blame the 200kb limit.

ORIGINAL: Erik Nygaard

I just noticed in build 173 that exporting/importing the OOB (no changes) would cause side 2 (only) to appear to be 'read-only'. I cannot selected a unit on the right pane. Sorry about the bad pic quality, blame the 200kb limit.

Thanks Erik,
I can verify it, it isn't setting the parent correctly when loading the OOB. I'm not sure how I missed that, I know I saved and reloaded and checked that the files were the same. It will be fixed for release.

Question-

Is there any way to get rid of the floating thing that shows whats in each hex?

ORIGINAL: edk2384

Question-

Is there any way to get rid of the floating thing that shows whats in each hex?

Check this to see if maybe this is what you are talking about :

tm.asp?m=2545467

quote:

ORIGINAL: JAMiAM

Hi all,

I know it's been forever in coming, but patch 3.4 is right around the bend


James,

I used to have a car like that.

Best wishes,
Steve

I used to have a girlfriend like that.

A few questions. I apologise if the answers are obvious, but couldn't get them, myself...

From the What's New Document:

Clouds even move between player-turns – just without weather effects.

Does this mean that one cannot rely on the weather effects of a given hex under a cloud, or rain, being what one would expect under a cloud, or rain?

From the What's New Document:

Also, note that movement recovery is done twice for each side (start of each player-turn). This will clear
the “Retreated” condition for both sides during their own player-turn (previously an unfair advantage for side-one).
It may even make use of reserve deployments more palatable to players.

I don't suppose there was any thought given to having half of the movement points 'regenerate' at the end of each turn, eh? Meaning a unit that was pushed around to max MP would be penalized for that, but also given a chance to retreat, as well?
(Yes, of course I should have brought this up before the patch came out )

From the What's New Document:

23. Old ACOW bug that caused bogus attacker evaporations was found and fixed.

Kudos, and how the heck did you find that?

Lastly:
Thanks again, boys.

I'm not sure what the cloud comment meant. They should be accurate, I think.

We did think about recovering half. This was back when this was supposed to be a simpler patch, so I opted for the simpler solution.

I don't remember exactly, but it was probably while grinding through one of Bob's test scenarios. I think he spits them out daily, and was willing to spend hours in working them to see the results in Excel to point out the bugs I'd introduced.[:(] it's a far better game because of that!

ORIGINAL: ralphtrick

I'm not sure what the cloud comment meant. They should be accurate, I think.

We did think about recovering half. This was back when this was supposed to be a simpler patch, so I opted for the simpler solution.

I don't remember exactly, but it was probably while grinding through one of Bob's test scenarios. I think he spits them out daily, and was willing to spend hours in working them to see the results in Excel to point out the bugs I'd introduced.[:(] it's a far better game because of that!

The cloud comment was at the bottom of the first paragraph of the player 1/2 balancing section. But, if the clouds are accurate, good.

Okiedokie.

Well that you Mr. Cross for the hours of work on this one.

ORIGINAL: Veers

ORIGINAL: ralphtrick

I'm not sure what the cloud comment meant. They should be accurate, I think.

We did think about recovering half. This was back when this was supposed to be a simpler patch, so I opted for the simpler solution.

I don't remember exactly, but it was probably while grinding through one of Bob's test scenarios. I think he spits them out daily, and was willing to spend hours in working them to see the results in Excel to point out the bugs I'd introduced.[:(] it's a far better game because of that!

The cloud comment was at the bottom of the first paragraph of the player 1/2 balancing section. But, if the clouds are accurate, good.

Okiedokie.

Well that you Mr. Cross for the hours of work on this one.

Weather effects: mud, snow, etc. are only figured once per turn. But clouds move between player turns - so you can't put a ship under a cloud on your player turn and know that it will still be under that cloud during the enemy player turn. Otherwise, player one could exploit this, but not player two.

ORIGINAL: Curtis Lemay

ORIGINAL: Veers

ORIGINAL: ralphtrick

I'm not sure what the cloud comment meant. They should be accurate, I think.

We did think about recovering half. This was back when this was supposed to be a simpler patch, so I opted for the simpler solution.

I don't remember exactly, but it was probably while grinding through one of Bob's test scenarios. I think he spits them out daily, and was willing to spend hours in working them to see the results in Excel to point out the bugs I'd introduced.[:(] it's a far better game because of that!

The cloud comment was at the bottom of the first paragraph of the player 1/2 balancing section. But, if the clouds are accurate, good.

Okiedokie.

Well that you Mr. Cross for the hours of work on this one.

Weather effects: mud, snow, etc. are only figured once per turn. But clouds move between player turns - so you can't put a ship under a cloud on your player turn and know that it will still be under that cloud during the enemy player turn. Otherwise, player one could exploit this, but not player two.

That's good.
So, to be clear, on player one and two's turns the clouds will have their 'desired' effect, where you see them, at that time?

ORIGINAL: Veers
That's good.
So, to be clear, on player one and two's turns the clouds will have their 'desired' effect, where you see them, at that time?

Yes.

I had the original TOAW game. Recently I purchased TOAW3 which has many improvement, obviously, including ELMER. Just getting back into the game and I am feeling my way along with the PO/ Elmer. All formations seem to have tracks preset. Why is the track to the 1st Obj. red and why does it always seem to be behind the formation? Also why do the tracks zig zag so much rather than taking a straight ahead path?
I deleted the 1st Obj and asked the PO to resequence and the blue conecting line then went to the 2nd Obj. What did I actually do there? Why wasn't it red?
When an Obj. is obtained, will the formation then attempt to move on tho the next Obj?
Thanks for the help.

Greg

All formations seem to have tracks preset.

This varies between scenarios as the tracks are set by the designer. Some tracks are set with the full intention of making a game of it. Some tracks are set only to meet certain requirements and will therefore not make a game of it.

Also why do the tracks zig zag so much rather than taking a straight ahead path?

I can't answer for all cases, but maybe in the hopes that the formation will cover some territory as opposed to heading in a straight line. The best way to try and get the PO to conquer all territory is to assign objectives to each hex. You could have objective 1 at hex 0.22, and objective 2 at hex 39.22. This will leave the PO on it's own to determine the best route to take from 1 to 2. Or you could place one objective in each of the 39 hexes, hoping that Elmer will take your advice (not always true).

When an Obj. is obtained, will the formation then attempt to move on tho the next Obj?

Maybe ! Trial and error playtesting is the best way to be sure. There is more to it than the objective placement. Formation Orders, Formation Bias and Formation Loss Settings also have an influence. Elmer also monitors the overall situation on the map.

I'm not clear about your other questions so I will not offer anything there. Are you designing something or just trying to get a better understanding of your opponent ?

Thanks for the response. I think I'm getting the hang of it now. I still don't understand why the first line in the objective track is red and the others Blue. Is this important?
Also one more thing concerning supply on the map. Why are some of the numbers encased in orange and most of the others blue? This has to mean something and I can't find anything in the manual about it. Thanks again.

ORIGINAL: GBS

Thanks for the response. I think I'm getting the hang of it now. I still don't understand why the first line in the objective track is red and the others Blue. Is this important?
Also one more thing concerning supply on the map. Why are some of the numbers encased in orange and most of the others blue? This has to mean something and I can't find anything in the manual about it. Thanks again.

The red objective line is the path from the formation's units towards objective 1

The supply colors mean that that hex will give that amount of supply to one side (red/blue) or both (orange)