player.config, The problem with

I invested a bit of time researching how the quest system works but unfortunately, in order to add new quests there are some limitations. Your quest must be either added to the 'initialquests' array for each race, and then you must start a new character for the quest to even appear. This is massively limiting as you cannot give items or blueprints to existing characters. The other way would be to add a 'followUp' quest to the last quest in the list, but what if the player already completed the beacon quest? There are other with this as well which involve having multiple mods. Installing multiple mods this way is just as awkward. They really need to upgrade this quest system so that you can add new quests and it recursively adds them if they're not defined in quests.config. Updating the player.config or quests.config is pretty much the same, but player.config is way more convenient in its current state.

 

This would work. Except you'd only be able to use one mod at a time, as each mod would override each other, so the last one in the bootstrap.conf list would likely be the only one to get used.

Ideally, you'd have an application that installed .zips into a Starbound/mods/ folder, which contained a player.config file, copied from the one from the /assets folder, which the mod manager could add to given files that contain instructions on what lines to add where in the player.config file.

 

Looks like your right there, I guess at this stage in the beta custom quests aren't really supported yet, well I'll stick to the furnace method for a bit longer, it seems fairly harmless.

 

I poked about in NPC dialogue a couple days back, and they seem to have a 'default' option for races. (I don't think it was in the quest config file at least.)
I'm not sure if all races include the default values, or exclude them if they have their own values defined in the same scope. (That being said I saw a Glitch merchant speak in a very unGlitch-like manner... So maybe.)

Still, it doesn't alleviate the problem of adding it to the starting config. Need to just figure out a hack job until something better comes to light, I guess.

 

Even if this is not a completely viable option at this time, I really like the idea of going through this in order to activate recipes without altering the player.config. Not only would you minimize the setup for the client, but it opens the opportunity to provide a prompt on activation introducing the client to the mod that they are about to use. I'll be keeping my eyes on this method as we go.

 

From what I gather the devs are looking to making a more feasible modding system without having to deal with this .config modifying business. But that could be months down the road.

Getting recipes via other methods isn't very feasible at the moment, and discovering recipes after picking up a certain item isn't reliable. From what I've experienced if you've already had a certain item in your inventory on your save you won't be able to learn the schematic.

 

Exactly! You could even make a short fun chain providing a bit of story or a bit of a challenge depending on the tone of the mod, but by the way that there is currently no 'quest' subsection of the mod forum, I'm guessing thats CFs way of saying it can't really be done yet.

 

Yeah. Don't get me wrong, the modability of everything is in a really good place right now. We just need a few tweaks. I don't think changing the blueprint system of player.config would take more than an hour or two, including testing.

 

On this, I believe part of the problem is that currently we only have quests which begin through an initial quest chain, rather than having a simple

Code:

"initiatequest": {
        [ "<QuestID>" ]
  }

Hook that can be added to items (gather or usage), NPCs, or other events. Which is to say, the same problem with most everything else... The lack of hooks to link to modded content without changing many default files.

In fairness, from a game design standpoint this is also one of the hardest things to do since you pretty much need to code in something that allows something you don't know about to be able to integrate with everything else. In terms of other games, it only works in Minecraft because all the recipes available are already known by the player. With Skyrim (and others), you could define a quest which would start immediately upon the next game launch.In other modded games... It usually doesn't exist natively, requiring some number of edits to be made to base game assets.

In addition to being able to start quests from more places, the best solution I could think of for this would be to add in an additional flag to recipe structure which would allow the recipe (or just common level recipes) to be instantly known when using the related crafting group. But this is something that likely could only be added as part of the base game by the developers.

 

I agree for the most part, but claiming that it's difficult to load things in that the game doesn't know about is something it does regularly. It loads in new items and recipes using their ids, by scanning the assets folder recursively, it picks up on .item and .recipe file types and puts them into the game ready for use. Their respective hooks in player.config / quests.config is for the most part irrelevant, beyond having race specific quests.

 

But those entries within the config files is EXACTLY what allows them to be connected to the game.

Let me explain it like this... Take for example treasure pools which define what item entries appear within the game. The treasure pools is being called by either a creature or container which is spawned in the world. The container is being placed based on a dungeon schematic or biome entry. The dungeon schematic uses a color code to locate objects, and constructed based off a pre-planned table of connections. The dungeon is selected based on it being defined within a biome file. The biomes available within a given sector are defined within a further file, and that file is called directly by the game.

This means that in order to make an item appear randomly in the game, you would either need to:
Edit an existing treasure pool with a new entry.
Make a new treasure pool linked with an existing container.
Make a new treasure pool linked with a new container that is declared within an existing .dungeon file.
"" "", "" "", with a new dungeon file and link it within an existing biome entry.
"" "", "" "", with a new biome entry, and edit the file that controls what biomes can appear in what sector.

In all cases, you would have to edit an existing file to patch in your new content. There are no open links to which you can attach loose data and have it work. The only things which I have found to work in isolation (just make them part of the right group) are, as mentioned, those recipes related to the stone furnace or refinery... And only because they work in a straight input -> output basis.

 

You don't need to explain how it works, ive been developing MVC frameworks for about 5 years.

The hook is manually written down in player.config. The hook can be automatically gathered by reading files, old and new. The best implementation i can think of would be to add an optional 'tier' property to recipes, which determines the tier they unlock with and their availability. For example;

Code:

{
  "input" : [
    { "item" : "ironbar", "count" : 5 }
  ],
  "output" : { "item" : "tier1bed", "count" : 1 },
  "groups" : [ "craftingtable", "furniture", "objects", "all" ],
  "tier" : "default"
}

It could even be an array, to allow it to be unlocked at various tiers or using custom tiers/ids.

Code:

{
  "input" : [
    { "item" : "ironbar", "count" : 5 }
  ],
  "output" : { "item" : "tier1bed", "count" : 1 },
  "groups" : [ "craftingtable", "furniture", "objects", "all" ],
  "tier" : [ "default", "tier4" ]
}

 

I wasn't saying hard from a programming standpoint, so much as it is hard from the actual planning and justification standpoint given that:

1). Developers typically don't have to even consider mod compatibility when developing their games. Meaning that any consideration usually occurs long after the fact, as something haphazardly patched in. Or it only exists because the developer was being lazy and didn't care about performance.

2). Openings like you describe are easy to implement, sure, but also mean reading more data every single time that action is called. In the case of an opening when the game first loads, this can lead to long initial load times within a heavily modded game. In the case of something which is occasionally called, as you describe, the extra loading is divided between multiple entry points, but can result in a cluttered interface. In the case of something which is frequently called, even if it only cares about new information, you have a continuous drain on available resources.

3). Even if there is no new data to load, open ended queries still mean additional reading of data and re-examining or existing data resulting in extra drain on available resources every time it happens, however minute. In terms of loaded data, this can lead to other issues down the road depending on how well the engine can manipulate and utilize RAM.

4). Meaning that you have to design those systems in a way so that the related performance hits are not particularly noticeable, but common enough that you don't have to funnel everything through a single method of entry that may become congested in a moderately or heavily modified case.

All of that aside, the bottom line is that currently, there is no such opening (reliable or otherwise) within the game for modders to add in new data without altering any existing files other than the mentioned furnace recipe method.

 

I've noted that this is what the game is currently doing, loading every asset file on startup. He may even throw an error on a malformed json present, but referenced nowhere. As such, between loading a list of recipe from a file, and building it dynamically from *.recipe, the performance hit should be pretty low.

 

I agree. In fact id argue that the performance would be equal. Im only suggesting it to be added to recipes and the large array found in player.config would be removed as a result. As for quests, they can work the same way, new quests are added when a new quest file is found. You wouldn't want to put them in 'initialquests' because then they'd all pop up when you start a new character.

 

Bear in mind that as it stands, there's no (revealed) way for THEM to add in new quests here, which is something I've believed they plan to do, I mean, why bother if you only wanted one long, linear quest chain from character creation? Especially if you had to restart your character to see latter versions.
That's just a to-do list. A long one you've to do over and over in the same order with every character in the same order.

It's likely just that they cobbled that together to give players some direction at the start of this, and what it is is likely not representative of the final system.
As for them not caring about modability, I think that's a bit of bullwhack. It's helped push similar games' lives way past what vanilla alone would hold people for. Imagine MC without mods, it wouldn't be flourishing right now.
In either case, they didn't necessarily have to make it so that files that alter functionality can be easily edited with a bare text editor, which most every computer has. They might've been making it convenient for themselves to muck about with things.

It just happens that it helps make it easy for external modders to alter it, as well as internal ones.

Call me crazy, but that point, the only real difference between a developer and a modder hanging about on these forums, is that they can easier alter the program for new functionality. (And they get paid for their work, I hope.)
They still will technically 'mod' the game in ways similar to how we would work. New items, armour, biomes, what have you. All by altering non-compiled text files.

Far easier for them, since they can get faster feedback, without having to compile anew. While keeping the community happy, and technically giving then a portion of an API to work with? It's a win-win.

As for performance hits, bear in mind that there's a lot still imperfect about this game. Now's a great time to throw out something new to give folks something to work on, and progressively make it more efficient. Not every system has to be utterly sleek to work, but it just needs to work to be shown to folks. Even if it limped along at a crawl, it works.

I'd be fine if it scanned the entire recipe directory every time I opened a crafting table; it'd be preferable to having to alter existing vanilla files. Proof it can work is most valuable, in my opinion. It can then be tweaked, altered, to make it work better in later versions. Even if they have to have a hackish way of doing it. Hey, it works. And how is it different than us using a furnace and getting 'special coal', to unlock a new subset of recipes? It works, it's shoddy, but it works. We're just waiting for a better way to do it.

tl;dr : Devs are basically modders too, when it comes down to bare brass tacks. The way this is done, is also convenient for them.
Also I'm bad at keeping to the point.

 

The best solution would be a way to define logical scripts for mods that run on startup and have exposed functions in lua to register recipes and items that are simply then added onto the player.config entries in the engine itself. Having this functionality would eliminate a host of problems with how modding is setup currently, and allow for mods that are purely script / logic based to exist.

 

Yes, and no. What you noticed is in relation to what the game kinda needs to do due to how all the game information is connected through various links. That initial loading is just following all the links and storing it within memory. As the game gets larger, this will continue to take longer just because that is how the game has to handle data. Unless I'm missing something however, it does not seem to be loading every asset file, but instead just those which are connected to something, like a recipe.

 

I noticed this

As we know, stonefurnace recipe are always available , it's currently the most well known workaround, so the game must be loading and linking these recipes without caring for player.config or <species>.config.

Before finding this post I've done a suggestion on reddit a bit similar to Xuhybrid one's :

http://www.reddit.com/r/starbound/comments/1sq090/suggestion_modding_recipe_integration_improvement/

 

Should be simple enough to implement your second suggestion doing something like this;

Code:

{
  "tiers" : [
    "tier1"
  ],
  "races" : [
    "default",
    "apex"
  ]
}