Tutorial Basic Object Implementation: A Tutorial

Discussion in 'Starbound FAQs, Q&A, and General Help' started by mollygos, May 14, 2013.

  1. Aralicia Moran

    Aralicia Moran Void-Bound Voyager

    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.
  2. Supergeek

    Supergeek Scruffy Nerf-Herder

    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:

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


    "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?
    Axe Garian and dhxmg like this.
  3. Aralicia Moran

    Aralicia Moran Void-Bound Voyager

    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]
    Axe Garian likes this.
  4. Supergeek

    Supergeek Scruffy Nerf-Herder

    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?

    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.
    Axe Garian likes this.
  5. Pentarctagon

    Pentarctagon Over 9000!!!

    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)?
  6. Aralicia Moran

    Aralicia Moran Void-Bound Voyager

    More like this :
    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 :
    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.
    Axe Garian likes this.
  7. Pentarctagon

    Pentarctagon Over 9000!!!

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

    Aralicia Moran Void-Bound Voyager

    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.
  9. Pentarctagon

    Pentarctagon Over 9000!!!

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

    Supergeek Scruffy Nerf-Herder

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

    > /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.
    Axe Garian likes this.
  11. Eight

    Eight Pangalactic Porcupine

    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
    {"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"
        "frameGrid" : {
            "size" : [16, 16],
            "dimentions" : [5, 1],
            "names" : [
                ['default0', 'default1', 'default2', 'default3', 'default4', 'default5']
        "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",
    It's not immediately apparent what this rusty old gear is even for
    Rusty Gear
    i'll be changing this later so it can have other values
    Axe Garian likes this.
  12. Supergeek

    Supergeek Scruffy Nerf-Herder

    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.
    Axe Garian likes this.
  13. Aralicia Moran

    Aralicia Moran Void-Bound Voyager

    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.
    Axe Garian likes this.
  14. 1mwb

    1mwb Big Damn Hero

    VERY Nice! :mwahaha:
  15. aljam

    aljam Cosmic Narwhal

    Wow, making objects looks incredibly easy. I would love to see more tutorials for modding.
    Axe Garian likes this.
  16. Supergeek

    Supergeek Scruffy Nerf-Herder

    I may be wrong, but from what they posted recently in the daily updates, these formats may have changed to be even simpler.
    Axe Garian and aljam like this.
  17. Alpha_Squad

    Alpha_Squad Cosmic Narwhal

    I would expect them to optimize the process, as this one is a bit redundant and dirty.
    Axe Garian likes this.
  18. aljam

    aljam Cosmic Narwhal

    WHAT? It's like they are trying to make it easier for modders or something. :chrono:
    Axe Garian likes this.
  19. Pentarctagon

    Pentarctagon Over 9000!!!

    aka not the minecraft route.
    Axe Garian likes this.
  20. aljam

    aljam Cosmic Narwhal

    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.

Share This Page