ckan scan without args => unhandlded NRE

[JustinKerbice]

At least on win (7):

ckan.exe scan =>

NRE in CKAN.MainClass.Main(String[] args)

(no more info)

EDIT: in fact using any command lead to this issue too:
ckan.exe list
ckan.exe version
...

[pjf]

Oh my! I don't suppose you can paste in everything you get by running ckan version --debug, can you?

[JustinKerbice]

Here it is:

ckan.exe version --debug
209 [1] DEBUG CKAN.KSP (null) - Checking if KSP is in my exe dir: Z:\games\KSP\t
ools
228 [1] DEBUG CKAN.KSP (null) - Cannot find GameData in Z:\games\KSP\tools
229 [1] DEBUG CKAN.KSPManager (null) - Loading KSP instances from registry

Exception non gérée : System.NullReferenceException: La référence d'objet n'est
pas définie à une instance d'un objet.
   à CKAN.MainClass.Main(String[] args)

looks like it's confused because it expects to be run INSIDE ONE KSP main dir :/.
For now, I put it with other KSP related stuff in Z:\games\KSP\tools .

[pjf]

Oh my! Yes, we should definitely fix that. It's supposed to look in all sorts of places for a KSP install, but it's not supposed to throw an NRE if there's nothing in the registry.

In fact, I suspect if you try ckan.exe list-installs it will break in exactly the same way, because it's trying to find an install before you can tell it where your install is.

Thank you for spotting this! I'm about to crash into bed (3:30am Australian time), but I'll start working on this if nobody else has caught it by the time I'm awake.

Many thanks again!

~ Paul

[JustinKerbice]

As I report before, it behave the same way for (not tested all) commands given to it.

May I suggest you to write more solid code, at least if you wish to release something to the crazy public, because nothing is worth than human "chaotic fuzzyness" (to stay polite :P), it's annoying and sometime boring, but EVERYTHING needs to be checked in every possible cases allowed by the code.
Never forget we're all use the exact same code in too much various situation you can't even imagine, proof here, I don't use it the way you do, and it doesn't work already for quite "trivial" cases.

[pjf]

Just a quick note to say that this is fixed in PR #198, and so the next release (which I hope to make tonight) will let you set your KSP dir if the client can't find it automatically:

ckan ksp add myksp /path/to/your/KSP/dir

If you have multiple installs, you can use this to add each one. I tend to have a bunch of installs under my ~/KSP directory, so I can test things against multiple versions, so I do something like this:

ckan ksp add 0.23.5 ~/KSP/0.23.5
ckan ksp add 0.25 ~/KSP/0.25
ckan ksp default 0.25

All the best,

~ Paul

[JustinKerbice]

Not agree with the closing of this issue as:

ckan.exe => window opened => add new => ... lost ! ckan is flying to an unknow and far body.
and --debug option doesn't exists in the last release :/.

[pjf]

Sorry, can you clarify your last report a little? What's the problem you're seeing, and what steps can be taken to reproduce it? Are you using the v0.18.1 release, or something older?

As far as I know, the --debug option still exists. ckan gui --debug will run the gui in debug mode.

[JustinKerbice]

To be specific, I use the v0.18.1-0-gb9249ff version

I see, the debug option only do something AFTER entering the core of the tool, as put it alone, in the previous version, still display some info.

The steps was what was wrote before except a critical info: no previous KSP install set BEFORE.
run ckan alone, gui open, click on 'add new' => ckan does something (maybe) forever but never get back (waiting mouse pointer).

[pjf]

Ah, that sounds like a completely different bug. I've opened #241 to track it.