NCSDIS: Make --list actually be the default

[dressupgeekout]

The usage message for ncsdis notes that '--list' is the default command, but if you omit it from your command line then we continue anyway with kCommandNone.

So I think we should either do this, or actually complain early on if the user doesn't specify a command.

[dressupgeekout]

OMG I just noticed https://github.com/xoreos/xoreos-tools/pull/12 is being worked on. Closing

[DrMcCoy]

Sorry, you were a bit late on that one. :P

If you're coming from seeing #11, that one has the "first-timers-only" label attached. It's supposed to be grabbed by people who don't have many (or any) contributions to FLOSS projects, as a sort of "gateway".

Correct me if I'm wrong, but you're already not that green anymore, right? :)

If you want to work on xoreos-tools, there's a few more complicated tasks that would be great to get done. From the top of my head:

• Extend the disassembler into a decompiler. It would then create recompilable C-like NWScript bytecode
• Extend the disassembler into the other direction: first an assembler, then a compiler
• Someone on Deadly Stream (the home of most of the KotOR/KotOR2 modding community) wrote a TGA to TPC (KotOR/KotOR2 texture format) converter. xoreos(-tools) currently can only read TPC and write TGA, not the other way round. The code could be integrated into xoreos(-tools) (though I'd need to check license compatibility first)
• We could use writers for the archive formats. RIM would be easy-ish. ERF more difficult (because many versions), but xoreos itself needs that for game saving in the future. KEY/BIF kinda in the middle

Hit me up if you want to work on any of these, have your own idea on what to do with xoreos(-tools), or want more options from me. Here, on IRC, by email, anywhere.

It's of course fine if you don't want to do any of this. :)

[dressupgeekout]

Heh I didn't know that https://github.com/xoreos/xoreos-tools/issues/11 was a thing. I was just using ncsdis in my spare time and I encountered a bug, so I fixed it :}

[dressupgeekout]

... in other news, my C++ skills are, like, super rusty and pretty bad. Although a RIM writer does sound kinda fun

[DrMcCoy]

Ah, a weird coincidence then. :)

Can't really help you with the C++-rustyness, I'm afraid, apart from the usual "It gets better with practice" platitudes. If you have any specific questions, I'm here, though.

And while it's doesn't help with C++ per se, please have a look over the Developer Central page on our wiki, if you haven't already. It contains code formatting guidelines, etc. When in doubt, look at what the code that already exists does. When still in doubt, ask me.

The RIM writer should probably be its own class, RIMWriter. And a companion tool to unrim, called, I guess rim, similar to zip and unzip, rar and unrar, etc. Unless you can think of a better naming scheme; I'm not really creative enough.

I'd also like some unit tests for the RIM writer class, to make sure we're not breaking anything in the future. It should probably contain a roundway trip through our RIM reader. And if you could test the created RIM files with an original game, by repacking an existing archive and seeing that the game doesn't choke on it, that'd be great too.

As for the design of that class, that's entirely up to you. It should probably take Common::ReadStreams and write the archive into a Common::WriteStream, though.

[DrMcCoy]

Hej @dressupgeekout, are you still considering writing a RIM writer? Now that there's an ERF writer class (for version 1.0, at least), you could use that as a template of sorts to base a RIM writer off of.

If you have any questions whatsoever, feel free to ask.

(And if you don't have any time, or just plain don't want to work on xoreos, that's of course also okay. No pressure :))