1. Please be advised of a few specific rules and guidelines for this section.

RELEASED Wired Teleporters (v0.1a) 2016-09-14

Wired Teleporter for local instant teleportation

  1. cybersam

    cybersam Subatomic Cosmonaut

    well... the thing i'm working on would allow the mod to be compatible with every mod out there...
    though... i need to get it to work.... just hope it will be possible...

    if not i'll look in to the file of FU to make it compativle with that... though i wouldn't know how to make it future proof...
     
  2. bk3k

    bk3k Oxygen Tank

    One annoying thing where implementing channels would be concerned, would be that "storage" is a bit misleading. It stores some stuff during the session but abandons it if you so much as go to the title screen.. Select things it saves between sessions. That you see is why I did stuff like
    Code:
    value = value or something()
    to keep the value if it is present, and assign it otherwise
    What I know off hand, it would save storage.state but only as a boolean. So setting it to 5 would just make it true upon loading time. I think I'd found something it saved as a numeric, if I can remember.

    Sure would be nice if that was documented. Would be nicer if it actually stored all of "storage" but no... that'd just be too easy.

    So if you want to retain that between sessions, the options I can think of are this.

    1.
    Your console has several input wire nodes. Like 4 or 8. Each hooked to a switch. Each switch will fortunately retain their own storage.state. So you build your channel number based off binary input. 8 nodes would get you 0-255 as possible channels. You could probably do with less. 4 nodes could get you 0-15 which unless you have a HUGE base to consider is plenty. But possibly some multiplayer people might just have such a huge base/planet. So maybe the 8 input nodes would be worth utilizing.

    I suppose for practical reasons you'd have this huge(8 tile wide) 80s/retro looking terminal just so you have room for nodes. In a way that could be cool. The terminal sends the channel data to the teleporter(unless you start moving this task to the terminals themselves).


    2.
    After changing channels, you spit out an item. That item goes in a container. Is the container wired to the terminal? Or is the terminal itself a container? Anyhow you can pull the information from it kind of like this.

    Code:
    function containerCallback()
      local itemInfo = world.containerItemAt(entitly.id(), 0)
      if (type(itemInfo) == "table") then
        if (type(itemInfo.teleporterChannel) == "number" ) then
          storage.teleporterChannel = itemInfo.teleporterChannel
        end
      end
    end
    and you create items containing that information kind of like this

    Code:
    
    function spawnChannelChip()
      local export = { teleporterChannel = storage.teleporterChannel }
      world.spawnItem("channel_StorageChip", entity.position(), 2, export)
      --I just made up the "channel_StorageChip" item
      --that would need to be a real item for this to work
      --and I had it spit out two items because you'd need matched items for both terminals.
    end
    Now one advantage to this method is that the number of channels you have is near unlimited. And you could really swap numeric channels for UUID if you wanted. That's certainly beyond overkill though. It can be more compact compared to tons of wall switches and a big terminal.

    The downside being every channel change you'd need to have someone travel to the other location. I guess if it is a registered teleport destination, that's alright.

    With switches, multiplayer people could just have someone on both ends to change channels. "hey bro change channels to 10010110". This makes my inner geek smile a bit more. Also the thought just inspired me to make a compact switch which also displays it's own output with 0 or 1.

     
  3. bk3k

    bk3k Oxygen Tank

    Changing your code every time they change THEIR code is going to make for a lot of extra work on your part! And what about making it work for many mods which need this access? That's not not manageable. I just downloaded it to see what you're doing that would interfere. You patched your script in right. But I saw you do


    Code:
    function init()
      self.lastYPosition = 0
      self.lastYVelocity = 0
      self.fallDistance = 0
      self.hitInvulnerabilityTime = 0
      self.shieldHitInvulnerabilityTime = 0
      self.suffocateSoundTimer = 0
    
      self.worldBottomDeathLevel = 5
    
      local ouchNoise = status.statusProperty("ouchNoise")
      if ouchNoise then
        animator.setSoundPool("ouch", {ouchNoise})
      end
    
      self.inflictedDamage = damageListener("inflictedDamage", inflictedDamageCallback)
    
      message.setHandler("applyStatusEffect", function(_, _, effectConfig, duration, sourceEntityId)
          status.addEphemeralEffect(effectConfig, duration, sourceEntityId)
        end)
    
      message.setHandler("teleport", function(_, _, toPosition)
        mcontroller.setVelocity({0,0})
        status.removeEphemeralEffect("blink")
     
        local port = coroutine.create(PlayerTeleport.Teleport)
        coroutine.resume(port, toPosition)
     
        while coroutine.status(port) ~= 'dead' do
          coroutine.resume(port, toPosition)
        end
      end)
    end


    when you want to do

    Code:
    require "/scripts/util.lua"
    
    PlayerTeleport = {}
    playerTeleport_hookedInit = init
    
    
    function init(...)
      playerTeleport_hookedInit(...) --calling the original init too()
      self.lastYPosition = 0
      self.lastYVelocity = 0
      self.fallDistance = 0
      self.hitInvulnerabilityTime = 0
      self.shieldHitInvulnerabilityTime = 0
      self.suffocateSoundTimer = 0
    
      self.worldBottomDeathLevel = 5
    
      local ouchNoise = status.statusProperty("ouchNoise")
      if ouchNoise then
        animator.setSoundPool("ouch", {ouchNoise})
      end
    
      self.inflictedDamage = damageListener("inflictedDamage", inflictedDamageCallback)
    
      message.setHandler("applyStatusEffect", function(_, _, effectConfig, duration, sourceEntityId)
          status.addEphemeralEffect(effectConfig, duration, sourceEntityId)
        end)
    
      message.setHandler("teleport", function(_, _, toPosition)
        mcontroller.setVelocity({0,0})
        status.removeEphemeralEffect("blink")
     
        local port = coroutine.create(PlayerTeleport.Teleport)
        coroutine.resume(port, toPosition)
     
        while coroutine.status(port) ~= 'dead' do
          coroutine.resume(port, toPosition)
        end
      end)
    end
    
    function PlayerTeleport.Teleport(toPosition)
      status.addEphemeralEffect("blink")
      util.wait(0.5)
      toPosition[2] = toPosition[2] + 3
      mcontroller.setPosition(toPosition)
    end



    Not that I tested that code, but you get the basic idea. I'm not familiar with the code in the init() you are replacing, but I'd bet what I posted should be slimmed down to avoid duplicate code. Your version of init() should only be what you need for your mod to work. The rest can be handled by whatever code you would have otherwise replaced.

    Now what I did there is simple. I copied init into playerTeleport_hookedInit before you essentially redefined init. Then I called playerTeleport_hookedInit() from within your init().

    playerTeleport_hookedInit may represent the original init(), or it may not. You don't have to actually care. PLus playerTeleport_hookedInit is probably such a unique name that it isn't likely to get redefined by accident if anyone else is also hooking into this.

    But the point is this. Some other mod probably is also hooking in. Probably FU and maybe others. Like you, they're replacing init and who knows what else. What you've done is replaced their version of init with your own. I made sure to preserve and run that function.

    That should ensure your mod becomes/remains compatible with theirs... unless of course you're using the same global variable names they are. You can avoid doing that by either using fairly unique names, or putting everything in a package which uses purely local variables. What I linked you in the colony manager thread is an example of me doing just that.

    Whatever works for you.

    oh and I supposed it makes sense to do
    playerTeleport.hookedInit instead of playerTeleport_hookedInit but either way gets the job done.
     
    Last edited: Sep 16, 2016
  4. cybersam

    cybersam Subatomic Cosmonaut

    cybersam updated Wired Teleporters (v0.1a) with a new update entry:

    Teleporter using channels to setup the teleportation

    Read the rest of this update entry...
     
  5. cybersam

    cybersam Subatomic Cosmonaut

    @bk3k
    thanks for the tipps...
    those helped quite a bit ^_^
     
  6. Merawolf

    Merawolf Scruffy Nerf-Herder

    @cybersam
    Hi again. May be better instead of small fivechannel system create the new one where you can type in your own code? For example we`ve got five channel but if we can open that item hud type our own code, for example 54437763, system will be hard to hack and diverce the opportunity bigger variety of channels so it will be possible for every player to create their own door
     
  7. cybersam

    cybersam Subatomic Cosmonaut

    that was the plan...
    this is just a "proof of concept" or a wip ^_^
    looking for a terminal sprite for it though...
     
  8. Merawolf

    Merawolf Scruffy Nerf-Herder

    Last edited: Oct 11, 2016
    cybersam likes this.
  9. Merawolf

    Merawolf Scruffy Nerf-Herder

  10. cybersam

    cybersam Subatomic Cosmonaut

    rl is getting in the way xD
    but i'm currently adding the doors for the next update...
    i might include that interface you posted...
    btw... it looks awesome ^_^
     
  11. Merawolf

    Merawolf Scruffy Nerf-Herder

    @cybersam,
    it is taken from mod "Macrochip" and slightly redrawn
    I think on the coordinate system is possible to create an entrance for the wires that wil switch it off. Switch it off the door will turn into close and prohibit teleportation. There my doors will be suitable for that concept.
     
    Last edited: Sep 22, 2016
  12. Merawolf

    Merawolf Scruffy Nerf-Herder

    @cybersam
    Hi again! How are things with the creation of mod?
     
  13. Shironoir

    Shironoir Void-Bound Voyager

    It'll be great if the version with working channels could be posted as update 0.1b? Eagerly waiting for a local teleporter with larger traverse distance!
     
  14. Storm_UK

    Storm_UK Existential Complex

    Hi, the teleporter system you're working on looks interesting. Note that the graphic Merawolf altered above was one I myself nabbed and altered from the Matter Manipulator upgrade interface. :)

    In regard to losing wires over longer distances, you could try something like this:

    Code:
      local visible = world.isVisibleToPlayer(rect.translate({-1,-1,1,1}, object.position()))
      if not visible then world.loadRegion(rect.translate({-1,-1,1,1}, object.position())) end
    If you put this in the lua script of an objects update, it should keep the defined area loaded in that world (change -1,-1,1,1 to cover the entire object from its point of origin.) That should allow wires to stay connected between such objects. You could also use a message handler system rather than wiring to communicate between the objects. I use this in my macrochips mod to make sure that chips and remote nodes can maintain communication.
     
    Merawolf likes this.
  15. Merawolf

    Merawolf Scruffy Nerf-Herder


    Yes, I changed a little texture panel of your mod macrochips)
     
  16. RexTheFox

    RexTheFox Subatomic Cosmonaut

    i'm giving this a go with my mod, as its the kinda thing i needed
     
  17. RexTheFox

    RexTheFox Subatomic Cosmonaut

    i have a suggestion: to disable the teleporter interface, make it so if no wire is connected, it no longer becomes interactable until a wire is connected
     
  18. Quinch

    Quinch Scruffy Nerf-Herder

    Hi! I'm not sure if this mod is still supported, but I figured I'd let you know - in 1.3 {at least}, it seems to somehow brick the energy bar for characters.

    [16:22:46.110] [Error] Exception while invoking lua function 'overheadBars'. (LuaException) Error code 2, [string "/stats/player_primary_bars.lua"]:24: bad argument #1 to 'pairs' (table expected, got nil)
    stack traceback:

    Pastebin log: https://pastebin.com/1FLSx2LR
     
  19. SSirin

    SSirin Void-Bound Voyager

    So sad that the mod does not seem to be updated anymore...
     
  20. Quinch

    Quinch Scruffy Nerf-Herder

Share This Page