Discussion Commanders log manual and data sample

As I said, I don't use those web apps, regardless of how apparently difficult that seems to be for you to believe. [blah]

I actually kind of view them as cheating and spoiling the fun of discovering things in game for yourself, but that's just me. I won't hold it against others for using them. To each their own and all that.
 
Last edited:
I actually kind of view them as cheating and spoiling the fun of discovering things in game for yourself, but that's just me. I won't hold it against others for using them. To each their own and all that.

Don't shoot a dead cow. It isn't cheating, when using 3rd party apps. They mostly replaces pen and paper, but we going off from topic!

For me, it is not required to put the journal into a JSON format, the netlog approach is enough. Don't make simple things complicated, at least for me. :)
 
However you choose to view them is irrelevant to how I choose to view them. Thanks for "shooting a dead cow" and continuing to derail the thread all the same though. :p

Point is: I personally would like to see more appropriate features in the game itself instead of FD catering to third party app makers which I won't use and that players in general shouldn't be expected to need to use.
 
Last edited:
One thing, there seems to be some weird design regarding data grouping:

Code:
{  	"event":"Died",
	"KillerNames":[  
		"Cmdr HRC1",
		"Cmdr HRC2"
	],
	"KillerShips":[  
		"type6",
		"Python"
	],
	"KillerRanks":[  
		"Harmless",
		"Master"
	]
}
Really should be:
Code:
{
    "event":"Died",
    "killers": [
        {
            "Name": "Cmdr HRC1",
            "Ship": "type6",
            "Rank": "Harmless"
        },
        {
            "Name": "Cmdr HRC2",
            "Ship": "Python",
            "Rank": "Master"
        },
    ]
}

Also someone used different quote styles in the doc, pls just auto generate that thing for the love of god :p
 
Last edited:

hchalkley

Senior Programmer
Frontier
...
Also someone used different quote styles in the doc, pls just auto generate that thing for the love of god :p

The effects of cut&paste into Word can be a bit unpredictable WRT quote styles, but if you don't mind, I'd rather spend my time on updating the code and implementing some of the suggestions rather than tinkering with the docs.
 
The effects of cut&paste into Word can be a bit unpredictable WRT quote styles, but if you don't mind, I'd rather spend my time on updating the code and implementing some of the suggestions rather than tinkering with the docs.

Yes that sounds glorious. Glory code!
 
allHighOne JSON object per-entry/line, rather than one per-file. Timestamps shouldn’t be used as keys.In the current proposal the file contents aren't well formed until the file is closed, and not even then if some timestamps are duplicates (invalid JSON).

That is a good point, as you and others have mentioned keeping a globally valid JSON object per file would be inefficient for parsing and does not account for partially complete files.

This would mean that the file itself would not be a valid object, however the following example shows that there could be very little effort into converting valid JSON by simply removing the last comma and wrapping in an array ([ ... ])

EDIT: As Shadowdancer and WizzyThing have mentioned, I agree it is better to have line delimited objects, my new example would be this

Code:
{ "timestamp": "2016-07-20T09:25:35Z", "event": "Heading", "part": 1, "gameversion": "2.2 (Trunk)", "build": "r113955 " }
{ "timestamp": "2016-07-20T09:25:35Z", "event": "LoadGame", "Commander": "HRC1", "Ship": "Asp" }
{ "timestamp": "2016-07-20T09:25:35Z", "event": "Rank", "Combat": 0, "Trade": 0, "Explore": 1, "Empire": 0, "Federation": 0, "CQC": 0 }


EDIT; OBSOLETE, please ignore, leaving for posterity :)
As written by the client
Code:
{
	"timestamp": "2016-07-20T09:25:35Z",
	"event": "Heading",
	"part": 1,
	"gameversion": "2.2 (Trunk)",
	"build": "r113955 "
},
{
	"timestamp": "2016-07-20T09:25:35Z",
	"event": "LoadGame",
	"Commander": "HRC1",
	"Ship": "Asp"
},
{
	"timestamp": "2016-07-20T09:25:35Z",
	"event": "Rank",
	"Combat": 0,
	"Trade": 0,
	"Explore": 1,
	"Empire": 0,
	"Federation": 0,
	"CQC": 0
},

Modified by parser to get valid JSON
Code:
[{
	"timestamp": "2016-07-20T09:25:35Z",
	"event": "Heading",
	"part": 1,
	"gameversion": "2.2 (Trunk)",
	"build": "r113955 "
},
{
	"timestamp": "2016-07-20T09:25:35Z",
	"event": "LoadGame",
	"Commander": "HRC1",
	"Ship": "Asp"
},
{
	"timestamp": "2016-07-20T09:25:35Z",
	"event": "Rank",
	"Combat": 0,
	"Trade": 0,
	"Explore": 1,
	"Empire": 0,
	"Federation": 0,
	"CQC": 0
}]
 
Last edited:
The effects of cut&paste into Word can be a bit unpredictable WRT quote styles, but if you don't mind, I'd rather spend my time on updating the code and implementing some of the suggestions rather than tinkering with the docs.

Amen to that!
 
Point is: I personally would like to see more appropriate features in the game itself instead of FD catering to third party app makers which I won't use and that players in general shouldn't be expected to need to use.
Point made.

I suspect the reason we're getting what has been offered, instead of something in-game, is that this costs significantly less development time. It does not require UI changes for a start so does not involve the art, web, or server "web service" coders. Instead it can be achieved by a single client side developer, likely in a few weeks or less.

Personally, I think this is better than an in-game solution for a very simple reason. Frontier has limited resources and I want them working on even cooler in-game features like ship launched fighters, passenger missions and thargoids. The sorts of things that a 3rd party app simply cannot add. By opening the door to 3rd party developers Frontier essentially gets a bunch of motivated coders for FREE who will produce a load of interesting tools and resources which will enrich the game for everyone who choses to use them (or not, for whatever reason).
 
Point made.

I suspect the reason we're getting what has been offered, instead of something in-game, is that this costs significantly less development time. It does not require UI changes for a start so does not involve the art, web, or server "web service" coders. Instead it can be achieved by a single client side developer, likely in a few weeks or less.

Personally, I think this is better than an in-game solution for a very simple reason. Frontier has limited resources and I want them working on even cooler in-game features like ship launched fighters, passenger missions and thargoids. The sorts of things that a 3rd party app simply cannot add. By opening the door to 3rd party developers Frontier essentially gets a bunch of motivated coders for FREE who will produce a load of interesting tools and resources which will enrich the game for everyone who choses to use them (or not, for whatever reason).

+Rep for having a reasonable perspective and response even if we have somewhat different outlooks on this sort of thing. [up]

I keep hearing that FD is hiring. Maybe they should hire some of you guys. :)
 
Last edited:
+Rep for having a reasonable perspective an response even if we have somewhat different outlooks on this sort of thing. [up]

I keep hearing that FD is hiring. Maybe they should hire some of you guys. :)
I haven't seen an un-reasonable response on this thread, but perhaps I'm reading the responses with a different assumed tone?

Why hire us when they can get us for FREE :p

Many developers, myself include, will code things for fun in their free time. The others may be students and having a coding project, no matter what it is, is a great way to practice/learn/develop as a software enginner/developer.

I tend to work in the back end server side of things and I'm seriously thinking of learning how to put together a front end using Angular or something.. the thing is, I don't really like javascript or java.
 
Yep, there are a lot of very experienced programmers out here in the void willing to devote their spare time to make add-on programs, web apps etc. If you totalled up our unpaid time, which we do for the love of it, it would have cost FD a fortune to hire us all. And we promote ED, make it a richer experiance, do things FD won't have the money for etc.

Its a win-win when they feed us these little titbits of functionality. Thanks FD.
 
Yep, there are a lot of very experienced programmers out here in the void willing to devote their spare time to make add-on programs, web apps etc. If you totalled up our unpaid time, which we do for the love of it, it would have cost FD a fortune to hire us all. And we promote ED, make it a richer experiance, do things FD won't have the money for etc.

Its a win-win when they feed us these little titbits of functionality. Thanks FD.

There's also the fact that what Frontier might want out of an in-house developed feature could be massively different from what the 3rd party developers want. If you're working for Frontier, you'd be doing what the management wanted implemented, rather than what you and your friends and users want.

So, it's not that a company like Frontier couldn't hire some of the 3rd party developers to make stuff for them, it's just that they'd be entirely different products as a result. Also - if eddb.io or EDSM bugs out, people aren't going to call for Frontier's head.
 

Saying something is reasonable is not explicitly saying something else is unreasonable, but maybe you're just reading my posts in a different assumed tone. ;)

I think it's great that you guys care to enhance the game and have fun doing it in your spare time as you see it. I personally don't see it as an alternative to proper in-house game development though. Optional add-ons are one thing. As mentioned by someone else though, there should be no such thing as "must have" add-ons, in my opinion.

Either way, there isn't much point in debating the pros and cons of these things. What's important is that Frontier is made aware of these issues and takes the perspective of those like me into consideration as well. I'm sure there are others who would also prefer a more complete game that can stand strong on its own merits and features.

Cheers, and happy gaming.
 
← Occasionally guilty of being a bit snarky.

I'm glad that you guys have fun messing around with this stuff, but I'd much prefer more player gaming experience solutions provided natively in the game itself.

I will more than likely never run third party executables for this game, but do make use of web apps occasionally.

Cheers.

Hmm... That's too bad. An app like ED-Discovery running in the background will take your ED log file, parse it on an update and create a splendid 3D map of your adventures. What's not to love? Moreover, this wonderful app can optionally then send this data to EDSM (Elite Dangerous Star Map) which is an online exploration aggregating service which logs all of the stars its users have visited creating at present a 3D map with 1,000,000 visited stars logged!

There is another app which actually uses character recognition to parse the market screens and send live market price data to a central server using EDMC (Market connector) for use by sites such as EDDB (Elite Dangerous DataBase) and others.

The amount of effort and support that this community generates is awesome, but it relies on people gathering data and sending it. Please support the database backend by installing the 3rd party tools and supplying the databases with up to date info... After all, at the end of the day, a database is only as good as the information it contains.

Oh, and you might even consider paypalling a few dollars their way. ;-)

G, Out.
 
Look folks - arguing about usage of 3rd-party tools or not is pretty much off topic here.

Perhaps create your own topic in some different section. Then the ones that do the 3rd party tool programming can have the signal we desire here.

Cheers.
 
Top Bottom