Matrix Games Forums

ORIGINAL: n01487477

Thanks - we don't know all the codes but at least we can rectify the 2012 as kamikaze.

Cheers

I think that would be helpful, and I'm not much of a Java programmer (one course, long ago), but my head-scratcher is WHERE it came up with a Device 2012? That's a couple of hundred numbers higher than the Device list in the Editor. I wouldn't want to instigate breaking something else. My karma couldn't stand the load right now. [:)]

Hi,

Tracker does not seem to see (Japanese) troop-converted cargoes. In all lists, they appear exactly the same as their regular counterparts (which means their capacity is incorrect).

Damian, where can the R&D-improved version you presented a few posts above be downloaded? ON the website, I only see the April 2011 release. Is there a special beta directory or something?

Thanks in advance,
Francois

ORIGINAL: Bullwinkle58

ORIGINAL: n01487477

Thanks - we don't know all the codes but at least we can rectify the 2012 as kamikaze.

Cheers

I think that would be helpful, and I'm not much of a Java programmer (one course, long ago), but my head-scratcher is WHERE it came up with a Device 2012? That's a couple of hundred numbers higher than the Device list in the Editor. I wouldn't want to instigate breaking something else. My karma couldn't stand the load right now. [:)]

The 2000 range are special devices (2005 is "Sunk by foundering", for example). Send me a save (witptracker@gmail.com) so I can test my fix.

[EDIT: With the save, I fixed that one and few others I never saw before (collision, marine casualty).]

Floyd

ORIGINAL: fcharton

Hi,

Tracker does not seem to see (Japanese) troop-converted cargoes. In all lists, they appear exactly the same as their regular counterparts (which means their capacity is incorrect).

Thanks Francois - I'll have a look into that for you.[edit]I think we knew about it, just hadn't implemented the 1/3 cargo space to troop capacity for "-t" ships.

Damian, where can the R&D-improved version you presented a few posts above be downloaded? ON the website, I only see the April 2011 release. Is there a special beta directory or something?

Thanks in advance,
Francois

That version hasn't been released yet, so it is unavailable at this time. I guess I should chat about a release date with Floyd soon; but we're both working pretty hard these days. And I haven't finished a lot of tracker code that I'd like to include. Maybe I will just have to wait until 2.0.

ORIGINAL: n01487477

ORIGINAL: fcharton

Hi,

Tracker does not seem to see (Japanese) troop-converted cargoes. In all lists, they appear exactly the same as their regular counterparts (which means their capacity is incorrect).

Thanks Francois - I'll have a look into that for you.[edit]I think we knew about it, just hadn't implemented the 1/3 cargo space to troop capacity for "-t" ships.

[/quote]

Done for the next release ... actually the manual is wrong; it is a quarter of cargo, rounded to the nearest multiple of 5 and then added to troop capacity.

ORIGINAL: floydg

[EDIT: With the save, I fixed that one and few others I never saw before (collision, marine casualty).]

Floyd

Glad I could help.

Is there a regions file for Andrews extended map mod? I just installed DaBigBabes 'C' and was looking for a regions file for it.

ORIGINAL: Graymane

Is there a regions file for Andrews extended map mod? I just installed DaBigBabes 'C' and was looking for a regions file for it.

Not sure if JWE's region file works properly (in the region-mappings folder)... otherwise I'd start with Kull's or JWE's and modify. Maybe ask in the specific scenario thread too.

We don't have the time to maintain up-to-date region mappings files with all the different mods; so if you come up with a good one send it on and we'll include it.

Thanks

Some technical question.

It seems that you are using some sort of internal database library to store the tracker data.
What i saw now, cause i have some performance problems (have a very large database with lot of turns) that whenever i launch the tracker that the system resources for my local wlan (Intel driver) skyrocket to almost 50% too. Is it possible that with your connection to the database you are using the external IP adress and not the internal loopback so all traffice regarding to loading the tracker are looped over the external network connection and not the internal loopback ?

I haven't tracked it in detail but it seems a little bit strange (and could be responsible for some of the performance problem during loading).

WLKEEPER.exe is the Intel drivers of the WLAN.

ORIGINAL: beppi

Some technical question.

It seems that you are using some sort of internal database library to store the tracker data.
What i saw now, cause i have some performance problems (have a very large database with lot of turns) that whenever i launch the tracker that the system resources for my local wlan (Intel driver) skyrocket to almost 50% too. Is it possible that with your connection to the database you are using the external IP adress and not the internal loopback so all traffice regarding to loading the tracker are looped over the external network connection and not the internal loopback ?

I haven't tracked it in detail but it seems a little bit strange (and could be responsible for some of the performance problem during loading).

WLKEEPER.exe is the Intel drivers of the WLAN.

Nope we don't use any lan connections or external IP's our DB is controlled by
"org.hsqldb.jdbcDriver" connected directly to the DB file.

ORIGINAL: n01487477

ORIGINAL: beppi

Some technical question.

It seems that you are using some sort of internal database library to store the tracker data.
What i saw now, cause i have some performance problems (have a very large database with lot of turns) that whenever i launch the tracker that the system resources for my local wlan (Intel driver) skyrocket to almost 50% too. Is it possible that with your connection to the database you are using the external IP adress and not the internal loopback so all traffice regarding to loading the tracker are looped over the external network connection and not the internal loopback ?

I haven't tracked it in detail but it seems a little bit strange (and could be responsible for some of the performance problem during loading).

WLKEEPER.exe is the Intel drivers of the WLAN.

Nope we don't use any lan connections or external IP's our DB is controlled by
"org.hsqldb.jdbcDriver" connected directly to the DB file.

As Damian said, no LAN connections are explictly made by WitPTracker.

ORIGINAL: beppi

Some technical question.

It seems that you are using some sort of internal database library to store the tracker data.
What i saw now, cause i have some performance problems (have a very large database with lot of turns) that whenever i launch the tracker that the system resources for my local wlan (Intel driver) skyrocket to almost 50% too. Is it possible that with your connection to the database you are using the external IP adress and not the internal loopback so all traffice regarding to loading the tracker are looped over the external network connection and not the internal loopback ?

I haven't tracked it in detail but it seems a little bit strange (and could be responsible for some of the performance problem during loading).

WLKEEPER.exe is the Intel drivers of the WLAN.

I assume the HD with the tracker database is local to your PC and not on LAN-connected HD.

ORIGINAL: michaelm

ORIGINAL: beppi

Some technical question.

It seems that you are using some sort of internal database library to store the tracker data.
What i saw now, cause i have some performance problems (have a very large database with lot of turns) that whenever i launch the tracker that the system resources for my local wlan (Intel driver) skyrocket to almost 50% too. Is it possible that with your connection to the database you are using the external IP adress and not the internal loopback so all traffice regarding to loading the tracker are looped over the external network connection and not the internal loopback ?

I haven't tracked it in detail but it seems a little bit strange (and could be responsible for some of the performance problem during loading).

WLKEEPER.exe is the Intel drivers of the WLAN.

I assume the HD with the tracker database is local to your PC and not on LAN-connected HD.

It is not uncommon that today you do a abstraction on the TCP Layer 7 and no longer care for System/Lan/Wan or anything else. You usually do not even care about any protocols as the libraries in combination with the operating system handle whatever you need.

From a quick look it seems that org.hsqldb.jdbcDriver works exactly that way and does not distinguish between System and Lan and Wan and anything else as a local connection would just be a local connection on the loop back.

And as i know from experience (saw that problems more than once in software or system configuration) for example if you access your localhost (127.0.0.1) not by that IP(or by localhost as name) instead by your external IP that all traffic is looped over the NIC (at least the driver if it is good developed, but even saw once communication to the next switch and back to the NIC, if you use more than one IP Adress). And don't think that any data is sent to the LAN instead it seems that for an unknown reason during loading of the tracker the driver of the NIC uses and unusual high amount of system resources.

Saw that problem once in an ESX Environment when everyone was complaining of the bad performance between the different VMS, and instead of the local connection between the VMS the external IPS where accessed which resulted in a heavy load on the NIC.

It was just an idea when i saw that problem today and could be a bad configured notebook (Company one) or some other driver which forces all local connections over the NIC (Anti Virus stuff or security stuff or VPN Stuff or whatever [;)]). Will track it a little bit further if i have time and as i said was just a question.

ORIGINAL: n01487477

ORIGINAL: beppi

Some technical question.

It seems that you are using some sort of internal database library to store the tracker data.
What i saw now, cause i have some performance problems (have a very large database with lot of turns) that whenever i launch the tracker that the system resources for my local wlan (Intel driver) skyrocket to almost 50% too. Is it possible that with your connection to the database you are using the external IP adress and not the internal loopback so all traffice regarding to loading the tracker are looped over the external network connection and not the internal loopback ?

I haven't tracked it in detail but it seems a little bit strange (and could be responsible for some of the performance problem during loading).

WLKEEPER.exe is the Intel drivers of the WLAN.

Nope we don't use any lan connections or external IP's our DB is controlled by
"org.hsqldb.jdbcDriver" connected directly to the DB file.

If other machines can access the database, even theoretically, there will be a connection.

ORIGINAL: floydg

ORIGINAL: n01487477

ORIGINAL: beppi

Some technical question.

It seems that you are using some sort of internal database library to store the tracker data.
What i saw now, cause i have some performance problems (have a very large database with lot of turns) that whenever i launch the tracker that the system resources for my local wlan (Intel driver) skyrocket to almost 50% too. Is it possible that with your connection to the database you are using the external IP adress and not the internal loopback so all traffice regarding to loading the tracker are looped over the external network connection and not the internal loopback ?

I haven't tracked it in detail but it seems a little bit strange (and could be responsible for some of the performance problem during loading).

WLKEEPER.exe is the Intel drivers of the WLAN.

Nope we don't use any lan connections or external IP's our DB is controlled by
"org.hsqldb.jdbcDriver" connected directly to the DB file.

As Damian said, no LAN connections are explictly made by WitPTracker.

Ok to clarify the case, your are right and i was clearly wrong.

It was just and idea and i did some traces with Wireshark, and not traffic is running over the external IP of the NIC (even if it is loopbacked by the NIC) and did a quick check with RawCap and no traffic is done over the internal loopback (127.0.0.1) (but dont shoot me if it is done, as not that easy to capture loopback traffic on windows).

Will have to track why the NIC driver uses so much resources. Could be a windows task manager display problem or something else.

ORIGINAL: beppi
Will have to track why the NIC driver uses so much resources. Could be a windows task manager display problem or something else.

Have you considered the probability that since the Database is been installed in memory that the OS may well be swapping data from internal cache space to swap space on disk. Have you checked for any disk thrashing?

Screen for consideration ...
Two new columns. I wanted to make the building no's more manageable or understandable. I think I've just made it more complicated... But anyway.

upg(Total)
The first no. = current (delayed and arrived) direct upgrade or the next upgrade for a group.
The (Total) = the first no. + grp PDU OFF upgrade path (so I iterate through all the groups and see what will upgrade to this type (PDU OFF))

Rec.B =TBO.YTA + upg(Total); Hence you can just by looking at this number determine how many planes your need to build of a certain model.

I was also thinking here that this Rec.B could have some intelligence in regard to the time of the next upgrade. Take the A6M2, some of the delayed groups are well beyond the later models availablility and maybe shouldn't have their max numbers incorporated into the Rec.B. I could compensate for that in parenthesis... maybe I'm just becoming too picky.

Comments or suggestions?



At this stage it is only tuned for PDU OFF, but I think it will give enough info for the time being. Maybe later if I get enough feedback I'll modify for PDU ON...

As it happens I have just been struggling with planning aircraft production and R&D. I could have used this benefit that you have added. Not enough data is way worse than too much. In this case though, I do not thing you have complicated matters at all.

You may want to add the option to allow the user to hide columns or re-order them.

A second thing that has occurred to me in the past is that 'sortable' columns need a marker to indicate this facility.

Since you have asked for suggestions, in this context I have an item on my wishlist.

I would like to see a suite of Pert Diagrams (or Gantt Charts) that clearly maps the progression of ship and aircraft manufacturing, r&d, upgrades and conversions.
Sometimes pictures are far easier to grasp and/or manipulate than arrays of complex (and sometimes disjoint) data sets.

Oh yes...

One final wish...


Please release 1.9 Yesterday! [;)]

ORIGINAL: bk19@mweb.co.za

As it happens I have just been struggling with planning aircraft production and R&D. I could have used this benefit that you have added. Not enough data is way worse than too much. In this case though, I do not thing you have complicated matters at all.

Thanks, I'm glad my initial efforts are finding positive review.

You may want to add the option to allow the user to hide columns or re-order them.

You can reorder them now. Hide no ...

A second thing that has occurred to me in the past is that 'sortable' columns need a marker to indicate this facility.

Nearly all of the columns in Tracker are sortable... which ones aren't?

Since you have asked for suggestions, in this context I have an item on my wishlist.

I would like to see a suite of Pert Diagrams (or Gantt Charts) that clearly maps the progression of ship and aircraft manufacturing, r&d, upgrades and conversions.
Sometimes pictures are far easier to grasp and/or manipulate than arrays of complex (and sometimes disjoint) data sets.

I'll look into it. I'm a visual person too - my g/f says I never listen.

ORIGINAL: bk19@mweb.co.za
Oh yes...
One final wish...
Please release 1.9 Yesterday! [;)]

You do realise we are no-profit...[;)] It'll be done when it's done. But we hear you.