Tutorial Basic Object Implementation: A Tutorial

I guess it would be a logical way. But for now, you should do as you feel. Those king of things may wait for latter. I was arguing "on principle".

Yes, you can have another image as metadata; and yes, it's much more complicated; It implies computed CRC, for examples.

 

This may be a bit overkill, but I would like to propose the following for mod files:

1. File Name. The file names should be in the following format: [MODDER TAG]_[MOD NAME]_[VERSION].zip

MODDER_TAG would be something like "Supergeek" or "Mollygos".
MOD_NAME would be something like "Toothpaste" or "Cougarzilla".
VERSION would be a version tracker so you know what version you've got if there's an update down the road. I would suggest major.minor.rev.

Some examples might be:
Supergeek_Cougarzilla_0.1.1.zip
Mollygos_SpinningCogs_0.2.0.zip

2. File structure. Subdirectories for \mods and the modder tag inside the file, like so:

\mods\Supergeek\Cougarzilla.object
\mods\Supergeek\Cougarzilla.frames
\mods\Supergeek\Cougarzilla.objitem
\mods\Supergeek\Cougarzilla.png
\mods\Supergeek\CougarzillaIcon.png
\mods\Supergeek\CougarzillaIcon.mod

"mod" would be a text file with any message the modder would like to write to the user. Information on the mod, licensing terms, their personal web site or Starbound server, greets, pizza recipes, diary entries, whatever.

I don't want to step on any toes, but I think eventually there will be a LOT of mods, and imposing some good organizational strategies before people start producing mods is a good idea.

I welcome any responses to my suggestions. Let's talk about it!

I am working on a site for uploading, managing, creating, finding, editing, and sharing mods. Is there open source software for something like this, where you have user accounts, file uploads with metadata, ratings, search, etc?

 

I agree on principle, but since we don't know the extends of the mod support (does it accept subdirectories ? does expect mods to be archived ?), I suggest to only work on a general guideline for now.
In this post I comment on some of your propositions, and introduce my own.

I. On file names and file paths.
1) On the use of the Mod Name in the file name / file path : I find this to be the basics. I don't think it's humanly possible to don't think to include it.
2) On the use of the Modder Tag/Name : The main issue I have with this is for collaborative mods, since they have multiple Modders. I suggest to either make "Modder Name" optionnal, or switch it to "Team Name" (as one-man teams are completely valids).
3) On versioning : As much as I agree on the usefulness of mod versioning in the file path, I don't believe that specific syntax should be expected; some people would want to include revision, other will use other systems. Thus, I believed mod versioning should be expected, but version syntax should only be suggested.

II. On object naming
1) Please note that I'm talking about the object ids, not the visible names (shortdescription).
2) As objects must have a unique name, in order to avoid conflict between mods, all objects should be prefixed by a identifier associated to the object's mod. The value of this prefix is up to discussion, I thinks using the mod name would result of a too long prefix, and while using a 3 char prefix would be easier, there would still be a risk of conflict.

III. On File structure
1) Should Starbound support multiple subdirectories for mods, I approve the use of the mods/TeamName/ModName/ path.
2) Should Starbound support multiple subdirectories for mods, I suggest that the modders try to keep their mods organised by making use of them (maybe by creating a subdirectory per distinct functionality)

VI. On the use of a .mod file
1) I approve the use of a mod file. Moreover, I suggest that we work on an optional header syntax for this mod file so that (future) mod managers can easily extract useful data (mod name, mod team, version, website, category ?, etc)
2) I would also suggest to add a "cover-style" image that could be shown to represent the mod. The path/name of this image could be indicated in the .mod header.[/quote][/quote]

 

Yeah, that makes perfect sense. We just want to be able to identify the source uniquely.

Absolutely. Just a suggestion.

If objectName is a purely internal (invisible to the player) identifier and there's likelihood of collision between names, it would be very helpful to have a central registry for them... like a centralized mod registry. It would also be good to know what exact limitations we have to work within, e.g. field lengths, character set, and so on. If objectNames can't be long, we will definitely get collisions if people just start picking them randomly without thought for uniqueness in the community.

If objectName length isn't an issue (say, 256 characters), I don't see a problem with running out of space to include modder+modname.

If length IS an issue, we'll have to figure something out.

Not sure what you mean by distinct functionality. Like, categories? Something like the following?
"mods\Supergeek\weapons\LaserSword"
"mods\Supergeek\decorations\VanGoghPainting"

1) I think that would be great. Once we know more about what types of mods are going to be available, we can work on the syntax.

2) I agree a screenshot illustrative of what the mod does would be very helpful. I know I like to browse things visually since it's much faster than interpreting a lot of words.

 

Checking for conflicting IDs really isn't that hard (I know because I could write a program to do it), but keeping the IDs solely internal make no sense. If you make no IDs publicly visible/usable, how could you make interactions between items such as recipes or conditional reactions based (like based on what type of projectile hit what type of block)?

 

More like this :

Code:

mods\Aralicia\MyCustomMod\weapons\LaserSword //data for laser sword
mods\Aralicia\MyCustomMod\weapons\DeathPistol //data for death pistol
mods\Aralicia\MyCustomMod\decorations\VanGoghPainting // data for painting

Or like this :

Code:

mods\Aralicia\SuperMounts\code\ // the code for supporting mounts
mods\Aralicia\SuperMounts\plains\horse // data for the horse mount
mods\Aralicia\SuperMounts\plains\saddle // data for the saddle
mods\Aralicia\SuperMounts\desert\worm // data for the desert worm mount

Or pretty much anything. The recommendation is : don't have 50+ files in one directory; partition it.

When talking about internal ids, Supergeeks meant "not visible by the player", not "not visible to anything else". His point was : if the player doesn't have to manipulate the id, it's not a problem to have "supergeek_myultimatemod_deathpistol" as ID; which is true

However, if people make item mods, with no ways to create said item (as it is often the case with Skyrim mods, for example), then the user will have to type in the chat something like "/give Aralicia supergeek_myultimatemod_deathpistol". Such a length for an ID may quickly be bothering.

As for checking conflicting IDs : the issue is not to check them, but to ensure that multiple mods from multiple sources will not use the same ids. A quick example :
- Modder A decide to create an really original weapon : a lightsaber ! He decide to give him the ID "lightsaber"; as soon as he finished he upload this mod for anyone to use.
- In the meantime Modder B (who doesn't know Modder A) also decide to create a lightsaber, and he use the same ID (why not ? It isn't used by anyone);as soon as he finished he upload this mod for anyone to use.
- Player C is really a fan of Starbound and Starwars, so he search for lightsaber mods, and he find two, lucky him ! He decide to download and use both. But, he now have two items with the same ID ! That means that (in the best case), one of those will never be accessible.

In order to avoid those problems we need to ensure that different modders will use different ID, even if they don't know each-other or which Ids has already be used. Thus, the suggestion to prefix IDs by the Team Name and/or Mod Name.

 

The only way to ensure that though, would be to have the game rename all conflicting IDs when found, which I dislike.

 

Yes, it would be the only (and completely insecure) way to absolutely ensure that.
But, if all (or at least most) modders agree to use prefixes and/or a central registry, it would do wonder to limit conflicting IDs.

 

Getting everyone to agree to use/do anything is extremely unlikely though.

 

Maybe in the case of duplicate "objectName"s, Chucklefish would force us to use an internal hash. Like:

Code:

> /spawn lightsaber
Ambiguous objectName.
Found two matches:
:: lightsaber ID# 113
:: lightsaber ID# 117
Please specify ID #.
> /spawn 113
Item spawned.
> /spawn 117
Item spawned.

But then again, if we're writing scripts at some point where items interact, like if I had an NPC that could wield a "lightsaber", he might wield the wrong weapon, or no weapon. We definitely need unique identifiers.

 

I think a 4 letter prefix for objectNames should be used if it's from a large mod, but for mods with ~10(complete guess) items, I think there should be a different system.

I've actually saved all the data for .object, .frames and .objitem in a single file to save space

Code:

{"ObjectName" : "sewergear",
"descritpion" : "It's not immediately apparent what this rusty old gear is even for",
"shortDescription" : "Rusty Gear",
"race" : "glitch",
"dropItem" : "sewergear",
"category" : "decorative",
 
"orientations" : [
    {
        "image" : "sewergear.png:{colour}.{frames}",
 
        "imagePosition" : [-8.0, -8.0],
     
        "frames" : 5,
     
        "animationCycle" : 1,
     
        "spaceScan" : 0,
     
        "anchors" : "Background"
    }
]
}split{
    "frameGrid" : {
        "size" : [16, 16],
        "dimentions" : [5, 1],
        "names" : [
            ['default0', 'default1', 'default2', 'default3', 'default4', 'default5']
        ]
    }
}split{
    "itemName" : "sewergear",
    "rarity" : "sewergear",
    "inventoryIcon" : "sewergearicon.png",
    "dropCollision" : [-4.0, -5, 4, 5],
    "descritpion" : "It's not immediately apparent what this rusty old gear is even for",
    "shortDescription" : "Rusty Gear",
    "race" : "glitch",
    "objectName" : "sewergear",
}

Code:

v1.0
sewergear
It's not immediately apparent what this rusty old gear is even for
Rusty Gear
glitch
sewergear
decorative
-8.0
-8.0
5
1.0
0.1
Background
16
16
default
sewergear

i'll be changing this later so it can have other values

 

From http://playstarbound.com/18th-may-progress/ :

So, sounds to me like the game will support:
1) mods loaded from mod-specific directories
2) some kind of archives for assets

Hopefully 2) means zip files.

 

The fact that assets, or even (possibly) mods will be packed is good news, I my opinion.
As for the format, it may be zip files, but they may chose another format. Wouldn't be surprised if they use tar or tgz.
On one side, zip doesn't use solid compression, which means that we don't have to uncompress the whole archive to read one file, which isn't possible with compressed tarball. On the other, it is less memory-efficient than solid compression formats.

 

VERY Nice!

 

Wow, making objects looks incredibly easy. I would love to see more tutorials for modding.

 

I may be wrong, but from what they posted recently in the daily updates, these formats may have changed to be even simpler.

 

I would expect them to optimize the process, as this one is a bit redundant and dirty.

 

WHAT? It's like they are trying to make it easier for modders or something.

 

aka not the minecraft route.

 

Hah! I kinda wanted to mod minecraft, but I figured I'd wait till the api comes out. It's been over a year and they are finally starting to shift into getting their mob api semi complete.