[Addon v1.110/112] Beam Me Up! v0.2.1 (early alpha!)

  • i've noticed that the teleporter does not consume power when moving items i charged it up and unplugged it no change in its power lvl ive been moving a note block around a few times to check. is power usage not implemented yet until the bugs are worked out?

    Correct, I'm leaving power consumption until after the signal mechanics work properly. Which are what I'm supposedly working on right now. You can tell how hard I'm working, since I have plenty of time to procrastinate over here ^^.


    Hell ya, Narc! I'll give this a try as soon as I have a minute free! :)

    Excellent, more minions! I mean, er... I hope you enjoy it :)


    To all: shall I take it from the lack of reports that everything you've tried to teleport has teleported correctly? I'm guessing and hoping that's a "yes", since in theory the tile entities (the most complex things to teleport) should just behave as if their chunk has been unloaded/reloaded. Unless I did something wrong. Which I may have.


    Oh, and speaking of teleporting things: I am fully aware teleporting the teleporter is possible, and no, I won't leave it that way. But it's hilarious, is it not?

  • im yet to have any luck in teleporting my self so i'll have to set up a test cow to see if mobs can be moved.

  • i do love how you can move an entire chest with the items in it even works on ic2 safes. but i found you can tp bedrock does the mod have a block blacklist yet?

  • i do love how you can move an entire chest with the items in it even works on ic2 safes. but i found you can tp bedrock does the mod have a block blacklist yet?

    Not yet, but it's on the menu! Including an API for other mods to poke in and say "I don't want you to move my X".


    Transporters and interdictors will likely be included in the blacklist by default. Active beacons won't be teleportable regardless of blacklist status, but inactive ones (with the power run out) should be fine to move (if you can lock them).


    And doesn't the chest teleporting just make you want to make a storage system where, whenever you want something, you call up the chest that contains it? I didn't think of that until I teleported my first chest, after which I went "that's so logical!". Other things that are useful to teleport: redstone energy cells, MFEs and MFSUs. The latter two being particularly interesting as they will keep their orientation. I haven't tried cables, but I imagine they'd work, sort of. Another candidate for the default blacklist, though.

  • i tried to use your mod as a weapons platform with a nuke... it failed once i armed the nuke lol. any chance this will ever work like that?
    but at any rate im yet to find a block to crash my game. when I started testing i thought that a reactor would crash the game by beaming the core out but it did not.
    seem every thing is well with the mod right now aside from needing black listed blocks to prevent people from using it to make a home of bedrock lol. I cant wait for the next instalment of the mod :D also will there be textures next the next up date? i do find the pink block with sides/top marked all over it funny.

  • i tried to use your mod as a weapons platform with a nuke... it failed once i armed the nuke lol. any chance this will ever work like that?

    Yes, that is fully intended to work, though it'll have to wait for teleporting entities, as that's what armed nukes (and primed TNT and ITNT) are. Won't be too long until I turn towards working on that, I imagine.

  • Ladies and gentlemen, boys and girls of all ages, welcome to the second alpha test build of Beam Me Up! The new download is available in the first post, like always, and we've got some awesome stuff for you today:

    • Firstly, transporters don't "just work" anymore, they need a transporter lock (boo!).
    • However, it's now possible to get a transporter lock (yay!).
    • We also got some incredibly awesome new textures from The_Paragon, inspired by Star Trek: TOS! Everyone thank The_Paragon for making these and sharing them -- I personally am completely in love with the look of my shiny new stuff.
    • About those transporter locks... interdictors work now (yay!) as do beacons, though the beacons are stuck on frequency 1337 due to the subspace flux currently in progress. Interdictors and transporters are unaffected by the flux, though, and will happily accept any frequencies you set them to.


    All of which means, in terms of gameplay, at least, that the range-limiting mechanics are finally in. I want you guys to play with the new transporters and tell me what you think of their range -- is it too small, it is too large?


    Remember two transporters on the same frequency are planned to extend each other's range when teleporting to each other, so you could theoretically just have waystations every 5,000 blocks or so if you're going a really long way -- do you go such long distances normally?


    Let me know, 'cause if nothing's wrong I'm going to see about getting the transporter's biomass filters operational with some new Heisenberg compensators and let you transport entities and players next! Along with fitting those interlocks I was just talking about so that transporters can operate in tandem for longer ranges.


    Edit: Oh, hey, I just found a couple of bits that might be useful to you in your testing.


    Here's a program I used to print out lock strength and watch it for variations:


    And here's an interdictor management program that's been handy for me:


    Note you'll want to change your peripheral.wrap() statement if your interdictors and transporters aren't on the back side of the computers you place. And remember, acquireLock() before transmit() or retrieve(), and releaseLock() after!

  • I believe it was in one of the ST:TNG novels that I read about an advanced alien race who had really long range transporters and they found out it was basically a bunch of shorter range transporters that would hand you off one to the next. Being that this interfaces with ComputerCraft, I could totally see somebody setting up a system where you picked a destination within an entire network of destinations and were handed off until you were re-materialized at the final location, even if that location was out of direct transport range from where you were coming from.

  • I believe it was in one of the ST:TNG novels that I read about an advanced alien race who had really long range transporters and they found out it was basically a bunch of shorter range transporters that would hand you off one to the next. Being that this interfaces with ComputerCraft, I could totally see somebody setting up a system where you picked a destination within an entire network of destinations and were handed off until you were re-materialized at the final location, even if that location was out of direct transport range from where you were coming from.

    Kind of reminds me of the star gate relay system. The gates will send their information to another gate to store in their 'buffer' then hand it off to the destination gate, or another gate's buffer until the information actually gets to it's destination.


    I like the idea of this addon, once it becomes a little more...I want to say 'fleshed out,' then I'll give it a whirl. With CC just to play with it.

  • does any one have a decent program made for handling teleporter functions such as setting coordinates and all? im to new to cc to do any thing aside from using each command manually in the lua mode its kinda time consuming to input each command every time.

  • I believe it was in one of the ST:TNG novels that I read about an advanced alien race who had really long range transporters and they found out it was basically a bunch of shorter range transporters that would hand you off one to the next.[...]

    I think it was an actual episode -- I want to say somewhere in season 1 or 2 -- but yeah, I have the same memory.


    Kind of reminds me of the star gate relay system. The gates will send their information to another gate to store in their 'buffer' then hand it off to the destination gate, or another gate's buffer until the information actually gets to it's destination.

    That was inspiration, too.


    I like the idea of this addon, once it becomes a little more...I want to say 'fleshed out,' then I'll give it a whirl. With CC just to play with it.

    Yes, I know the feeling. It was a major win to get as much of the signal system going as I did yesterday, and there's still plenty more to do.


    does any one have a decent program made for handling teleporter functions such as setting coordinates and all? im to new to cc to do any thing aside from using each command manually in the lua mode its kinda time consuming to input each command every time.

    You might like this extremely simplistic retrieve program I've been using, then:


    I also have a transmit program that's effectively the exact same thing, but with transmit instead of retrieve near the end there.

  • narc? With that CC program, shouldn't be checking for too many arguments as well as too few? Pardon the merging of languages, I haven't gotten around to learning LUA.


    Code
    if #args != 3 then


    Also, would it be possible to set up an intercept system for PvP servers, where the enemy can change the destination coordinates for someone being teleported to the coordinates of a teleporter in the enemy's own base? It could be useful for PvP server that are "Capture The Flag"-orientated.

  • narc? With that CC program, shouldn't be checking for too many arguments as well as too few? Pardon the merging of languages, I haven't gotten around to learning LUA.

    It's not an error condition if you pass in too many arguments, they'll just get ignored.


    Also, would it be possible to set up an intercept system for PvP servers, where the enemy can change the destination coordinates for someone being teleported to the coordinates of a teleporter in the enemy's own base? It could be useful for PvP server that are "Capture The Flag"-orientated.

    Okay, that's an interesting future idea -- intercepting a teleport. Right now I'm just going with teleport area denial with the interdictors, but I can certainly see the use of being able to accept a teleport but modify its destination. Probably along the lines of having an interdictor paired with a transporter to do it: the interdictor "traps" the original transporter lock and the transporter resets the destination. I'll note it down.

  • It's not an error condition if you pass in too many arguments, they'll just get ignored.


    Okay, that's an interesting future idea -- intercepting a teleport. Right now I'm just going with teleport area denial with the interdictors, but I can certainly see the use of being able to accept a teleport but modify its destination. Probably along the lines of having an interdictor paired with a transporter to do it: the interdictor "traps" the original transporter lock and the transporter resets the destination. I'll note it down.

    Ah, okay. Like I said, I haven't gotten around to learning Lua, I've had my nose too deep in Java for a while as I'm currently working on my own mod (full mod, not addon).


    You're welcome for the idea.

  • Ah, okay. Like I said, I haven't gotten around to learning Lua, I've had my nose too deep in Java for a while as I'm currently working on my own mod (full mod, not addon).

    And speaking of learning Lua, I'm surprised nobody's caught me out about something else that's wrong with that code: there's a syntax error at line 16. I don't even remember what the right Lua syntax for what I'm trying to do is, so I just reversed the if and else blocks. Also, it turns out I forgot to release my lock after acquiring it, which I only found out after I played with the transporter a bit and found myself in the extended cooldown you get after a lock is broken for being terrible for too long.


    I went and edited with a fixed version that's working just fine for me, for the moment. I do note that it will stop working at some point in the future, as it releases the lock far too soon -- it should release the lock only after the transport is complete. Which also tells me there need to be peripheral functions to query about the transport process. Most entertaining, I say, most entertaining.

  • Star Trek-like transporters: give them target coordinates, and they can theoretically retrieve or transmit to that destination. There are other details, but that's the pitch line. I suppose I should put that in the OP.

  • On chunk resetting: Beware thread safety. The entire world can't be accessed safely by another thread.

    I worry about that, working with ComputerCraft, but it occurs to me I've probably been doing the right thing all along by just setting the teleport timer from the CC peripheral stuff and letting the main updateEntity() do the real work. I still worry a bit about working with faraway chunks, though I suspect (and will be checking; edit: confirmed) that World.getBlockSomethingOrOther(x, y, z) loads the chunk in question, at least for one tick, and that's all I need to the real teleport process. Everything else is just smoke and mirrors -- or rendering and sound, to be more precise. I've teleported things from about 1800m away for testing purposes (and to continue my wall of strange teleported things) with great success!


    Thank you kindly for the warning, and for looking in over here. What do you think about the project itself? Sound fun?