Feedback Please, make it easier to troubleshoot & update mods!

There are certain things about Starbound which makes developing a mod - or even using a mod - much more difficult than it needs to be.

Starbound is a complex game. There are literally thousands of files and a frightening number of lines of code, all working together to create a unique interactive experience. Even without mods, bugs and unintended behavior will occur occationally, especially since 1.0 hasn't been out that long yet.

When one adds mods to the equation, things get even more complicated. Files and lines of code are added, replaced, and/or changed. Some mods are, themselves, very complex, consisting of many lines of code and/or files. And some mods simply do not play nice with certain other mods - especially when they attempt to change the same files or do similar things. Sometimes a mod author releases a WIP mod or does a rewrite of the entire thing, without fully testing everything.

Whenever Starbound crashes or behaves in a way that is clearly unintended (i.e., "bugs"), the only recourse players have (as far as I'm aware) is starbound.log.

Unfortunately - sadly - this log is not nearly as verbose or informative as it needs to be. Consider these actual errors I found in my starbound.log:

Code:

[08:09:13.495] [Error] Exception caught loading asset: /objects/crafting/upgradeablecraftingobjects/craftingwheel3/craftingwheel3.object, (AssetException) Could not read JSON asset /objects/crafting/upgradeablecraftingobjects/craftingwheel3/craftingwheel3.object

Code:

[10:01:15.186] [Error] Could not load image asset '/objects/protectorate/objects/protectoratebooks2/protectoratebooks2icon.png', using placeholder default. (AssetException) No such asset '/objects/protectorate/objects/protectoratebooks2/protectoratebooks2icon.png'

Code:

[10:01:15.055] [Error] Could not instantiate item '[drillstop, 10, {}]'. (MaterialException) No such material id: 49800

Code:

[10:01:11.837] [Error] Object nand defined twice, second time from /objects/wired/ExtendedLogic/ExtDftGates/nand.object

Not one of these errors indicate or even hint at the cause. The only one of these that was obvious to me was the last. And that was only because I recognized the "ExtendedLogic" part of the path. The rest were a mystery to me. (Though, I figured out craftingwheel3.object after searching for "craftingwheel" in the vanilla assets revealed that it was the Spinning Wheel.)

The least this log to do is inform whether Starbound's own assets and code is to blame or whether it can be traced to a mod! With proper error trapping, such a 1/0 state (True or False distinction) should not be difficult to make.

More importantly, if the log can indicate which file is causing the problem, then it should be able to indicate where that file is located (or should be located). It does give a path, such as '/objects/protectorate/objects/protectoratebooks2/'. But it leaves out the important part, which is name of the source. That would be either (a) /assets/packed.pak, (b) the name of a /mods/ folder, (c) the name of a .pak in /mods/ or, (d) the name of the Steam Workshop folder (a 9-digit number, beginning with "7").

Granted, many players do not use any mods. However, with more and more mods on Workshop, more and more players are willing to try mods. And it looks like more multiplayer servers are using mods now.

If a player only has a few mods installed, that's one thing. Having only a few makes narrowing it down a lot easier. Also, if only one mod was added recently, then that is the likely culprit.

But do consider that some players play with a lot of mods. This is especially problematic with Workshop mods, because these are all packed into .pak files. Also, because all these .pak files are given the same name: contents.pak.

Back in early 2014, before all this .pak/.modpak stuff, it was painless. All I had to do was perform a file search in my /mods/ folder for the offending file. Easy. But that is no longer true!

In my case, since I had so many Workshop mods, I had to find a way to unpack -all- of these mods before I could perform said file search. With several dozen (over a hundred), that is a huge chore!

To begin with, I had to rename all those contents.pak to reflect the 9-digit number of their Steam Workshop id (so I could put all of them into the same folder and perform a batch command to unpack them all at once). To do this, I used the Bulk Rename Utility and this method. Then I manually moved each file into the same temp folder.

By far, the worst part was how asset_unpacker.exe is too simplistic to even allow wildcards. I mean, seriously? I can't just use a command like this?:

asset_unpacker *.pak

Instead, I had to use "DIR /B > unpak.bat" and edit the file so each line looked similar to this:

asset_unpacker 729426797.pak 729426797

Finally, after they were all unpacked, I could search them for the offending files in my Starbound.log. It would have saved me a few hours if only the log was more informative. Also, please add wildcard support to the asset_unpacker!

 

Game just crashed with this cryptic error:

Code:

[17:01:41.718] [Error] Application: exception thrown, shutting down: (AssetException) Path '' must be absolute

That's not very helpful, is it? With more than a few mods, how can anyone hope to narrow down which one of them did not use Path properly, let alone find the file responsible?

Please, make the Starbound log more verbose when an error is thrown, or at least give us the option to see more details!

 

Recently, for no obvious reason, my Starbound now does a CTD (Crash To Desktop) when trying to start. I uninstalled all my most recently installed mods and it still does it. I've also check my subscribed Chucklefish mods and threads and my comment notifications for Steam Workshop mods. But, I find nothing about a new CTD bug.

Here's the relevant error:

Code:

[Error] Application: exception thrown, shutting down: (JsonException) Cannot convert from array to string

The rest looks like complete gobbledygook:

Code:

[0] 7ff618561ee3 Star::captureStack
[1] 7ff618560c6e Star::StarException::StarException
[2] 7ff61850b046 Star::Json::toString
[3] 7ff6185056c7 Star::Json::getString
[4] 7ff6186c4ad5 Star::ItemDescriptor::ItemDescriptor
[5] 7ff6188aacef Star::QuestTemplate::QuestTemplate
[6] 7ff6188a9f70 std::make_shared<Star::QuestTemplate,Star::Json>
[7] 7ff6188ab63e Star::QuestTemplateDatabase::QuestTemplateDatabase
[8] 7ff6188ba3b5 std::make_shared<Star::QuestTemplateDatabase>
[9] 7ff6188be8d9 <lambda_6a21814ff59db299d6420af313620a10>: operator()
[10] 7ff6188b078f std::_Invoker_functor::_Call<<lambda_6a21814ff59db299d6420af313620a10> & __ptr64>
[11] 7ff6188b47f6 std::invoke<<lambda_6a21814ff59db299d6420af313620a10> & __ptr64>
[12] 7ff6188b24e9 std::_Invoke_ret<std::shared_ptr<Star::QuestTemplateDatabase>,<lambda_6a21814ff59db299d6420af313620a10> & __ptr64>
[13] 7ff6188c0fd6 std::_Func_impl<<lambda_6a21814ff59db299d6420af313620a10>,std::allocator<int>,std::shared_ptr<Star::QuestTemplateDatabase> >::_Do_call
[14] 7ff6188bf6f7 std::_Func_class<std::shared_ptr<Star: DanceDatabase> >: operator()
[15] 7ff6188b7893 Star::Root::loadMemberFunction<Star::QuestTemplateDatabase>
[16] 7ff6188b5329 Star::Root::loadMember<Star::QuestTemplateDatabase>
[17] 7ff6188c6c12 Star::Root::questTemplateDatabase
[18] 7ff6188b0c40 std::_Invoker_pmf_pointer::_Call<std::shared_ptr<Star: DungeonDefinitions const > (__cdecl Star::Root::*)(void) __ptr64,Star::Root * __ptr64 & __ptr64>
[19] 7ff6188b4609 std::invoke<std::shared_ptr<Star::ItemDatabase const > (__cdecl Star::Root::*& __ptr64)(void) __ptr64,Star::Root * __ptr64 & __ptr64>
[20] 7ff6188b200c std::_Invoke_ret<std::shared_ptr<Star::TerrainDatabase const > (__cdecl Star::Root::*& __ptr64)(void) __ptr64,Star::Root * __ptr64 & __ptr64>
[21] 7ff6188b0cce std::_Call_binder<std::_Unforced,0,std::shared_ptr<Star::Configuration> (__cdecl Star::Root::*)(void) __ptr64,std::tuple<Star::Root * __ptr64>,std::tuple<> >
[22] 7ff6188b03be std::_Binder<std::_Unforced,std::shared_ptr<Star::SpawnTypeDatabase const > (__cdecl Star::Root::*)(void) __ptr64,Star::Root * __ptr64 const>: operator()<>
[23] 7ff6188c0cb2 std::_Func_impl<Star::SwallowReturn<std::_Binder<std::_Unforced,std::shared_ptr<Star::ImageMetadataDatabase const > (__cdecl Star::Root::*)(void) __ptr64,Star::Root * __ptr64 const> >,std::allocator<int>,void>::_Do_call
[24] 7ff618558d3b <lambda_7b083dc4bdd496712d99e51bb49515b5>: operator()
[25] 7ff618559ae2 Star::WorkerPool::WorkerThread::run
[26] 7ff61855ea0e Star::ThreadImpl::runThread
[27] 7fff1b8713d2 BaseThreadInitThunk
[28] 7fff1d4254e4 RtlUserThreadStart

Not even a FILE NAME is mentioned to give us some clue as to which file or which mod is the source of the issue.
If there exists a detailed error report - for any other game or piece of software - that is less helpful, I'd be very surprised. Because, I can't fathom how.

The only thing I can imagine is that one of my many mods changed their code in a way which suddenly conflicts with one of my -other- mods. And nobody has reported it, yet, because it's probably due to an usual combination of seldom-used mods.