Check this Supply Situation Out (Full Version)

All Forums >> [New Releases from Matrix Games] >> World in Flames >> Tech Support



Message

palne -> Check this Supply Situation Out (9/7/2015 6:46:38 AM)

How is it possible for a UK be in supply when a USA unit stacked with it is not?




palne -> RE: Check this Supply Situation Out (9/7/2015 6:50:23 AM)

Picture of Supply Issue?

[image]local://upfiles/26519/76D8A39B31B34E2B8E973C6072FE346F.jpg[/image]



palne -> RE: Check this Supply Situation Out (9/7/2015 7:16:29 AM)

In this save, now even the UK units are not in supply even when adjacent to an HQ.

I thought maybe it had something to do with the HQ being a rebuilt Polish HQ after it was interned by the Russians and sent to the UK force pool. Meaning: The USA would not co-operate with this previously-polish HQ. I think this would be an incorrect interpretation of the rules since this HQ is not really Polish any more. I believe it is UK in all respects in this circumstance. Especially since Polish units were never added to the UK forcepool.

In addition this would not explain why the UK unit goes from "in supply" to "not in supply."

Pretty much just ended a game with this one. That is the only HQ in theatre and this game allows for corps size units to not suffer attrition while running amok out of supply in the most inhospitable place on Earth--the deep Saudi desert.

19.5.1

Once you exercise those rights, the part of Poland to the east of the
partition line becomes conquered by the Soviets. Move any Axis units
there to the nearest Axis controlled hex they can stack in. Any Allied
(except Soviet) units there are destroyed. They are removed from the
game (internment) until Germany and the USSR are at war, at which
point they may be added to the Commonwealth force pool if the
Commonwealth player so desires.
Axis units may not cross the partition line after the USSR exercises its
rights unless Germany and the USSR are at war.
Anytime after 1941, the Commonwealth can add a randomly chosen
Polish MOT and MECH to its force pools if, at that time:
 The USSR has exercised its rights under the pact; and
 Poland has been conquered by the Axis; and
 The USSR and Germany are at war.


All the Polish units covered by this rule are treated as British for all
purposes.



Centuur -> RE: Check this Supply Situation Out (9/7/2015 7:55:12 PM)

Both are bugs.



palne -> RE: Check this Supply Situation Out (9/7/2015 8:41:46 PM)

This is why a bug list would be nice to have. Assuming these were on the bug list. I didn't have to send the polish HQ to the mid east and find out a year later there's "bugs in the desert..."




Centuur -> RE: Check this Supply Situation Out (9/8/2015 3:29:04 PM)

Ah. I see. I have to be more precise next time. Sorry for this, but both bugs are not on the bug list. You've found new ones...



palne -> RE: Check this Supply Situation Out (9/8/2015 9:18:04 PM)

Can we get an answer as to why the bug list can't be posted in the forums?



Numdydar -> RE: Check this Supply Situation Out (9/9/2015 2:15:05 PM)

Unresolved bug lists for any program are seldom (never?) published publicly simply due to many people do not have a good understanding of software development. Plus you would have an uproar about why bug b was not being addressed before bug a.

In addition, 'someone' would have to update and maintain it. Along with the 'old' bug lists still being listed somewhere. Unless they were removed every time (which again 'someone' would have to do). But people could still crosspost the old list and people would be posting here about bugs that were already fixed.

So all in all posting bug lists is a bad idea all around. Which is why no one I know of posts them for commercial products.



palne -> RE: Check this Supply Situation Out (9/9/2015 5:02:07 PM)

Seems like the reasoning is a bit weak.

1. "many people won't understand them." OK. So they remain in a state of ignorance. But, those who do understand them would benefit greatly. With a game that takes months to play, it's a bit different than just reloading a previous save on an x-box when the the game crashes. It's really frustrating to have a game terminated over things you could have done differently to overcome bugs. I'm not sure too many incapable of understanding bug lists would make it through the learning curve on WiF to begin with. And, developers are missing out on a very useful source of debugging--input from users on existing bugs.
2. "fixing bug A over bug B. Managing the politics of bug fixes is well within the capabilities of matrix developers. Not doing this means players have to chose path A: enter into a months-long game knowing there are many bugs that can cause an untimely end to your activities. or "B" knowing the developer won't help you with the latest information because "other people" might not understand software development or get upset about what bugs got fixed?
3. "maintaining the bug list is a pain." Isn't that already being done anyway? The only reason this isn't being done would be because there are no bug fixes coming. In that case, there would be no reason to update the bug report. Adding new bugs to the bug list isn't any more work than responding to the forums about new bugs anyway. You would only have to post a new version of the bug list when a new version of the game came out. Interim version control seems well within the capabilities of the people I've seen posting in the forums. It's not like real-time updates is necessary. Perhaps 1/mo. with the development update.


Why do new versions of the game announce what has been fixed? If people didn't know what was broken, why tell them? It only opens the developer up to argument #2. (Probably because people like to see progress with development).
Why have people posts bugs and submit saves? It only opens the developer up to argument #2 and #3? (Probably because the benefits of user-insight outweigh the negative impacts mentioned).


I'm really glad WiF was released. It was a LONG time in coming. I'm even fine with bugs. I'm not so fine with developers holding out on information that would make my player experience better (or even possible given the number of game-ending bugs present).

It would be really nice to have a list of bugs that will create game-ending situations. For example, the whole hex-control bug situation. I was able to work around it by holding a division in reserve on a cruiser when invading (usually islands in the pacific). Then, post invasion, I would bring a cruiser to the sea zone and embark a previously invaded div (if the hex was fully stacked--3 units), and disembark that reserve div which would cause hex control to switch (as it should have previously). Sure, it's a bug. But now, it's not a game-ending bug that it had been when the USA couldn't advance through the Pacific.

I would have preferred to not have to develop this information on my own if somebody else discovered it. And, if I were the first to discover this work around, it would be great to share it with the community in a way that it could be found (forums aren't really searchable for this kind of thing).













Numdydar -> RE: Check this Supply Situation Out (9/9/2015 11:23:14 PM)

Yes but you are looking at this just from your single point of view (which is fine btw). You cannot restrict public forums to just those that understand what a bug list is and how developers would work from it. I understand and you understand it, but I can tell you than no one else in my family would have a clue. So Matrix has to take everyone into account, not just techies.

The reason that patch notes have a list of FIXED bugs is so people know what is now (hopefully working) versus it not working before. I have played many games where bugs were fixed that I never experienced. But having a list of open bugs can cause exploits/more complaining/etc.

Also you would need to have some indication of the complexity of the bug to be fixed too. There are many people here that think it is really simple to do things that would take a lot of complex coding (like the half map scenarios as an example). So if Bug A was fixed because it only took 4 hours while Bug B was not because it would take 4 weeks+ and everyone wanted Bug B fixed first, then the forums would be alive with complaints. Also people would disagree with the complexity. 'I am a software developer and it would only take me X time to fix that' would be a common occurrence. So just a bug list is not enough. Added enough information to make sense to the public would be a much harder task than just listing out what was fixed in patch notes.

Feel free to disagree [:)] but there will never be an open bug list posted here or anywhere else.



AxelNL -> RE: Check this Supply Situation Out (9/10/2015 5:48:00 AM)

apply to become a beta tester and you will receive the list if Matrix feels it could use another tester...



michaelbaldur -> RE: Check this Supply Situation Out (9/10/2015 10:44:42 AM)



more importantly .. if he had to post the list, and keep it updated. it would take time.

time taken away from solving bugs.



Centuur -> RE: Check this Supply Situation Out (9/10/2015 5:45:28 PM)

All developers need to update the bug list, so the time it takes to post it in the public forums would be only a minute.

However, I agree with the things Numdydar is saying. We all want that particular bug to be fixed first, because it is something we have ran into in the current game. Discussions about such things should be avoided, I believe.




palne -> RE: Check this Supply Situation Out (9/10/2015 10:51:27 PM)

I did apply to be a beta tester, but never heard anything back....:(



Shannon V. OKeets -> RE: Check this Supply Situation Out (9/13/2015 12:41:54 AM)


quote:

ORIGINAL: palne

I did apply to be a beta tester, but never heard anything back....:(


Sorry about that.[:(] Mea culpa.

Adding beta testers requires extra work on my part and frequently new beta testers disappear after a month or so. Some never even get started after being approved.

All in all, I am reluctant to add beta testers and deal with the learning curve for the new person: both them learning the details of being a beta tester and me learning about the new person (it's similar to acquiring a new friend).



Shannon V. OKeets -> RE: Check this Supply Situation Out (9/13/2015 1:04:58 AM)


quote:

ORIGINAL: palne

This is why a bug list would be nice to have. Assuming these were on the bug list. I didn't have to send the polish HQ to the mid east and find out a year later there's "bugs in the desert..."



Bug lists are almost always out-of-date. In my monthly reports I often have a line saying: my task lists are up-to-date. While that might seem like a throw-away comment in the report, in reality it means that I have spent 2-3 days making everything current. The joke(?) is that during those 2-3 days, there is often even newer stuff being posted or code changes being made by me, so of the 3 task lists I maintain, usually their 'current' dates are mismatched.

As a simple example of why bug lists are only of use to the developer (to make sure nothing falls through the cracks), this past week I looked into a Use Oil bug that was causing the program to halt. The cause of this problem was the new Delphi compiler (April 2015) generating an executable that was slightly different from the old compiler (circa 2010). After fixing that problem the number of bug reports I had in the category Use Oil was 10 (most of these I had identified as Use Oil problems because the accompanying screenshot had shown the Use Oil form on the screen). So having just refreshed my memory about the code related to Use Oil, I investigated 6 of those bugs and marked them as 'fixed'. Basically, they were from early 2014 (emailed bug reports with zero commentary from the player) that I had never cross-checked as having been fixed. Without remembering specific details, I am pretty sure what happened is that numerous people had reported problems with Use Oil at that time and I had fixed those problems. But I hadn't categorized all the emailed bug reports I had received, so a half dozen bug reports related to the old Use Oil bug(s) remained on my task list.

This happens a lot. I fix a problem with release A.B.C.0 and it becomes available to players in release A.B.D.0. Meanwhile I have moved on working on other stuff. Players who are still running version A.B.C.0 keep generating emailed bug reports and unless I am alert enough to see at a glance that the newly reported problem has already been fixed, it gets added to my task list until I find the time to investigate it more fully.

So more than 50% of the items on my task lists probably have already been fixed - but not investigated to the point that I am willing to removed them completely.

===
In summary the difficulty with posting list of bug reports are:
1 - Keeping the list current.
2 - Making each entry coherent for the reader (e.g., Mad Except during TAirCombatForm.FinalMessage).
3 - Distilling the proven from the suspected bugs.
4 - The time required that could be spent on investigating and fixing bugs.



Shannon V. OKeets -> RE: Check this Supply Situation Out (9/13/2015 1:22:23 AM)

This is not a bug.

Rydz is a tertiary supply source and is tracing supply through Jerusalem: a secondary supply source belonging to an Commonwealth aligned minor country. The US units cannot use the capital of a country aligned to the Commonwealth for supply.

A more common occurrence of this is when the Italians are trying to trace supply through Bucharest (which the capital of Rumania, which is aligned to Germany), or the Rumanian HQ.

[image]local://upfiles/16701/F5E4E753410A4047B02D5F048BF15DD3.jpg[/image]



Centuur -> RE: Check this Supply Situation Out (9/13/2015 9:13:12 AM)

I don't agree on this. Rydz is a CW HQ and cooperates with the US...

RAW:

18. Co-operation
Units must be able to co-operate to do certain things together. These
rules will tell you who can co-operate, what they can’t do together
even though they can co-operate, and what they can’t do together if
they don’t co-operate.

6. US and Commonwealth units co-operate provided neither is
neutral.

Units that don’t co-operate cannot:
(...)
3. draw supply from a source controlled by the other;

All the Polish units covered by this rule are treated as British for all
purposes.

Rydz has to act as a secondary supply source to both CW and US units, because the CW and US cooperate and he is considered to be a British HQ. He is on a railline, therefore able to trace to any port in the Red Sea. Since there are CW convoys points in both the Red and Arabian Sea he can trace directly to Bombay which is a primary supply source for both the CW and the US.

I conclude that this is a bug.

I don't understand why Rydz is using 4 points to go to Jerusalem. He should be using the Railroad for 0 and overseas for 1 point...





joshuamnave -> RE: Check this Supply Situation Out (9/13/2015 10:20:38 AM)

And this is why an updated bug list would be useful. I've been under the impression that this was a well known bug that just wasn't important enough to get fixed.

Any time you have a major power using a cooperating major power's HQ for secondary supply and the cooperating HQ is tracing to a secondary source for it's own major power but not for the cooperating power but COULD trace instead to a primary source, then the cooperating power's units are shown as out of supply. In other words, once the HQ finds a supply path that works for its own units it stops looking, even if that leaves cooperating units out of supply that could be supplied.



Grotius -> RE: Check this Supply Situation Out (9/13/2015 3:10:10 PM)

I've loaded up the save in the first post in this thread, and the supply state seems correct to me, though I confess I don't understand all the paths either. The only OOS units I see are the three CW units stacked three hexes northeast of Damascus and Rydz. They are more than 4 points away from either supply source because of the intervening desert hexes, so they should be OOS, shouldn't they?

In that save, I see the Americans drawing supply successfully from a primary source (Belfast) via an overseas supply route. That seems fine to me, I think.

The only question I have is similar to Centuur's: why isn't Rydz a secondary supply source? Using a railway supply link, he can trace to a primary source. If for some reason he does have to be a tertiary source, then it makes sense that he's tracing to Jerusalem, because a tertiary has to trace to a secondary or another tertiary (RAC 8.7.1.21). But why is he tertiary?

As for publishing daily bug lists publicly, I don't have strong feelings about it; but, speaking as a tester, it's already hard enough to keep track of what's been fixed in the beta-testing forum! Just yesterday I posted a bug, only to learn that Steve fixed it two days ago. I confess that I don't check the master task list every day when I test; I just play and report stuff.



Grotius -> RE: Check this Supply Situation Out (9/13/2015 3:52:47 PM)

I've also loaded the save Paine posted in his post #3 in this thread. I'm having more trouble figuring out what's going on here. This one does look like it might be a bug.

First, is Rydz in supply? His status dot is green, and when I mouseover him, it says he has an HQ supply link. But when I right click and choose "Supply Sources and Paths," then filter for OOS, he's listed as OOS.

He's also listed now as a secondary source, whereas he was tertiary in the first save. Why is that?

Now, if he is a secondary source, then he should be able to trace a railway supply path to a primary source: 2 hexes over desert to the rail, rail to Jaffa port (3rd hex), then overseas to primary. So I think he should be in supply, shouldn't he?

But the game seems to think he's out of supply, and when I select him in the 'trace path' form, all six units trying to draw from him are OOS. Thus I think the issue is not cooperation, but rather that the game thinks Rydz is OOS -- even though his status supply dot is dark green.

So this one DOES look like a bug to me.



paulderynck -> RE: Check this Supply Situation Out (9/13/2015 7:31:26 PM)

The "tertiary" source status is something Steve introduced when writing the supply routines. I confess I've never understood how or why it works or is needed, but I accept it was necessary for the way Steve wanted to program Supply.

From the boardgame point of view, all secondary sources need to trace to primary sources (either via a basic or a RR path) OR a basic path to another secondary source and from there to another, etc, as long as the last secondary in the chain can trace to a primary. The unit tracing supply is the one to be considered for cooperation and it must cooperate with all secondary sources used if there's a chain of them. But all HQs are secondary sources and Rydz is "CW for all purposes", so Rydz cooperates with US units. Rydz should be checked for a direst path to a primary first, and in both cases here, he has one.

Zartacla's post is likely a good theory of the problem here. Personally, I don't recall seeing this type of supply bug before.



BrianJH -> RE: Check this Supply Situation Out (9/14/2015 2:43:30 AM)


Is this really a bug?

A quick read of the supply rules I see this:-

"If the unit can’t trace a supply path directly to a primary supply source, it can trace it via one or more secondary supply sources instead."

This implies that a unit must try a Basic supply path to a primary supply source first, and only if one does not exist, it then tries secondary supply sources. A corollary would therefore be, that if a unit can trace a Basic supply path to a Primary supply source, then that is the units supply source, and it cannot choose a secondary supply source.

If this is the case, then MWIF would appear to be implemented correctly as that is the way that it appears to be working.

Brian.






paulderynck -> RE: Check this Supply Situation Out (9/14/2015 6:17:52 AM)

Rydz is actually able to trace a basic path to both the UK or to India in both cases, as well...

In any case your reading of the rule is overly restrictive. Every supply path that can possibly work - should work.




palne -> RE: Check this Supply Situation Out (9/15/2015 3:20:14 AM)

FYI: Z HQ is NOT a cooperating power... it is a UK unit. Per the rules:

All the Polish units covered by this rule are treated as British for all
purposes. [/quote]



Shannon V. OKeets -> RE: Check this Supply Situation Out (9/24/2015 1:58:31 AM)

Just to let everyone know, I have added this to my task list as a bug.



Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.765625