Release [Explorer's Application] Captain's Log

[disorganise]

Still on 2.1.5 here but I noticed that yttrium is being shown as a red icon which I believe is intended to mean very rare, whereas it is actually rare. It's been there a couple of versions at least cos I noticed that EDD shows it as yellow....but only this morning I got around to actually checking inventory.

Also a request...
In 1.x we used to have an overall summary of bodies scanned on this trip. Will (can) this come back? [or...how to get to it if it is already there but I'm not seeing it?]

And some suggestions (more work so...):
On the assumption that an overall body count per body classification exists, it would be nice to click the body type (eg ELW) and see the list of systems.....even better if we can then single click the system name to clipboard to paste into ED
Also, it would be cool to search/filter for nearest bodies (systems) with a particular material, sorted in concentration, and 'green' systems. All based off your current location.
Now...i know EDDB can do this (badly for multiple mats imo) but....you could make it based off the local DB only and thus not be based on 'crowd sourced' information. (similar philosophy to TCE for trading data).
Just for fun, perhaps add a 'highest value system' button/text box (name and value). Perhaps also one for greatest body count.
Staying with the theme of the local DB v crowd source data.....I'd also like to know my personal 'records'. What's the hottest/coldest star *I've* scanned this trip, what's the highest concentration of polonium...etc

As always, feel free to ignore the stupid (sub optimal to be more PC I s'pose) concepts and thanks for an awesome tool o7

 

[Genar-Hofoen]

Still on 2.1.5 here but I noticed that yttrium is being shown as a red icon which I believe is intended to mean very rare, whereas it is actually rare. It's been there a couple of versions at least cos I noticed that EDD shows it as yellow....but only this morning I got around to actually checking inventory.

Also a request...
In 1.x we used to have an overall summary of bodies scanned on this trip. Will (can) this come back? [or...how to get to it if it is already there but I'm not seeing it?]

And some suggestions (more work so...):
On the assumption that an overall body count per body classification exists, it would be nice to click the body type (eg ELW) and see the list of systems.....even better if we can then single click the system name to clipboard to paste into ED
Also, it would be cool to search/filter for nearest bodies (systems) with a particular material, sorted in concentration, and 'green' systems. All based off your current location.
Now...i know EDDB can do this (badly for multiple mats imo) but....you could make it based off the local DB only and thus not be based on 'crowd sourced' information. (similar philosophy to TCE for trading data).
Just for fun, perhaps add a 'highest value system' button/text box (name and value). Perhaps also one for greatest body count.
Staying with the theme of the local DB v crowd source data.....I'd also like to know my personal 'records'. What's the hottest/coldest star *I've* scanned this trip, what's the highest concentration of polonium...etc

As always, feel free to ignore the stupid (sub optimal to be more PC I s'pose) concepts and thanks for an awesome tool o7

Weirdly enough, after I release 2.1.6, I was going to embark on what I'm calling the Galaxy Browser (for now). Great minds must think alike, because I was talking about this on the Discord server a couple of days ago, and you've voiced here a lot of the similar things I'd like to see in CL2 too - even right down to what I was describing as the 'Find me a material' function

I haven't heard any negative sounds from anyone using the 2.1.6 betas (it's now up to beta 3) , so I may just release 2.1.6 fully tomorrow. That'll free me up to start work on the 2.2.0 release and with it the 'Galaxy Browser'.

 

[disorganise]

Bug report: Herbigs. (2.1.5 iirc)
I stumbled into a herbig system this morning and after scanning the star, CL did not display any worth. When I scanned a HMC the system value was just that HMC.
So it would appear that herbigs aren't being 'detected' (I guess they could also be 0 value but then I'd expect 0 to be displayed).

 

[Genar-Hofoen]

Bug report: Herbigs. (2.1.5 iirc)
I stumbled into a herbig system this morning and after scanning the star, CL did not display any worth. When I scanned a HMC the system value was just that HMC.
So it would appear that herbigs aren't being 'detected' (I guess they could also be 0 value but then I'd expect 0 to be displayed).

Thanks - I'll check into that. Currently there's CL2 2.1.6 beta 3, so I may try to fix that in a beta 4. I'll let you know.

Regards

 

[disorganise]

Thanks - I'll check into that. Currently there's CL2 2.1.6 beta 3, so I may try to fix that in a beta 4. I'll let you know.

Regards

It occured to me the journal entry might be of use, so:

{
"timestamp": "2017-10-29T19:33:45Z",
"event": "Scan",
"BodyName": "Aidohs WO-R e4-0",
"DistanceFromArrivalLS": 0.0,
"StarType": "AeBe",
"StellarMass": 4.300781,
"Radius": 86130944.0,
"AbsoluteMagnitude": 9.859924,
"Age_MY": 2,
"SurfaceTemperature": 5158.0,
"Luminosity": "VI",
"RotationPeriod": 3778.449463,
"AxialTilt": 0.0,
"Rings": [
{
"Name": "Aidohs WO-R e4-0 A Belt",
"RingClass": "eRingClass_Rocky",
"MassMT": 483120000000000.0,
"InnerRad": 139450000.0,
"OuterRad": 3924200000.0
}
]
}


And a screenie.....Interesting - the star scan is not registered at all [and it was a class I not a HMC ....bad memory when writing from the bus]

 

[disorganise]

Sorry....but I also just noticed that Niobium is being coloured the same as Cadmium, but Cd is rare and Nb is standard - I noticed cos the scan I just did had more Cd than Nb so I checked

 

[Genar-Hofoen]

It occured to me the journal entry might be of use, so:

{
"timestamp": "2017-10-29T19:33:45Z",
"event": "Scan",
"BodyName": "Aidohs WO-R e4-0",
"DistanceFromArrivalLS": 0.0,
"StarType": "AeBe",
"StellarMass": 4.300781,
"Radius": 86130944.0,
"AbsoluteMagnitude": 9.859924,
"Age_MY": 2,
"SurfaceTemperature": 5158.0,
"Luminosity": "VI",
"RotationPeriod": 3778.449463,
"AxialTilt": 0.0,
"Rings": [
{
"Name": "Aidohs WO-R e4-0 A Belt",
"RingClass": "eRingClass_Rocky",
"MassMT": 483120000000000.0,
"InnerRad": 139450000.0,
"OuterRad": 3924200000.0
}
]
}


And a screenie.....Interesting - the star scan is not registered at all [and it was a class I not a HMC ....bad memory when writing from the bus]
https://i.imgur.com/nw1zUMk.png

Ah okay, I think I know what's wrong here - you're the victim of a legacy bug from CL2 2.0.0 whereby there were duplicate entries for the star types table in the GALAXY database, for AeBe star types.

This means that when CL2 reads scan data for an AeBe star, sees that it's an AeBe star, and tries to look the type up in the startypes table in the GALAXY database, it gets about 3 results back instead of the expected one, and confusion reigns.

I did code a fix to that and advertised it a while ago, but you appear to have slipped through the net

The fix was (in CL2 2.0.0) to click the blue "Reset star/planet to default values" button in the DB Tasks panel, which itself is a legacy thing since star and planet values are now calculated via MattG's formula rather than hard-coded low and high values as per CL1.x.

This also called an added de-duplication routine which removed the extra AeBe star type entries from the GALAXY database. Unfortunately this button will not work for you right now, because a small bug was introduced between 2.0.0 and 2.1.5 when I changed the way CL2 handles database sessions, but neglected to change that one small function which gets called when you click the blue button.

However, I have fixed this for the upcoming 2.1.6 release which will be happening Soon[tm], so, once 2.1.6 is released, you should be able to click the blue button and AeBe stars should work as expected.

Regards

 

[Genar-Hofoen]

Sorry....but I also just noticed that Niobium is being coloured the same as Cadmium, but Cd is rare and Nb is standard - I noticed cos the scan I just did had more Cd than Nb so I checked

Did the rarity of some elements change at some point between now and when the Player Journal was first introduced or when Horizons first came out? When designing the element icons I made sure at the time which ones were very common, common, rare, very rare and I'm very sure that's the rarity they were at a while back.

I'm loathe to change this as it's a lot more work than one would think, and besides, everything works fine as-is and I have other, more exciting things I'd love to start working on for the CL2 2.3.x release(s)

Regards

 

[disorganise]

Did the rarity of some elements change at some point between now and when the Player Journal was first introduced or when Horizons first came out? When designing the element icons I made sure at the time which ones were very common, common, rare, very rare and I'm very sure that's the rarity they were at a while back.

I'm loathe to change this as it's a lot more work than one would think, and besides, everything works fine as-is and I have other, more exciting things I'd love to start working on for the CL2 2.3.x release(s)

Regards

Dunno.....it's a minor cosmetic that doesn't worry me.....TBH, I can't keep the colour coding in my head anyway and just look at the actual concentrations. Leave it be.....I want my stats panel

Regards the AeBe fix....no worries. I didn't know I had any issues previously so if I did see your original fix, I likely ignored it thinking it didn't apply.....plus, I went through the uninstall and reinstall for 64bit. But since I kept my DBs elsewhere......yeah...the logic is not strong in this one :/

Alternatively.....its your fault cos you moved the thread

 

[Gramps]

I been getting this the last few days when I try to download the EDSM Dump, so I re-named the file called EDSMnightlydump.json and it created a new one but that didn't fix it, any idea's.
Windows 7 by the way.

Spoiler

 

[Genar-Hofoen]

I been getting this the last few days when I try to download the EDSM Dump, so I re-named the file called EDSMnightlydump.json but that didn't fix it, any idea's.
Windows 7 by the way.

Spoiler

https://i.imgur.com/wrJH1Ek.jpg

Interesting.

My guess is it's possibly the Qt4 GUI which has crashed for reasons which escape me at this time. Possibly to do with Qt4's GUI refreshing shilst trying to update the download status.

Reason I believe it's the Qt4 GUI library crashing is because that's a Windows crash dialogue window as opposed to a Python crash dialogue window - if it was the Python program part of CL2 which was crashing there'd either be something in the Logger, or there'd be a cx_freeze window with a proper message indicating the nature of the crash.

CL2 is currently on 2.1.6 beta 3 at the moment and I'm trying to get 2.1.6 out the door so I can move on to a new feature I'm planning with a future 2.2.0 release. I'll take a gander at how the GUI is refreshed per download update - I may be able to alter it in such a way to either get rid of or at least reduce the chances of a GUI crash.

Oh and presumably, you have enough disk space to download >2GB of EDSM nightly dump and have around an additional 2GB of space to accommodate the resultant EDSM database created from that nightly dump?

Regards

 

[Gramps]

Interesting.

My guess is it's possibly the Qt4 GUI which has crashed for reasons which escape me at this time. Possibly to do with Qt4's GUI refreshing shilst trying to update the download status.

Reason I believe it's the Qt4 GUI library crashing is because that's a Windows crash dialogue window as opposed to a Python crash dialogue window - if it was the Python program part of CL2 which was crashing there'd either be something in the Logger, or there'd be a cx_freeze window with a proper message indicating the nature of the crash.

CL2 is currently on 2.1.6 beta 3 at the moment and I'm trying to get 2.1.6 out the door so I can move on to a new feature I'm planning with a future 2.2.0 release. I'll take a gander at how the GUI is refreshed per download update - I may be able to alter it in such a way to either get rid of or at least reduce the chances of a GUI crash.

Oh and presumably, you have enough disk space to download >2GB of EDSM nightly dump and have around an additional 2GB of space to accommodate the resultant EDSM database created from that nightly dump?

Regards

Plenty of empty space on that drive (376GB) thank you for looking into it Genar and for all the work that must go into creating such an excellent program.

 

[Genar-Hofoen]

Plenty of empty space on that drive (376GB) thank you for looking into it Genar and for all the work that must go into creating such an excellent program.

Cheers.

Well the good news is, I found the cause of the crash.

The Qt4 library is indeed crashing - it's because of the way I program CL2. I send the download progress as a Qt GUI Signal() - embedded within this downloadProgress signal is an integer value of the amount of bytes downloaded so far.

The trouble is, 32-bit Qt4's integers can only go so high, and the EDSM nightly dump has now exceeded that maximum value for a 32-bit integer. When the download progress bytes value has exceeded the 32-bit maximum value that Qt4 can cope with, it causes an internal Overflow Error within the Qt4 library, which promptly crashes the program.

The solution is to send the signal, and embed the download progress value as text instead of an integer.

The signal receiver function then converts that string back to an integer - because Python can handle these huge integer numbers.

This fix is in for the upcoming 2.1.6 release, which I'll try to get out some time during the 2nd November

Regards, and thanks for the bug report!

 

[Gramps]

Looking forward to the new release then, thank you again Genar.

 

[Genar-Hofoen]

Captain's Log 2.1.6 beta 4 available for testing...

As per title, I have a beta version of 2.1.6 available, which fixes a number of bugs since 2.1.5.

If you are prepared to try this beta, BACK UP YOUR Captainslog2 FOLDER in %localappdata% (and if configured in a different folder, your database files) BEFORE RUNNING THE BETA!

Please send bug reports to the Discord server, #beta_bug_reports - if you are not prepared to use Discord, do not try the beta!
Please DO NOT PM me on the forums about bugs or issues!

Since this is a beta, take a backup of your Captainslog2 folder in %localappdata% and also your database files if they are in a different location, before running the beta.

Should be safe to upgrade from CL 2.0.0. NOTE: your GALAXY.db will be upgraded and will no longer be compatible with CL 2.0.0 so back everything up.
Should be safe to upgrade from 2.1.3 - 2.1.6 beta 3.
Uninstall other versions of CL2 before installing.
Otherwise just uninstall CL2 before installing this version, if you want to err on the safe side.

If you are trying out this beta, and see Luminosity values are missing, create a new blank trip DB, highlight it and hit the Import Journals button - this will update the starsystems from the scans in the Journals with any Luminosity values in more recent Journals. Then select your current live Trip database and click the Switch To button to reload it. Luminosity values should now be visible for stars which have them.

Download link for 2.1.6 Beta 4 : https://www.dropbox.com/s/ryosatrr4bkky1s/Captain's Log 2_2.1.6 beta 4_setup.exe?dl=1

2.1.6 Beta Changelogs

- store total value of planets calculated in PlanetTableWidget

- store total value of stars calculated in StarTableWidget

- BUGFIX : don't send total trip value to the system value visibility checker function. Dolt.

- ENHANCEMENT : A lot of work done to make the Overlay WAY more responsive when scanning stars and planets, which once and for all stops the first planet data showing up in the Overlay widget before the latest-scanned planet data.

- added journalSupercruiseExit signal (& parser) to JournalParser class.

- ENHANCEMENT : When exiting supercruise near a planet, CL2 will auto-select that planet's details. (Thanks Cometborne for the idea!)

- BUGFIX : made the planet data parser more robust to prevent missing body parameters from preventing the Nav Beacon Scan data import from completing. Triton in the Sol system, I'm looking at you -.-

- also changed the Nav Beacon Scan bits of the JournalParser to be more DRY. Less code! Less bugs! Honest!

- a couple of internal variables renamed to make more sense. It helps. A lot.

- tidied up some nav beacon scan update code. Now all neat and tidy.

- BUGFIX : get the GALAXY database AeBe de-duplication function working again. This fixes a legacy bug in the GALAXY database from CL2 2.0.0 where AeBe star types were duplicated about 3 times and which confuses CL2 when looking up the AeBe type for various things like scans of that type etc. If you encounter weirdness in CL2 whereby you get no information about AeBe star types, then you need to go into the Configuration Manager and click on the blue "reset star/planet to default values" button, which will also de-duplicate the AeBe star types in the GALAXY database, and should fix the weirdness. I tried to think of some way of making this bugfix text much, much longer to read but couldn't... Oh, there ya go!

- BUGFIX : JournalParser float values are now all converted to text before being emitted as a Signal() to the relevant handlers.

- BUGFIX : v2DBInterface - signal handlers now receive floating point values as text and converts them back into floats.

- BUGFIX : removed incorrect luminosity floating point column from the database and added a starluminosity text column instead

- altered the attempt_repair_of_galaxy_database() functions to take into account further database migrations

- BUGFIX : properly use and take note of a star's Luminosity from a scan.

- added a database migration script to alter the GALAXY database with the new luminosity column.

 

[Genar-Hofoen]

Captain's Log 2.1.6 Released

As per title, Captain's Log v2.1.6 is now available, which fixes a number of bugs since 2.1.5.

Please refer to the 2.1.6 beta 4 release announcement above for full release notes.

If you see Luminosity values are missing for previously scanned stars for which the game's Player Journal provided that value, create a new blank trip DB, highlight it and hit the Import Journals button - this will update/refresh the star systems from the scans in the Journals with any Luminosity values in more recent Journals. Then select your current live Trip database and click the Switch To button to reload it. Luminosity values should now be visible for stars which have them.

If you notice any oddness with AeBe stars (i.e. they don't appear in Captain's Log after a scan), hit the "Reset star/planet to default values" button in the DB Tasks panel of the Trip Databases tab in the Configuration window, then restart CL2. This fixes a legacy problem with AeBe stars which was introduced when CL2 2.0.0 was released. This is only for those that notice they have odd beheviour as desribed with AeBe stars. If you don't have this problem, no need to worry.

Download 2.1.6 from : https://captainslog.scarygliders.net/download/captains-log-2x/

An alternate download location is available, mentioned on that page.

 

[Markzeero]

Change font or window size

Is there any way to change the font or increase the window size? This is the view I have of the application.

Cheers,
Mark

 

[Gramps]

Wrong thread

 

[Genar-Hofoen]

Is there any way to change the font or increase the window size? This is the view I have of the application.
https://imgur.com/a/m9mLM
Cheers,
Mark

I do have plans to add some kind of font customisation thingy. Might even be for the next release of CL2. But it's going to involve a bit of work to accomplish, as I'm going to have to add some means of changing font preferences to groups of GUI widgets with text in 'em.

The window resizing thing's been asked about many times, and my response is it's simply too difficult to make the CL GUI look the way it does and be able to resize it in some expected manner. I've looked into the GUI toolkit's layout facilities before, many times, and each time I've tried I just cannot get such a window to behave as one would expect - keeping the layout the same with desired GUI widgets resizing in a reasonable and predictable manner, without one or a few suddenly leaping down to some unwanted column or row.

The times I've tried making a resizable version of the static GUI before, it just turned into a horrific mess. So keeping the layout static has been to this day the best way to design the look and feel of the application

Regards

 

[Markzeero]

I do have plans to add some kind of font customisation thingy. Might even be for the next release of CL2. But it's going to involve a bit of work to accomplish, as I'm going to have to add some means of changing font preferences to groups of GUI widgets with text in 'em.

The window resizing thing's been asked about many times, and my response is it's simply too difficult to make the CL GUI look the way it does and be able to resize it in some expected manner. I've looked into the GUI toolkit's layout facilities before, many times, and each time I've tried I just cannot get such a window to behave as one would expect - keeping the layout the same with desired GUI widgets resizing in a reasonable and predictable manner, without one or a few suddenly leaping down to some unwanted column or row.

The times I've tried making a resizable version of the static GUI before, it just turned into a horrific mess. So keeping the layout static has been to this day the best way to design the look and feel of the application

Regards

Thanks, for replying and thanks for the work you're putting into this, it's a good app.

Cheers,
Mark