Posts by narc

All right, folks, I'm in need of some assistance in testing this thing, so I'm calling out to all of you. Before I start, though, this very very important note:

Keep backups (of your world)!

While writing the mod, I've had several chunks reset because the teleport mechanic wasn't working properly yet, and I make no guarantees it won't happen again, or even leave your world impossible to get into. If it happens to you, I'll want the error report, but there won't likely be anything I can do to help, and MCEdit doesn't speak 4096 block IDs. With that said, we've had several people trying to make it crash for about a week now, and haven't had any problems, so it might be safe.

What is this thing?

Star Trek-like teleporters: give them target coordinates, and they can theoretically retrieve or transmit to that destination. There are more details, and so if you feel like a bunch of reading (and learning what's supposed to be in the mod at the time of the proper release), head over to the feedback request thread I made for it earlier.

What's new in this build, Narc?

• Still no recipes, you still need to be in creative mode (Decorations tab) and/or have NEI to get the blocks (they are called Transporter, Interdictor and Beacon).
• Still no GUIs, so you must use ComputerCraft to do anything. Still.
• Interdictors affect a transporter's signal, as do beacons (though beacons are permanently locked on frequency 1337)! Interdictors also consume the appropriate energy, though beacons don't.
• Transporters do not consume energy yet, though they have storage for up to 10,000,000 EUs.
• A config default has changed: signal { lock.variance } now defaults to 0.05 instead of 0.2 -- the higher value was far too noisy in early testing. Delete your config to have it regenerate with the new defaults.
• Transporters require you to have a lock before they will transmit or retrieve! Once the process has started, though, the lock can drop without ill effects.
• Speaking of ill effects, there are none for having a low-quality lock (not yet, anyway). Be aware that this will likely be the next thing on the menu, along with the other missing bit: transporter interference.

The ComputerCraft API for the transporter now looks like this:

• getEnergyLevel() -- returns the number of EUs stored in the block (you can also right-click the block to get the same information).
• getTargetCoordinates() and setTargetCoordinates(x, y, z) -- guess what these do?
• getFrequency() and setFrequency(freq) -- again, guess what? The frequency a transporter operates on determines what interdictors it can bypass, and what beacons it can use. Remember beacons are currently locked on frequency 1337!
• hasLock() and getLockStrength() -- pretty self-explanatory
• acquireLock() and releaseLock() -- note that there is a cooldown after releasing a lock before a new lock can be acquired. Also note that if you lose a lock to having it under the "terrible" threshold for too long, the cooldown is greatly increased! Release your locks when you don't need them!
• retrieve() -- teleports blocks from the target coordinates to itself. Probably crashes if you forgot to setTargetCoordinates first.
• transmit() -- teleports blocks from itself to the target coordinates. Same note on crashing as above.

You will also want to know the interdictor CC API:

• getEnergyLevel() -- same as on the transporter, gives you an energy reading.
• getFrequency() and setFrequency(freq) -- just like on the transporter, only more so: the frequency set here will be exempt from being affected by the interdictor. Make sure your transporters and interdictors match frequencies!
• enable(), disable() and isEnabled() -- 'dictors don't respond to redstone yet, so you'll have to use this method if you want to disable them.
• rangesOn(x, y, z) -- purely a debugging helper, this allows you to ask the attached 'dictor if it can dampen at the given coordinates.

What needs testing

Signals! And interdicting signals! And boosting signals with beacons! Most importantly, tell me if you're happy with the range you're getting out of your teleporters now -- and remember, just because your < 50% strength teleports don't randomly shift the target coordinates now, it doesn't mean they won't do so in the future.

Does the teleport range need a boost? Remember that we plan for two transporters on the same frequency to boost each other and allow you to teleport to and from one another over something like double the range of your furthest current teleport.

Feedback?

I put up a feedback request thread a couple of days ago -- so far, the only real "complaint" has been the teleporter distance calculation (using Manhattan distance), and that's not one I'm going to budge on. If you have thoughts or inspiration while playing around with this, please let me know here or there.

Speaking of feedback, feel free to look at config/BeamMeUp.cfg and tell me if there's a tweak in there that isn't explained well enough or if there isn't a tweak in there that should be. I considered putting machine EU storage and max current allowed in there, but I'm not sure it's necessary -- you guys let me know if you think it should be.

Downloads

• BeamMeUp 0.2.1 (universal) for Minecraft 1.4.6, IC² 1.112.170, and ComputerCraft 1.48.
• BeamMeUp 0.1.3836e29 (universal) for Minecraft 1.4.5, IC² 1.110, and ComputerCraft 1.47.

Version History (reverse chronological order)

• v0.2.1 -- makes BeamMeUp not crash if it tries to start up on a server.
• v0.2 -- straight update to Minecraft 1.4.6.
• v0.1.3836e29 -- makes interdictors capable of interdicting, beacons capable of beaconing, and transporters care about signal strength.
• v0.1.a7f0de98 -- makes transporters that can move blocks. Any blocks, including chests, energy storage blocks, whatever. And they keep their inventory.

License notes
The mod itself is under the Minecraft Mod Public License, source is available at its Github project page or in the zip file.
The sounds are released under Creative Commons-Attribution by Keith W. Blackwell.
The textures are also under Creative Commons-Attribution, and are made by The_Paragon.

There we go:

Steps to reproduce: place a charging bench (implements IEnergyStorage) next to a teleporter and link the teleporter to another one, so it can try to teleport you. Then, try to teleport.

Lack of IWrenchable means the other possible bug/crash isn't there, happily.

Did you try wrenching them? I'm getting 2x Low Voltage Solar Array when wrenching a single HV one. Edit: And nothing when wrenching an LV array. That's some really interesting behaviour.

Progress report, since people are interested:

I just teleported a number of things with great success: cobblestone with a torch on it, a pair of logs out of a tree, a door, a chest, a liquidUU accelerator, a crystal chest, a buildcraft tank with liquidUU inside, a turtle, and a seed library.

I have also successfully teleported myself several times, but not using the current method.

I also have a trio of beautiful teleport sounds from freesound.org, namely the three related to this one: http://www.freesound.org/people/zimbot/sounds/122979/. They sound bloody brilliant.

Still need to: teleport entities (including players), make some visual effects, both for other players and for the one being teleported, implement transporter locks (half of it is in there at the moment, but untested), implement beacons properly... yeah, still a bit to go. That's not even an exhaustive list. But, I'm super-hyped with what I've managed so far. I hope you guys enjoy the progress report.

^ So change its block ID? That is one of the most basic things in running modded Minecraft, after all.

I think it was a feature of one of the older versions of Mistaqur's NEI plugins, but it was a good long time ago -- before IC² had its own built-in NEI handler, maybe?

Quote from RawCode

and how exacly painting cobble related to IC2?

...exactly the same way painting CFoam is related to IC2. Honestly, sometimes I swear you're just trolling.

As for the original post, it's possible to make this, but it would require a lot of work and would likely not look terribly good -- and it would probably break a lot of things for other mods in the process. It's not likely to happen, sorry.

Quote from Two

[...]Expected behaviour: Energy is drawn from both boxes by machines and excess energy is stored in the second then first batbox.

You don't actually need to loop at all -- just connect the two batboxes to each other in series, and output from the last batbox into your machines. It does exactly what you want.

I made an update. LiquidUU 0.7.9 makes the accelerator work with the extra bit in the IC2 wrench API, which honestly wasn't that big a change in the first place.

You'll also note the version history disappeared -- that's because I moved it to my website, where I also moved the older downloads. If GitHub doesn't want to host binaries, I can do it myself, TYVM. Please let me know if you have any problems with the downloads -- they should just work (including through wget), but if something goes wrong I can actually look at it and fix it now.

Quote from Pantheis

Forge is pretty accommodating to pull requests if something needs to be fixed / added / made protected/public. I would encourage you to check on how to do that and submit the code. It sounds like the change could benefit others.

Mhm, I think I know what the patch needs to be, too. I'll look into it when I haven't got like fifteen different things being done all at once ^^.

Quote from Pantheis

I have to admit, I am very excited about this mod. Tallinu and I had been discussing creating a transportation mod modeled after the turbolifts in Star Trek, but then started getting all sorts of elaborate and interesting ideas. In the end we shelved it for now to work on other things, but I may just have to dust that idea off. After all, how better to get to your cool transporter room than in a turbo lift?

How entirely true! I'll be keeping an eye out for the turbolift mod!

Quote from HobbyCraft

Cool Are you used to modding, or is it kind of a fun thing/hobby?

Kind of both and neither at the same time, if that makes any kind of sense? I only started modding a month ago, with great help from FunnyMan3595, and most of the time I've spent doing it so far has been learning both Java and the Minecraft innards I've had to deal with. However, I came into it with the experience of someone who's been programming, off and on, for something like 14 years (most of that time actually spent working with Web applications, of all things). I will definitely admit it's fun to work on something and see the results of my work fairly quickly, and it's even more fun to read about people reacting to my work. Is that more or less what you were asking?

Quote from Pantheis

I think it must be possible to freeze the player in place, including preventing falling, given that if you pick up a player with the gravigun or portal gun, they don't fall and can't technically move. You can move them around, but they can't move themselves. As to how to do it, I have absolutely no idea.[...]

It's a fairly heavy-handed method, from what I've seen: GraviGun, at least, declares a tick handler and then iterates held players and does stuff to them. It's not the easiest thing to translate, especially out of deobfuscated, decompiled code. Luckily, I don't have to -- I figured out the silliest hack ever: have the player ride an invisible entity, as if they were riding a minecart or boat.

There was an interesting moment when I found out that returning false from shouldRiderSit() doesn't actually do anything because it gets overridden by idiotic code (see Entity.isRiding() and understand that getFlag(2) will always return true if this.ridingEntity != null... yeah)... and I was forced to reflect my way into it to make a protected function (Entity.setFlag(int, boolean) if you're curious) accessible so I could call it. Ah, well.

Quote from Pantheis

For the particle effects, you should be able to have the TileEntity spawn particles at a specific x,y,z, I think. For something more elaborate, I haven't a clue. I haven't worked with particle effects or much of anything rendering wise in any of my addons.

I'll figure something out -- I've been doing that basically since I started modding Minecraft.

Quote from Thutmose

Blocks may be the thing for some things, but others do use the actual distance, such as lighting, loaded chunk radius, arrow range, liquid spread distance, view distance, etc. for a transporter, it should probably be based on the actual distance, rather than the sum of the coords.

Really, that's what you're going to pick on? Everything else must be totally awesome, then.

Just for fun, I'll have to inform you that lighting and liquid spread are governed by Manhattan distance rules (the diamond pattern makes it pretty damn obvious), and loaded chunks are actually a square (no, really, the Y dimension doesn't exist for chunks), not any kind of distance at all. Arrow range and view distance are the only ones that actually do have Euclidean distance rules, but they are terrible examples.

Considering the actual calculation is completely irrelevant to the player, who only gets to see a signal strength readout, I think I'm in good shape.

Quote from MatLaPatate

I hadn't been brave enough to read the whole thing but ... why not using [Euclidean straight-line distance]?

Because I want to. Literally, that's the only reason ^^. I know how to calculate the distance, but I prefer this one, it makes for an interesting change. Plus, this is Minecraft, blocks are kind of our thing, aren't they?

Quote from Pantheis

This sounds like a really neat addon! The only feedback I have is that it would be really awesome if you could manage to make some sort of particle effect happen around things being transported instead of it just instantly teleporting the entity/block to the destination. A "transport time" as you would see in the actual Star Trek universe.

Yes, and I *really really* want to do that, but I have no idea what would be involved in that yet (also, I'll need graphics, but yeah). Also, particularly for teleporting players around, do you know if it's possible to freeze a player in place? It would make things a lot cleaner if I didn't have to worry about the player moving while being teleported -- and that includes them not falling while they're being transported.

Eh, a screen flash and a blindness potion effect sound okay, as far as visual effects go. Persistent radiation is a no-go for multiple reasons, but a momentary effect again sounds reasonable. The mushroom cloud is a no-go not just because of possible lag, but also because it's really difficult to do right.

I know, I said I wouldn't comment, but just saying "lag" is too simplistic.

I won't comment on the other stuff, but I'm pretty sure the nuke drops less than 50% of what it breaks already. Let me just go check...

Yeah, there it is: the drop rate for a nuke is 0.05 (that's 5% for the mathematically-challenged) as of IC2 1.106. I don't think it's changed since then.

As one or two of you might know, I'm working on a Star Trek-like teleporters addon I'll be calling "Beam Me Up!". I'm at the phase where I've got a lot of the core mechanics decided, but there's still room for a little tweaking and I'm not sure which people would like to play more. So I'm asking you guys to give me your thoughts on the matter, hopefully giving me a clear direction.

Before the questions, though, let me explain the core mechanics already in place:

• Firstly, we have the transporters themselves, which can lock onto a set of coordinates and transport any blocks or entities from those coordinates to themselves, or the other way around. Each transporter operates on a frequency, which will become important in a moment.
• Secondly, we have ways of reducing a transporter's effective signal in an area, using either (powered) interdictor blocks (which can be configured to allow one frequency un-dampened) or interdictor grenades, which temporarily dampen all transporter signals in an area.
• Thirdly, we can boost the transporter signal by reducing the required signal to lock onto an area, using beacons which are charged with EUs in an MFE or MFSU and will consume that charge when placed on the ground. The beacons only affect the one block they're standing in and its immediate neighbours, and cannot be teleported while powered. On the other hand, they don't completely occupy the block they're in (they're like torches) so you can stand inside them. Beacons on the ground can be recharged using an energy crystal or lapotron crystal, and their charge lasts about five minutes.

These are the absolute core mechanics that are unlikely to change. Building onto these, we have these derived mechanics and design decisions:

• Two or more transporters on the same frequency will interfere with each other, making it difficult to acquire locks on any given coordinates. The interference is relative to their proximity to each other, so a transporter far enough away won't interfere at all. But wait, there's more:
• Two transporters on the same frequency will boost each other when transporting to each other by halving the effective distance between them. One can assume what's happening is one transporter sends to a halfway point, then the other transporter receives from that halfway point, all of this happening too fast to see. To do this, both transporters use power both for maintaining the target lock and for the actual teleport (Obvious corollary: if one transporter runs out of power, they're not working in tandem anymore).
• Interdictors' effectiveness stacks the more of them are covering an area -- the first interdictor halves the effective signal for any teleport, the second reduces the resulting signal to 2/5ths, the third to 3/8ths of the previous result, and the last to 1/3rd of the result of the other three reductions. An area covered by four interdictors is completely immune to teleporting (possibly barring two teleporters working in tandem, but that isn't a worry).
• However, this increased effectiveness comes at the cost of more EU/t consumed when more than one interdictor is dampening a target lock. The cost, however, does not increase beyond the fourth interdictor, given that the interdiction effectiveness also does not.
• Interdictors also consume EU/t while idling -- presumably, they're scanning frequencies within their range for transport locking attempts. This is a constant consumption that can be turned off only by disabling the interdictor itself (by applying a redstone signal, or using ComputerCraft).
• Beacons have a purely portable version that can be carried in your inventory (on your hotbar, specifically) which is a less effective signal booster than a placed beacon, but allows a transporter on the same frequency to lock onto your coordinates without needing to have them passed in. This is designed to work with wireless redstone to allow a remote teleporter that you wish to have retrieve you to do so.

I'm currently considering the configuration aspect of the mod, and ideally I want to have all the base values be configurable by anyone who understands the inner mechanics. So let's discuss the finely-detailed mechanics of how transporters work:

• Acquiring a lock on a remote set of coordinates requires some "signal" based on the 3-dimensional Manhattan distance to that block (abs(targetX - xCoord) + abs(targetY - yCoord) + abs(targetZ - zCoord)). Currently, this is set to be 1 signal required for every block of distance. A beacon can reduce this by a configurable percentage (currently 20%), but only if the lock is being acquired on the beacon block or its six neighbours.
• Transporters have a base signal value (currently 500) that can be boosted by a percentage of the required signal for a given locking attempt (currently set to 20% of that value), using up to a configurable amount of EU/t (currently 500) to provide the boost. Boosting works on a logarithmic scale, so the more EU/t you're using to boost, the less the next EU/t you invest will be worth. Interdictors reduce this value by the previously-detailed method.
• Transporter base signal, reduced by (distance * signal required per block), is also used to decide the strength of the interference between multiple transporters on the same frequency. This currently translates to transporters more than 500 blocks away from each other having no interference at all.
• When a transport lock is acquired, it has a signal strength which is the ratio of effective signal / required signal, modified by interdictors, beacons, etc.. The signal strength determines the effect of the teleport on the item being teleported (all of the thresholds being configurable):
  
  • A signal between 90% and 100% means a guaranteed perfect teleport.
  • Between 50% and 90%, teleporting a player or mob has a chance of giving them a bad potion effect, like nausea or blindness; teleporting a block with inventory has a chance of losing items from that inventory as they "never rematerialize".
  • Between 10% and 50%, there is a chance of the teleport target shifting by up to 16 blocks in each of the six directions, and (this is very important) teleporting does not ensure that the destination is survivable! It's perfectly possible to get teleported into stone if your target lock was less than 50%; blocks trying to teleport into other blocks will just be bounced back, though, as an anti-griefing measure.
  • Under 10%, there is a chance of the teleport failing completely and never rematerializing you, if this happens you will have been killed by "a transporter malfunction". You can also lose blocks this way, so if the signal strength is that low, you *really* don't want to teleport anything.

  
  

• A lock under 10% signal strength held for one second will be lost, sending its transporter into a cooldown lasting 10 seconds (again, configurable), during which the transporter cannot acquire new locks. If the lock is broken before the one second timeout, the cooldown is proportionally reduced. If the signal strength rises above 10%, the cooldown is completely mitigated.
• Transport lock signal strength can naturally vary by up to 20% (yes... configurable) of its normal value (e.g. a 10% lock can vary between 8% and 12%). This uses a Gaussian distribution, so it's more likely to remain near the real value, but can spike up or down reasonably far.
• One final bit of internal mechanics is the range at which the interdictor can affect a teleport lock, which is a cube with an odd number of blocks per side, configurable by setting how far away from the interdictor it is still effective (currently 8 blocks, giving a 17x17x17 cube).

Wow, that's a lot of information. I didn't really realize how much of it there is, as I just built it up over the last couple of days. If you got this far, thank you.

So now the feedback requests: I will carefully consider requests to change any of the mechanics involved, within reason. I had one specific question, but in writing this post I went over some of my calculations again and came to a conclusion, so it's basically a free-for-all. What do you like? What don't you like? Most importantly, what do you think will make for a better experience, and what do you think will make for a terrible experience?

Well, a chainsaw isn't really a sword, despite its excellent damage against mobs. I'd mark it as intentional. Also, get Railcraft, use crowbar

Thaumcraft 2, current? I'm sorry, we must be running completely different Minecraft versions. See, when you said Thaumcraft, I really thought you were referring to the one that came out just a couple of weeks ago, not the one that's been finished and un-updated for several months.

Thaumcraft 3 isn't really settled yet, and I'm sure Azanor has ideas for working with Flux. Also, I wouldn't base any large bit of IC2 on a mod that may or may not be installed in other people's games. As for being sure a lot of us would love to see this, I don't seem to be in that group. Though that does make me think it might be interesting to have Flux have some kind of effect on machines/cables...

...dammit, no, I already have two large addon projects going. And TC3 isn't really settled yet, as I said!

^ Reproducing: make sure you don't have a chunk loader keeping things loaded, place solar generator and batbox, walk or teleport away. You should see the warning just about when the chunk unloads. Might not need the batbox, but it's more likely to happen if there's an energy sink somewhere in there.

Quote from Two

The problem doesn't start with decompiling, but when you try to apply the fix. It would be really annoying for players if they'd had to download the main version plus 20 mods or so that individually fix several bugs in that main version.

Well, yeah, that's why he mentioned a separate branch that everyone with a fix could just make pull requests to. Then players would only need to download a single binary.