Modding Discussion ComputerBound

Thanks! I've put a lot of time and effort into this, so I'm glad to have some support from others.

Yeah, I've thought about grabbing a VM in order to run commands and such, I just haven't done so since I've been working on other aspects of the mod.
For one, I've decided that I'm going to move in the direction of a Lua interpreter for the computers (or more specifically, a Lua VM in Lua to run bytecode).
I'm aware that there will be a disadvantage in speed as compared to running the code natively, but running it in an interpreter gives a wide host of advantages for me in making the mod, such as better limitations as to not harm the host environment or be too resource intensive, the ability to have persistent computers, and potentially new features for the Lua side as a whole (such as an actual debug library and even the ability to JIT compile =P) so in my opinion, it will be worth the disadvantage.

 

Just wanted to let anyone who was wondering know, this project is not dead. Rather, it's quite far from it. It hasn't seen a release in quite some time because school has greatly subtracted the amount of time I have available to work on this mod.
Luckily, I can get some work in on the weekends. Hopefully I'll get another update out soon, as the mod is pretty bare-bones as it is right now.

 

Work has begun on a simple crafting station for all the computer parts.



The easy part is making the crafting station and all the recipes. The hard part is making the recipes balanced and sensible. =P
It's most likely going to function like most other crafting stations in the game, where if you want to use higher tier hardware, you'll have to upgrade the station itself.
The complexity of the tech will scale will each upgrade, much like how you start from a regular furnace and end up with an atomic one in game. The hardware will go from very old to very new. Lets hope I make it work out!

 

nice

 

Really nice project: following!

 

If you need help with anything small man, don't hesitate to ask.
Considering how interested I'm sure many people are (me included), I'm sure some of us are willing to help.

 

Thanks!

The best help I can get at this point is people trying out the mod and reporting bugs and such to me.
The second best help would be for a Mac/Linux user to message me as to show me what certain commands do in their respective terminals. In case you're wondering why, in order to access files and such, I need to use Lua functions that use the console of the host system. A bit annoying, but it works.

 

You know I did have this thought. You could include some code as included recipes. Actual code used in any (open permissions) mod that you think might be useful so people can do useful things right off the bat.

But also code that you feel serves as a useful example of different ways LUA can be used. So in that way it can serve as something like a tutorial or to expand people's LUA ability if they already have the basics down. Showing people new ways to do things. Perhaps that should be a companion mod (with this as a requirement).

I mean yeah interpreters exist but something like this ties the code into practical application that's fun at the same time. So I really love your project.

Now it occurs to me that in Starbound objects have access to certain functions, techs have other functions, active items others still, etc. Some things are client side and some things server side. Granted I don't do multiplayer with my spotty internet so I don't fully understand what is what. It is unfortunately a bit fragmented. But I believe the messaging system can relay messages between things - be they server or client sided. So you maybe a combination of function hooks and the messaging system could allow for more manipulation... maybe too much manipulation though.

You might get your buddy to go swimming in lava etc by having him use mcontroller functions and he/she may find it less funny than you do. So maybe the extra hooks would also be a separate companion mod. But I figure an RP server would love that. A DM player manipulates NPCs into going certain places and saying certain things, etc.

Wait, you are at a point where testing this out is actually viable? I assumed it was a bit more WIP still.

 

I had a similar idea. Except, the only thing craftable would be StarOS so you're not stuck with a paper weight. All other programs would be bought from an npc at the outpost, who might shift what he sells every now and then like the frog merchant does. People would be able to push their programs on github or send them to me so I can add them to the shop.

Yeah, I actually use the messaging system you're referring to for communication between computer and monitor so you can see the screen. Other functions available to computers will be accessible from an admin only modders computer.

As far as controlling players go, I'm not quite sure how feasible that is, but I was planning on adding programmable androids in the game, with specific made purposes. For example, you might use a default Android, which will probably resemble a glitch, and program it to farm, or you might use a robot specifically designed for farming to obtain better results. If you're looking to control npcs and alike, maybe something can be done with the to-be-implemented modders computer.

Well, there's much more work to be done, but if you're a Windows user, you can most certainly use it. Programming on it might be a little rough with lag here and there, but you should totally be able to make comprehensive programs. There's even a bit of sound support built in the computer, so I'd imagine it should be viable to use the mod as it is right now. If anything does change, I'd imagine it would be StarOS itself, rather than everything that lies beneath it.

 

So, after quite a bit of work and reading of the source files for Lua, I've finally implemented a more working than not Lua VM in Lua. There's still some stuff left to be done to complete it, but as of now, it totals some 470 lines (with comments). I've decided that for now, the first three tiers of CPUs will be 10kHz, 20kHz, then 40kHz. In the future, I might add faster CPUs or CPUs that go in between tiers (such as 30kHz) but for now it should be fine. Once the CPUs have been properly and fully implemented, I can start to move on to the more fun stuff, like peripherals, (and eventually modem/router peripherals). All in all, progress is good.

 

Hello, how have you been developing the mod? I was fascinated, because I did not find anything similar in the workshop. Thanks for listening.

 

I haven't been getting in nearly as much time in as I would like, unfortunately.

Around this time is when finals begin to roll their way in, along with many other projects which I've been dealing with for the past month or so, which has very much had an impact on my development time.

Don't get me wrong. I still love to work on this, and I still plan to. In fact, during the time I had been working on it, I've went through four or so different VM designs. You might be thinking "Well, why not just put all your time and effort into one?" Simple answer is, I've never quite worked on something of this scale before. If I'm going to release the mod, I want to release it without people worrying about it crashing a server or something. I'd like to make sure it's as fast and as efficient as can be, so going through different designs not only shows me what works, but strengthens my ability to create good code as a whole, much like learning the same thing multiple times strengthens your knowledge on it.

I have to apologize for the amount of time this has been taking so far. The good news is that with my current VM design, it can pretty much run whatever code I want. What's left is implementing coroutines, fixing up how memory management and garbage collection will work, and how outside functions from peripherals can be linked to the computer.

I don't have any real ETA on when a new release can be expected on. Just do know that I work on it when I get ample free time. If you're using Windows and you just have to use the mod, an alpha version can be found on my github here.

 

Defiance3 thank you for your attention, with your comment, gave me a sense of how the project is going. I know something like this takes time. I'm on windows and I'm testing the alpha version. I'm hoping for progress with the mod, it has a lot of potential. Thanks again for your attention.

 

So, I decided to simply skip over the whole VM thing for now. A while ago I had a pretty much working version, but even with all the optimizations I had, it was terribly slow.
Then I had a new idea: a byte code injector, which would insert a function in between each and every instruction. And now I have a mostly working version of that, but
there were quite a few "gotchas" which were rather annoying, and since I'm not very proficient in C, reading the Lua source code will only get me so far.

I have a new goal in mind. To just simply work on literally everything else and make this an actual mod already. And so I've been doing exactly that.
So far, I've rewritten the main computer script as well as changed a few things about peripherals and how they're used. Though, the most visible change will be that of the GPU.
The whole "bits per channel" thing is rather awkward, so I've opted to use a palette system instead. This also means that the amount of data needed to be sent from server to client side
for monitors should decrease, which is nice. As for how many colors can a GPU have? I'm not sure if the palette should increase with tier, or if the GPU should have RAM which increases
every tier. If this system were used, the user could choose the size of the palette at the expense of screen resolution (of course, you can't have a resolution higher than the monitor's).

Other than that, I want to finally get around to adding some kind of reset button on the computers so players don't have to exit and re-enter their world just to do so.
Once I'm done with these changes and more, I fully intend to release the mod properly, and then I'll see where it goes from there.

 

After many hours of attempting to understand the GUI system that Starbound has, I've finally produced an acceptable result:

This will be the new computer interface. Hovering the mouse over any of the buttons tells you what it's for.
The giant empty space to the left of all the slots is where computer-crashing error messages will go-- helpful for those making an OS. And, you probably already noticed, but yes! Those are power and reset buttons in blue and red, respectively.
Of course, they do work.

I'm wondering if I should have two eject buttons for the space next to the reset button. I'll have to think about it.

As far as other progress goes: (I might be a bit vague as to not sound too committed to anything said; it may change to be better)
* GPU has successfully been switched to a palette system. I'm in the process of adding a few extra draw functions to it.
* The monitor code has been completely rewritten, and so the FPS is a lot more consistent when using them.
* The component table has become an actual API.
* The node table has been split to deal with input and output nodes.
* Peripheral method calling has been changed, and peripheral hooks work correctly.
* And a bunch of other small things I don't remember off the top of my head.

Since it's the weekend, I'll probably be getting a whole lot done. I'll be sure to post major things here as I go.

 

Wow. If only I could take a closer look at this...
Do you mind describing some things you've done in the wiki's GUI reference?
For example, one of the things I tried to do was add tooltips to slots and other GUI elements.

 

I'll do you one better and post some example code.
Here's a shortened version of the case's config file. (Some of the item slots we removed so the more important parts of it can be quickly looked over it)

Code:

{
  "gui" : {
    "background" : {
      "type" : "background",
      "fileHeader" : "/interface/computercase/chestheader.png",
      "fileBody" : "/interface/computercase/slots17to24.png",
      "fileFooter" : "/interface/computercase/chestfooter.png"
    },
    "title" : {
      "type" : "label",
      "value" : "Computer Case - Tier 1",
      "hAnchor" : "mid",
      "position" : [80, 140]
    },
    "cpuSlot1" : {
      "type" : "itemslot",
      "position" : [81, 100],
      "backingImage" : "/interface/computercase/cpu.png",
      "callback" : "null",
      "rightClickCallback" : "null"
    },
    "gpuSlot1" : {
      "type" : "itemslot",
      "position" : [100, 100],
      "backingImage" : "/interface/computercase/gpu.png",
      "callback" : "null",
      "rightClickCallback" : "null"
    },
    
     == Eight other item slots removed to shorten this. ==

    "expansionSlot3" : {
      "type" : "itemslot",
      "position" : [119, 62],
      "backingImage" : "/interface/computercase/expansion.png",
      "callback" : "null",
      "rightClickCallback" : "null"
    },
    "expansionSlot4" : {
      "type" : "itemslot",
      "position" : [138, 62],
      "backingImage" : "/interface/computercase/expansion.png",
      "callback" : "null",
      "rightClickCallback" : "null"
    },
    "buttons" : {
      "type" : "radioGroup",
      "toggleMode" : true,
      "callback" : "onButtonToggle",
      "position" : [81, 43],
      "buttons" : [
        {
          "id" : 0,
          "baseImage" : "/interface/computercase/power.png",
          "hoverImage" : "/interface/computercase/powerhover.png",
          "baseImageChecked" : "/interface/computercase/poweron.png",
          "hoverImageChecked" : "/interface/computercase/poweronhover.png"
        },
        {
          "id" : 1,
          "baseImage" : "/interface/computercase/reset.png",
          "hoverImage" : "/interface/computercase/resethover.png",
          "baseImageChecked" : "/interface/computercase/reseton.png",
          "hoverImageChecked" : "/interface/computercase/resetonhover.png",
          "position": [ 19, 0 ],
          "selected" : true
        }
      ]
    },
    "count" : {
      "type" : "label",
      "value" : "Component Slots - 12",
      "hAnchor" : "mid",
      "position" : [80, 121]
    },
    "overlay" : {
      "type" : "image",
      "file" : "/interface/computercase/shine17to24.png",
      "position" : [0, 3]
    },
    "close" : {
      "type" : "button",
      "base" : "/interface/computercase/x.png",
      "hover" : "/interface/computercase/xhover.png",
      "pressed" : "/interface/computercase/xpress.png",
      "pressedOffset" : [0, 0],
      "position" : [143, 156]
    }
  },

  "scriptWidgetCallbacks" : [
    "onButtonToggle"
  ],

  "scripts" : ["/objects/computers/case.lua"],
  "scriptDelta" : 0
}

As you can see, I ended up using "itemslot" elements. I originally had "itemgrid" elements, but oddly enough, we're only limited to three of those. The "itemslot" elements offer a lot more customization at the price of writing more code; you can't actually put/take items from those slots without writing the code to do so. You have to define a function in the lua part of the script, then list that function in the array "scriptWidgetCallbacks." Once done, you simply change the "callback" or "rightClickCallback" parameters in an "itemslot" element to reference the name of your function, and it'll call it! I have yet to add that code in, but I'll be doing it today.

As far as the lua script goes for the computer case:

Code:

local ComputerID
local pairs = pairs

-- Base of all tool tips; this is needed.
local ToolTipLayout = {
    background = {
      type = "background",
      fileHeader = "",
      fileBody = "/interface/computercase/tooltip.png",
      fileFooter = ""
    },

    title = {
      type = "label",
      position = {2, 10},
      hAnchor = "left",
      vAnchor = "top",
      wrapWidth = 100,
      fontSize = 8
    }
}

-- Where I define the names of the tooltips.
local ToolTips = {
    -- And of course, each name, such as "cpuSlot1," is the exact name of a widget from the config.
    cpuSlot1 = "CPU Slot",

    gpuSlot1 = "GPU Slot",

    -- Item slots emitted to shorten the example

    expansionSlot3 = "Expansion Slot",
    expansionSlot4 = "Expansion Slot",

    ["buttons.0"] = "Power Button",
    ["buttons.1"] = "Reset Button"
}

-- This function is called on by the game to create the tooltips.
function createTooltip(screenPosition)
    for widgetName, description in pairs(ToolTips) do
       if widget.inMember(widgetName, screenPosition) then
          ToolTipLayout.title.position[1] = 35 - (#description*4)/2
          ToolTipLayout.title.value = description

          return ToolTipLayout
       end
    end
end

-- This is just called on whenever the power/restart buttons are called on.
function onButtonToggle(index)
    -- Check if the restart button is on.
    if widget.getChecked("buttons.1") then
        widget.setChecked("buttons.1", false) -- If so, switch it off.
        widget.setChecked("buttons.0", true)  -- Then turn the power button on.
        world.sendEntityMessage(ComputerID, "preformRestart") -- And then restart the computer.
    else
        world.sendEntityMessage(ComputerID, "setPowerState", widget.getChecked("buttons.0"))
    end
end

function init()
    ComputerID = pane.sourceEntity()
    onButtonToggle()
end

It's simpler than I thought it would be. Only thing that wasn't simple was finding all this information in one spot.
Hopefully this'll help explain it to you.

 

It really is useful. SB lacks documentation, and ItemSlot previously had no known descriptions.
I hope to add some info to the wiki as soon as I can play with it a bit on my side. Feel free to join

 

I know in SB 1.3 there will be some additional API functions for itemSlots for player inventory/item slot lua scripting. That should enable some further nifty tricks we can perform with the GUI. Nice to see you're still working on this Defiance3

 

This is interesting to see, including the GUI manipulation.