Announcement Making mod installation easier

Hmm... when we modded the bootstrap. config, we had to put in periods, does "../mod_thing/thingspawner_logic.lua" work?

 

I was getting a 502 error or I would have responded sooner:

"/thingspawner_logic.lua" works.

 

iis there more to bartwes explanation because i try to follow his instructions exactly and my mod wont work and it use to work on the old

so what your saying is dependencies are our moded objects for example i have a mod thats a vendor ad the other item is spawner to get the vendor so for deps i should have
the vendor name and the spawner name correct

 

As your post confuses me, allow me to try and make my own more clearer... Say I have a mod with the following .modinfo file:

\mods\colony\colony.modinfo

Code:

{
  "name" : "Starbound Colonization",
  "version" : "Beta v. Offended Koala",
  "path" : ".",
  "dependencies" : [],
  "modauthor" : "SeveredSkullz",
  "modversion" : "0.3",
  "moddescription" : "Adds Colonies to Starbound.",
  "modsupporturl" : "http://community.playstarbound.com/index.php?threads/making-mod-installation-easier.52349/"
}

In my dependancies for the OTHER mod, I would need to have

Code:

  "dependencies" : ["Starbound Colonization"],

even though my folder and modinfo file are simply named "colony".

 

Yes, having a way to version dependencies would be VERY useful, particularly with minimum versioning on top of explicit versioning. For the v1.1 release of tabularasa we're embedding this information in the "name" field (i.e, "tabularasa1.1") to avoid namespace collisions with "tabularasa" in future versions.

 

What I would really like, is the ability to auto-patch mods that are conflicting. For example, every species mod ever.
Can't have more than one unless you hand-edit the mods in question to remove every little file conflict.

So, I suggest, instead of having files that override the game's typical assets, mods instead use patch files that detail what is added. The game then generates a merged asset file to be loaded as opposed to the vanilla asset file.

I'm not sure how feasible this would be, but as it stands, having more than one added race is a real pain.

 

That's what I'm trying to figure out. The .frames files, .species files and player.config files have lead nowhere. It seems to be with the way eyes are added specifically to this race. I would love if someone could take a look at it and see if they can fix it.

 

This is entirely feasible. And what would be another good addon is, instead of editing player.config and replacing it with new ones, we leave player.config alone and the game simply loads a new filetype called "recipelist", to determine its player recipes. It loads every recipelist filetype it finds and generates the recipe list using those.

 

What the game could do is, add the info it needs on the item.recipe itself, rather then having a list of everything on the player.config?

 

A JSON merging system is something the devs have talked about on IRC. It sounds like we'll get one eventually.

 

I think there are better solutions than merging files to be honest. A lot of their system works without having to list things specifically. Id hoped that these other things were just work in progress so i hope they don't get lazy when it's definitely possible to do it properly.

 

You do know that you can utilize a template with XML formats to create a tool that lets you fill in text boxes, which acts as a form right?
Doing so would make item generation and such much easier and less likely to get the freaking 'helmet' and chestplate' of a set mixed up on the items.

I've notice a lot of 'mixups' on the scripting parts of item integration by the devs, and I'm still wondering why they aren't integrating a tool to make templates for said items in a 'fill in the box' program.

Code:

{
  "name" : "sparkz",
  "version" : "Beta v. Indignant Koala",
  "path" : ".",
  "dependencies" : [ "tabularasa" ]
}

You can have a simple program which takes user input on the interface controls, to 'create' a template with values set by the users. This makes the user avoid modifying the actual file in a word processing editor and reduces the odd of making mistakes in their typing.

[Insert-function]>[name]
The user clicks on the 'insert' button, which shows a drop down list of function names.
User selects "name".
Label "name" shows up in the 'view panel'.
Label "name" would have a 'text box' next to it, and a button called [accept].

Get the picture?

I've been out of programming for a long time now and it sorta depresses me when I attempt to do so (due to past traumas in college), but that doesn't stop me from writing up concepts to a program.

 

can someone make a tutorial for how this new setup works "In layman's terms" please... now none of my mods are working ~_~

 

./mods/<modnamehere>/<modnamehere>.modinfo

He said everything you need to know here.

All your files go in that folder with the .modinfo file.

 

not as easy as it sounds ive been tryng to get my mod to work all day under the new system it worked great under the old one

 

When talking about paths, include /Starbound/ or /assets/ or it's ambiguous.

 

It is worth noting that the way files are loaded seems to have changed. Several members of the modding IRC channel and I cannot get tech to work unless the relative path to the mod root (that .modinfo points at) is /tech. We haven't really sniffed out exactly what is going on, but it appears that a completely generalized asset structure may no longer be viable.

 

Does the old version of editing the bootstrap still work or do I have to convert all my mods to the new method?

 

think you have to convert them as my mod that used the old system no longer works and im to dumb to get this new system working

 

Actually I think the old way would still work, its just messier. Also when the game updated it would have replaced the player.config so anything you had in there pointing it to your old mod would be gone and you would have to set it up again.

This new system is actually pretty slick, It is just missing the ability to merge player.config files at the moment. Though from what I have read you can add a player.config file in the same folder as your .modinfo file but it will be used INSTEAD of the vanilla one as opposed to being added to it.