Cmdr's Log Continued

Do you prefer light or dark applications/websites?

  • Total voters
    61
  • Poll closed .

Forecaster

Forecaster
Introduction

Cmdr's Log is an application by ArchV1 here on the Frontier forums.
It's a trading assistant used to generate trade routes by inputting commodity prices from a number of stations as well as some other features.
It's a good program, however ArchV1 has disappeared. Last login date as I'm writing this was 01-03-2015, which is quite a while (I believe he had a child).

I stopped playing Elite for a while, due to lack of time, but a month ago or so I got back into it! Just before I'd stopped playing I had bought a Type-7 and I knew that I'd eventually want to do some commodity trading again. I of course remembered Cmdr's Log and how useful it was, but I had a few problems with it.
One of the issues with it in my opinion was the lack of themes. I prefer my applications and websites dark whenever possible, and there was a couple of other things I wanted as well.
So, I set out to write a replacement for it, called Cmdr's Log Continued (Hereby referred to as CLC), which is really a lie because I'm re-writing everything from scratch in a completely different framework, but I wanted to keep the name and ties to the old program, because it is going to carry on it's spirit. And thus I'm going to list the features it's going to have.


The Features

First up are the ones inherited from the original Cmdr's Log:
  • Completely Offline Trading Data
  • Store station details such as economy and services
  • Enter commodity data into station such as demand/production, stock and buy/sell price/ton
  • Find trades based on commodity data and filter by things like data age and profit
  • Keep a journal over your travels

Now, here are the things that are going to be new/different in CLC:
  • Fancier journal: Instead of basically a text file edited within the application this will deal with distinct "posts" similar to a twitter feed for example
  • Trade journal: Name not final. Keep track of your purchases and sales in a separate log and keep track of your current balance
  • Themes: Thanks to the interface being HTML based themes can be customized with CSS (Will include a light and dark theme by default)
  • More OS support: CLC will most likely support Windows and Linux, and possibly also OSX
  • Standard Data Store: Instead of the proprietary save format the original uses, CLC uses JSON, for which interpreters exist for almost any language.
  • Configurable Shortcuts CLC will have shortcuts for quickly setting commodity data similar to the original app. These will be configurable!

There are a few more additions I'll probably make, such as the ability to display images in journal entries, but this is the gist and will do for now! May post more details about new features in additional posts later.


Development

Development is already underway, but it's not super fast, I have other things that require attention as well, such as my YouTube channel, and I have limited free time.
But it's progressing! Here is an example of what the main window looks like with the add system/station window on top (using the dark theme):

8y7fbW5.png
(Don't mind the window title. It's wrong.)

I'll create new posts in this topic with development updates, questions for feedback, and occasional screenshots as coding continues. The plan is to get the basic GUI and back-end in place to allow adding systems/stations, some station data, commodity data and to generate trade routes. At this point an beta will be released (we are currently in alpha).


Status: BETA

Current Version: 0.4

Development stages:
  • ALPHA Core features incomplete, app in an unusable state (Core features are station commodity data entry and trade route generation
  • BETA Core features complete, app usable. Work on additional features (test version avaliable)
  • RELEASE App fully functional, potential for bug fix releases
Additional features would be collected, then added in the next major version (eg 2.0) which would go through the same process as above.

Releases / Downloads

https://github.com/Forecaster/cmdrs-log-continued/releases/


Feedback

Please post any and all feedback in this topic! Feedback can be anything from "This wasn't in the original application! Add it!" to "The original application did this thing I didn't like! Don't do it!".
You may also (perhaps preferably) submit feature requests and bug reports to the projects issue tracker here: https://github.com/Forecaster/cmdrs-log-continued/issues
I appreciate any suggestions or critiques along with any words of encouragement!

I hope you'll stick around until the beta stage!
 
Last edited:

Howe

Howe
I'll be interested in this. I'm still using the latest release of the original and have been coping by adding new commodities myself. I only really use the trading aspect as I use Inara for everything else.
 

Forecaster

Forecaster
Howe said:
I'll be interested in this. I'm still using the latest release of the original and have been coping by adding new commodities myself. I only really use the trading aspect as I use Inara for everything else.
Click to expand...

That's fine :)

I'm personally mostly interested in the trading features as well, and the trade log, which Inara has something similar, but I'll prefer the one built into the trading app, rather than one relying, and storing all data on some remote server :p
 

Forecaster

Forecaster
So how will data be split up? I can easily divide data between multiple files however I choose or just have everything in a single file. I want to people to know how I want the file structure to look.

Currently the separate files I'd have would be
  • Application Settings: Things like chosen theme and keybindings, things changeable from the apps settings menu (Which hasn't been designed yet)
  • Commodities: A list of all the commodities basically
  • Station data: All of your stations and systems, and their individual settings and values
  • Journal: All journal entries
  • Transaction log: All transaction data you've entered

I believe in keeping the number of individual files as low as possible, but if anyone has input on this I'd like to hear it!
 

mmm

mmm
Right on CMDR! Have some rep for your efforts :)

I didn't play around with this kind of tools yet, hence a stupid question: Is there any way to gather information like economy type, market data, outfitting options etc automatically when you're docked at a station? Anything other than OCR that is.
 

Forecaster

Forecaster
mmm said:
Right on CMDR! Have some rep for your efforts :)

I didn't play around with this kind of tools yet, hence a stupid question: Is there any way to gather information like economy type, market data, outfitting options etc automatically when you're docked at a station? Anything other than OCR that is.
Click to expand...

There is not to my knowledge. Elite doesn't expose this information anywhere other then inside the game.
 

Forecaster

Forecaster
To clarify, unless I get a reason to split into more files then I'll most likely go with the above list. :)

Also, I'm considering enabling the application to fetch a commodity list from a server, I'd also set up a service to provide said list.

Essentially on application start it would send a request to my server (or another configurable url, in case I disappear) where it would get a unix date back, for when the list was last changed, it'd compare this to the local list, if the server list has changed after the local list it would request the list to be sent and overwrite the local list with it.

This would mean you wouldn't have to re-download the entire application to update your commodity list, nor would you have to do so manually unless you want to, where you can disable this check.

To increase user-friendliness I'd have a window pop up the first time this happens with the options "download the updated file", "stop asking and always download", "disable the check" and "ignore this update".

This is only to update the list of commodities when Elite adds more, not any trade data.

Oh. And default values like station types and economies and such too I suppose?
 
Last edited:

Forecaster

Forecaster
Here's another update!

I've been working on the commodity window!

Like in the original it will be an independent window, it will have a "keep on top" option in the future.

It and the main window look like this currently:

eSPB55h.png

As you can see it's incomplete, it's only writing the names into the list, nothing else yet.

I now stand before another choice:

1. Do I do what the original did and have another window where you enter the data for a commodity, with the option to manipulate the entries somewhat using your keyboard
2. Integrate all data entry into the list, having inputs appear dynamically, to avoid having additional windows, still allowing use of the keyboard

#2 seems the better choice to me and is most likely what I will work towards. But I wanted to post an update anyway to communicate the progress.




Here's a separate issue, a little more complicated, but I'll explain if you bear with me.

Because of the way the original was designed with the ability to both input free-text and choose from a drop-down of preset values for station data, and me wanting to stay as close to the original as possible, I didn't want to drop this feature, but I am handling it a bit differently.

When you select a station and click inside an input a drop-down menu will appear and display a list of presets for that input, for example the four allegiance types, Alliance, Federation, Empire and Independent. When you choose one of these what you see is the value being filled into the input you know it's stored because if you pick another station and then pick the first one again it'll remember what value you picked. Here's where it gets complicated though, because what really happens when you choose a preset is that it sends the key back, and that is what is stored. The same thing will happen if you type a key in manually into the input. For reference, a key is generally the same as the actual value, but all lower-case and all spaces replaced with underscores, so the key for "Alliance" would just be "alliance", and the key for "Scientific Outpost" would be "scientific_outpost".

The reason I'm doing this business with keys is to allow mass-editing values. This is useful if say a station type is changed, and storing keys means that you can just edit the preset, say from "Scientific Outpost" to "Magic Outpost", and all stations that refer to that key will display the new value, without having to find and edit every single station. You can't change the key of course. It would still have to be "scientific_outpost" in this case.

If you enter a value that doesn't correspond to a key among the presets for that input it will simply store the custom value and just display it for that station. Unlike the original application it will not be automatically added to the global presets. To do this currently you would have to add it to the file. Unfortunately at the moment it only checks for keys, it doesn't check if you enter a value, such as "Scientific Outpost" if it already exists as a value in the presets and store it's key, it will just store it as a unique value, which means if the preset is updated it wont change. I could fix this, by having it generate a key from entered values, and if the key doesn't exist add it to the presets automatically. But it'd take more time, and I'm not sure I should, as being able to enter existing values knowing they wont change could be useful perhaps?

I worry that it might not be user-friendly enough, but at the same time, with the automatic update system I plan to add for the presets most users shouldn't be required to edit the files anyway unless they want to.
 

foxpur

foxpur
Forecaster said:
2. Integrate all data entry into the list, having inputs appear dynamically, to avoid having additional windows, still allowing use of the keyboard

#2 seems the better choice to me and is most likely what I will work towards. But I wanted to post an update anyway to communicate the progress.
Click to expand...

The number 2 is my choice...
Anything the limits entry ares on the keyboard is good, even a onscreen keyboard is good. In my case whatever you create I have to integrate into a sub-window panel to use it in OpenVRDesktopDisplayPortal so I can use it in my Oculus. Keyboard entry is....complicated
 

Forecaster

Forecaster
foxpur said:
The number 2 is my choice...
Anything the limits entry ares on the keyboard is good, even a onscreen keyboard is good. In my case whatever you create I have to integrate into a sub-window panel to use it in OpenVRDesktopDisplayPortal so I can use it in my Oculus. Keyboard entry is....complicated
Click to expand...

How do you interact with the application while doing that? Directional keys and a select key? It'd be great if you explained how it works so I can perhaps find a way to allow it to work natively
 

foxpur

foxpur
Forecaster said:
How do you interact with the application while doing that? Directional keys and a select key? It'd be great if you explained how it works so I can perhaps find a way to allow it to work natively
Click to expand...

Well I assign VA commands to the movement for the app... But direct clickable thru-put doesn't work yet :(
I got the idea from the G19s Companion app, that can use VA and standalone
https://forums.frontier.co.uk/showt...on-app-(with-simulated-space-traffic-control)

HotKeys are VERY useful for this if you use VA, Astra (and Jazz and Verity), EDDI, G19s, Marvin from ToolBox, anf a few custom commands :)
 
Last edited:

gazzareth

G
Glad to see that you're working on this, still using v2.1 with EDMC for the import.

Find it works really well, although the main feature it lacks vs the likes of EDDB is any form of distance details between systems....

G
 

Forecaster

Forecaster
foxpur said:
Well I assign VA commands to the movement for the app... But direct clickable thru-put doesn't work yet :(
I got the idea from the G19s Companion app, that can use VA and standalone
https://forums.frontier.co.uk/showt...on-app-(with-simulated-space-traffic-control)

HotKeys are VERY useful for this if you use VA, Astra (and Jazz and Verity), EDDI, G19s, Marvin from ToolBox, anf a few custom commands :)
Click to expand...

If all you need is hotkeys you'll be fine with the current plan I believe

- - - Updated - - -

gazzareth said:
Glad to see that you're working on this, still using v2.1 with EDMC for the import.

Find it works really well, although the main feature it lacks vs the likes of EDDB is any form of distance details between systems....

G
Click to expand...

I was going to allow you to group systems with regions, and perhaps use that when finding trade routs to limit searches. Other than that I'm not sure.

I could also allow entering distances between systems, but that is a lot of data to enter and would be complicated to use. I'm not sure that's the best option.
 

Forecaster

Forecaster
So I just learned about the Journal feature introduced in 2.2.

It's apparently a file where information about certain game events are output as a kind of log, such as docking, undocking, going into supercruise, exiting supercruse, FSD jumps and even buying and selling goods. I found out about this thanks to foxpur mentioning the G19s Companion app which uses it.

I'm going to implement support for this into CLC to allow it to keep track of your position and probably even automatically input events into the trade log along with manual entry!

I might require manually pointing to the directory where the files are kept. I know where it is on windows, but not on linux/OSX.

(I'm not working on this yet. It'll be for later once basic functionality has been established of course)
 
Last edited:

gazzareth

G
Forecaster said:
If all you need is hotkeys you'll be fine with the current plan I believe

- - - Updated - - -



I was going to allow you to group systems with regions, and perhaps use that when finding trade routs to limit searches. Other than that I'm not sure.

I could also allow entering distances between systems, but that is a lot of data to enter and would be complicated to use. I'm not sure that's the best option.
Click to expand...

The first idea seems the better of the two - like you say that's a lot of data to enter otherwise.

Wasn't sure if the journal held coordinates of the systems that you had visited though, in which case it could be calculated on the fly.

G
 
You must log in or register to reply here.
Top Bottom