Matrix Games Forums

Another problem i just found.
No idea what this can be. Even with new rules after patching the fuel and resources can´t simply disappear
within one turn, or ? Moving yes, but not disappear.
For me this is a bit too much...

I did not lose convoys with the res/fuel in question in this turn. So where is it ?

Forgot to wish you guys a HAPPY NEW YEAR ! [:)]

ORIGINAL: seille

Another problem i just found.
No idea what this can be. Even with new rules after patching the fuel and resources can´t simply disappear
within one turn, or ? Moving yes, but not disappear.
For me this is a bit too much...

I did not lose convoys with the res/fuel in question in this turn. So where is it ?

This is linked the the other problem with the res histories... to make sure can you send me the two saves please... I want to test it thanks

[edit] Oh and Happy New Year - although I've got a really bad hangover today

Sent the two files to your mail adress. Pls confirm you got them.

After loading a new turn into tracker the gaps moved.
I have now a 170.000 fuel gap between turn 81 and 82.
For resources i have now a gap of 60.000 between turn 85 and 86.

It seems these values are changing with every new turn i load. Maybe this helps in finding the problem.

Two small ones

In version 1.7.1, I believe the new ship loading calculation (in the base display, bottom detail) is incorrect for resources. On the opening turn of for scenario 2, as Japan, I get 19600 in Matsuyama. Now the port is three (ie 1200 / day), there are 225 naval point (ie 2250 more) and is produces 460 resources (ie 2300 more). Result should be around 5500-6000, I believe.

For Ominato, I get 4400, whereas I have 443 naval support (which already represent more than that...)
For Hakodate 5600, whereas it should be a bit under 4000 (6 port = 2400, 80 resources = 400, 112 Naval support = 1120)

In the Industry Redional Ind repair tab, the "lower table" data only gets updated if you change line and column selected. If you click on another line on the same column, the update does not fire.

Francois

ORIGINAL: fcharton

Two small ones

In version 1.7.1, I believe the new ship loading calculation (in the base display, bottom detail) is incorrect for resources. On the opening turn of for scenario 2, as Japan, I get 19600 in Matsuyama. Now the port is three (ie 1200 / day), there are 225 naval point (ie 2250 more) and is produces 460 resources (ie 2300 more). Result should be around 5500-6000, I believe.

For Ominato, I get 4400, whereas I have 443 naval support (which already represent more than that...)
For Hakodate 5600, whereas it should be a bit under 4000 (6 port = 2400, 80 resources = 400, 112 Naval support = 1120)

I think you might be partially right here and I'll do some checking too...

Resource load rates are not affected by Naval support iirc. Matsuyama for example 1200 / day Port size +
460*20 = 9200 so LR = (9200 + 600) *2; In my testing I think I found the half requirement or Res was not how it was calculated (the manual). Anyway I'll have a retest

In the Industry Redional Ind repair tab, the "lower table" data only gets updated if you change line and column selected. If you click on another line on the same column, the update does not fire.
Francois

Yeah - this is Working as designed at present as I couldn't get it to do both when I first did it. It should work on the same row, but then when you change column you need to select another row to make it fire.

Hi Damian,

ORIGINAL: n01487477
Resource load rates are not affected by Naval support iirc. Matsuyama for example 1200 / day Port size +
460*20 = 9200 so LR = (9200 + 600) *2; In my testing I think I found the half requirement or Res was not how it was calculated (the manual). Anyway I'll have a retest

Here are the results of a more precise test. You are right that naval support has no effect, but the formula above overestimates the effect of resources.

Ominato : Port size 5, 60 resources : 3200, naval support or not, so that would be 1000*2 + 60*20, ie the halving of resources would be per phase (over a day, it is just the resources produced, not multiplied by 2)

Muroran : Port size 3, 60 resources : 2400, 600*2 + 60*20

So I guess Matsuyama would be 1200 + 9200 = 10400, but this cannot be tested for lack of large enough cargoes...

It would be interested to see whether unloading is strictly symmetrical, or will be helped by naval support (the manual suggests so).

Francois

Hi Trackers,
 
Wondering if someone can help me out on this.
 
When using the upgrade to (path) function, I am wondering how I can discover what type(s) of plane i have to upgrade to, before this "path"opens?
 
Cheers,
 
d0mbo.
 

This screen i get when i choose avalable,cv capable planes (choosing "CV capable" first then "available")
I have no idea why Sally II is in that display for example ? Do i something wrong here or is it a tracker problem ?

Hope to get a hotfix soon for the resource history problem. Together with the ingame problem of new resource flow it makes
resource convoy setup not easier for japan.

ORIGINAL: seille

This screen i get when i choose avalable,cv capable planes (choosing "CV capable" first then "available")
I have no idea why Sally II is in that display for example ? Do i something wrong here or is it a tracker problem ?

Hope to get a hotfix soon for the resource history problem. Together with the ingame problem of new resource flow it makes
resource convoy setup not easier for japan.

Looks like when you select the checkbox and anything else is set to filter, it doesn't work. If you set the Status back to "All", it should work. Damian needs to look at this section of code, since I'm having trouble figuring out what he's doing here.

As for the resource issue, I think we have a fix and I'm working on it now.

Floyd

Great What would i do without you guy´s and this great tool ? [&o]

A few of the more important bugs were fixed, so here is Release 1.7.1.

Download from the regular place: here.

New Features:
[*]none

Bugs Fixed:
[*]Resource histories properly aligned
[*]Liquid (oil and fuel) load rates corrected
[*]Null pointer exception fixed in Air Production panel

Known Issues:
[*]nothing new

Enjoy!

Floyd and Damian

Thank you very much! [:)]

Replacing the .jar file with the new version will update my 1.7 tracker databases, right?

ORIGINAL: VSWG

Thank you very much! [:)]

Replacing the .jar file with the new version will update my 1.7 tracker databases, right?

Yes, just replace the .jar file. The 1.7 database is completely compatible with 1.7.1 and no updates are needed.

All the resource histories seem to be working fine now. Thank you!

First many thanks for the new version.

I just found another possible problem. At least i cannot explain myself.

I just studied the details of two air groups in tracker that had high losses during the last turn.

Ingame Zero unit:
KIA: 6
WIA:2
MIA:3

Tracker airgroups->history (for the current turn):
-11 pilots (right)

Tracker air groups->pilots (for the turn in question):
KIA: 1
WIA:2
MIA:3

The top row for pilot details shows:
Pilots: Active:49 Delayed (1 Day):9(1) WIA:2 MIA:7 KIA:1

As you see that pilot history can´t be true. Overall that Zero unit lost 30+ pilots so far.
Why i don´t get the real numbers looking at air groups->"pilots" ?
Do tracker delete/ignore pilots and their faith ?

ORIGINAL: seille

First many thanks for the new version.

I just found another possible problem. At least i cannot explain myself.

I just studied the details of two air groups in tracker that had high losses during the last turn.

Ingame Zero unit:
KIA: 6
WIA:2
MIA:3

Tracker airgroups->history (for the current turn):
-11 pilots (right)

Tracker air groups->pilots (for the turn in question):
KIA: 1
WIA:2
MIA:3

The top row for pilot details shows:
Pilots: Active:49 Delayed (1 Day):9(1) WIA:2 MIA:7 KIA:1

As you see that pilot history can´t be true. Overall that Zero unit lost 30+ pilots so far.
Why i don´t get the real numbers looking at air groups->"pilots" ?
Do tracker delete/ignore pilots and their faith ?

Yeah the ingame record is different from ours as we only look at current pilots still in the DB. We don't take the game history which counts deceased pilots as a whole even after they are removed. Once the game deletes pilots we don't have those records anymore.

We are only trying to include DB points now that we feel are essential as the DB struggles with too many records.

Ok Damian, i already expected something like this.

But there is still something i can´t follow.
When i look into air groups->pilots for the unit in question it shows only
1 of the 6 killed pilots. Same time it shows some pilots MIA in earlier turns.
Do you delete just killed pilots ??
And if yes, why even the killed ones from curreent turns ?

Can´t you allow a time window for deleting of let´s say 20 turns ?
Show the killed pilots for 20 more turns and then remove them ?
Hard to believe that the killed pilots of 20 turns make the DB exploding.

I simply wanted to check which of my high XP pilots died this turn and it was not possible since only
one KIA was shown instead of the 6 that died. Another good question is why he was still there and the other 5 weren´t [:D]

ORIGINAL: seille

Ok Damian, i already expected something like this.

But there is still something i can´t follow.
When i look into air groups->pilots for the unit in question it shows only
1 of the 6 killed pilots. Same time it shows some pilots MIA in earlier turns.
Do you delete just killed pilots ??
And if yes, why even the killed ones from curreent turns ?

Can´t you allow a time window for deleting of let´s say 20 turns ?
Show the killed pilots for 20 more turns and then remove them ?
Hard to believe that the killed pilots of 20 turns make the DB exploding.

I simply wanted to check which of my high XP pilots died this turn and it was not possible since only
one KIA was shown instead of the 6 that died. Another good question is why he was still there and the other 5 weren´t [:D]

AE deletes the pilots each turn if they have no kills iirc (or there maybe a min kill no)... we just refresh the pilots list deleting those that no longer have a record... if we didn't do this then if a new pilot uses that number we'd be inaccurate.