Posts by narc

"Socket closed" is just as generic as "disconnect.generic", unfortunately. It kind of had to be just a network thing.

Quote from ff255away

I'm responding from the other thread, so as to hopefully let it die?

I'm okay with using both threads, I keep an eye on most of the IC2 forum regardless so it's no inconvenience to me either way.

Quote from ff255away

Anyways, thanks for such a quick response! How opposed are you to a multiblock structure? That would be the easiest way to increase the cost of the components, but would definitely make things a bit more difficult to code, and the lag could be minimized to only search for the other blocks by including them as apart of when the device is used (if you have the transport console, energizing coils, phase transition coils and molecular imaging scanner, but no transport platform, there could be problems). Similar to MFFS's pseudo-multiblocks, where you need a certain type of energy which can be transmitted wirelessly to other blocks which require their own added modifications for functionality.

Mm, I do like that idea -- it might take a bit longer to write the code, and I'll need to poke The_Paragon to see if he has time/willingness to make textures for things, but it makes sense to have the transporters be multi-block structures.

Quote from ff255away

If you were to use a multiblock structure, it looks like a minimum of transport platform (where the heisenberg compensators would be located), a console, the energizing coils can easily be replaced with mfsu's/whatever gregtech capacitor you want, and the phase transition coils and molecular imaging scanner could be functionally combined into a single unit. That would be 3 blocks required in addition to the capacitors.

Although keeping the phase coils and scanner separate is perfectly fine, as well. I rather suspect the Heisenberg compensator is actually a component of the molecular imaging scanner: it compensates for the Heisenberg uncertainty principle, after all.

Quote from ff255away

Maybe take a page from greg's books, and use emeralds as data storage (rarer, don't have as many uses as diamonds), which would be useful in something that stores the necessary information to recompile teleported objects.

Emeralds as part of the console construction. I'm not sure it's feasible to have any portable storage of teleported things -- it would work for everything but players, and how does one logically explain that in-universe?

Quote from ff255away

So, if you're teleporting a player to yourself, and there is no platform for them to materialize on, would that kill them? This could make a sweet assassination mechanic. Especially if you set things up so that they conveniently had a beacon on them at the time (have an ally throw it at their feet).

Ooh, that's a tricky one to balance: how do you make sure it's not too easy for players to get killed this way? Interdictors have a fairly small limited range compared to the distance a player might roam -- but now that I think of it, actually targeting a player will be exceptionally tricky in and of itself. Okay, I very much like it.

Quote from YX33A

Hm...Just a thought, but if you're planning on adding a GregTech level Hard Mode, you might want to make it require use of a GregTech level energy flow(aka use of a redstone'd Supercondensator to be able to charge it quick enough).
Currently the only device which needs a Supercondensator is a Fusion Reactor, and even so, it uses it to down-convert the power output.
Use of a new energy type which is in essence a super high value EU level(as these devices can be charged with EU, one could convert quite a lot of EU into a single energy unit for these devices) would make use of a Supercondensator to up-convert the EU would make sense in then.

The thing about GregTech is I don't play with GT, and I rather do want to play my own mod, plus I don't really know what's available. The part that touches on it most closely in the current (mildly revised) implementation plan is just to allow you to plug in as much energy storage as you like and use the existing teleporter API bits to suck it dry quickly -- this should make GT storage blocks very useful as they'll give you more buffer, but that's about all I can safely do within the limits of my own playing style.

Quote from YX33A

Plus, Multiblock structures ROCK. I fully support using Multiblock setups to transport stuff, and remember, bitches love particle effects. I also love the idea of teleporting nukes into by foes bases, active ones. So I hope this all works well enough, because I'm adding it to my game.
Might not be able to use it much, but it's still sweet.

Yeah, I'm fully with you on that. It's an immensely fun idea with plenty of potential for what is otherwise a fairly simple addon.

Just to be clear, though, I'd like to reiterate what I've been saying lately: I'm currently being kept busy at my new workplace and development is naturally taking a back seat to that, and I'm also prioritizing LiquidUU above this addon, as I have some ideas there in the middle of being implemented. I will be making sure BMU continues to be updated to the latest MC/IC2/whatever, but LiquidUU is getting first pass at my limited addon-programming time for the foreseeable future.

And again, thank you all for the interest! It's what keeps me going.

Agreed, I was just adding to the semi-off-topic comment above.

Have you tried looking through the Forge javadoc? It includes the Minecraft classes, and occasionally has useful comments left in. Other than that, reading other people's code helped me a lot when learning modding. You're going in a direction I don't think anyone's explored, though.

Quote from DrBlocks

I do not particularly use 1.2.5, but I read somewhere that it was the latest IC² server build available.

This is technically (and only technically) correct -- starting with Minecraft 1.3.2, Forge made it possible to unify the client and server packages of given mods into a single "universal" package. You will be undoubtedly pleased to know the person making the quoted claim was not entirely talking out of their ass, but were just being a smart-ass instead.

^ You beat me to it, Pantheis, I was just about to advertise for you. Still loving the storage monitor, by the way

Quote from RawCode

nothing special with RP2 code, it merely save TE objects just like they saved on chunkunloading and then load on new location, you can implement this method without issues youself.

Yes, that's how I did teleporting in Beam Me Up!, which is even open-source, so anyone's welcome to steal those bits of code. Turned out to not be all that complicated, and works every time (near as I and other testers can tell).

I do know that Railcraft gives you a charcoal dust item and (if so configured -- by default it is) allows charcoal to be macerated to its dust. Unfortunately, this does not give you the other recipes this addon gave you (namely, solar panels, coal fuel cells, SU-batteries and the classified recipe), but using a custom recipes mod, one could add them back in.

^ Good sir, you may be extremely interested in this thread, where I've already begun the implementation process.

Unfortunately, as I recently mentioned in my other addon's thread, I'm currently somewhat busy at work and therefore development is going fairly slowly (and I'm currently prioritizing LiquidUU, as well), but BeamMeUp is definitely not forgotten!

As for your specific requests, the first one is absolutely designed in from the start. My current list of configurables looks like this:

interdictorRange = 8; // blocks in every direction, so 17x17x17
    positionImprecision = 16; // (blocks, calculated independently for all six directions)




    lockDuration = 600; // (ticks)
    lockCooldown = 20; // (ticks after releasing a lock)
    lockLossCooldown = 200; // (ticks after losing a lock below lockThresholds[2], cumulative)
    badLockDuration = 20; // (ticks)




    transporterBaseSignal = 500;
    signalPerBlock = 1.0;
    transporterBoostMultiplier = 0.1; // (bonus signal when boosting with MaxBoostEU/t)
    beaconMultiplier = 0.8; // (reduce by 20% of effective distance)
    interdictorSignalRatios = { 0.5, 0.4, 0.375, 0.33 }; // (for each additional interdictor)
    lockThresholds = { 0.9, 0.5, 0.1 };
    lockVariance = 0.1; // (standard deviation from the base value)




    interdictorBaseConsumption = 4; // (EU/t when enabled)
    interdictorDampeningConsumption = { 1, 2, 3, 4 };
    transporterLockEU = 512; //(EU/t)
    transporterBadLockEU = 1024; //(EU/t)
    transporterBoostEU = 512; //(EU/t)
    transportCostPerBlock = 100; //(EU)
    transportCostPerItem = 1000; //(EU)

Logically, setting any of the costs (available in the configuration file) to 0 will cancel out that part of the calculation equations.

As for the component costs, this is really fully up in the air at the moment -- I haven't yet given any thought to crafting recipes, and would more than welcome thoughts on the subject. Feel free to give me a nice, complex set of components (make sure to include a Heisenberg compensator in the transporter recipe!) and perhaps suggest where steps along the way could be simplified for easy-mode recipes... or don't, I may end up having only hard-mode recipes. I rather do think a transporter like this should be pretty damn expensive.

Teleporting to other dimensions was actually discussed a bit in the BMU main thread, so I hope you won't mind if I quote myself:

Quote from narc

It's definitely possible, and it's something I'd like to do, but I'm not sure how to balance it with the intra-dimensional teleport mechanics.

It feels like an inter-dimensional teleport should be quite expensive, and very range-limited -- perhaps even a forced 1:1 mapping of coordinates (and then what about the Nether's native 1:16 mapping?) -- because you're using the transporter in a way it's "not designed" to be used.

Though, to be fair, I'm also not sure if I want to build this into the regular transporter or make the inter-dimensional one a special machine of its own -- if the inter-dimensional transporter is its own machine, it can have different freedoms and limitations so it's theoretically easier to balance.

For now, I'm saving thoughts of inter-dimensional teleporting for after I have the basics ready and working, but feel free to suggest restrictions/freedoms that might make it balance well.

Display More

I appreciate all thoughts and suggestions and promise to always give them full consideration -- note this does not necessarily mean I'll accept every suggestion, but if I refuse one, I will tell you my reasoning. Thank you very much for your interest!

I apologize -- I'd thought it was a fairly common turn of phrase to speak of "baking [a feature] into [a piece of software]", but it turns out to be a relative rarity. Nevertheless, it is what I wanted to say: I can head off any problems with the remote accelerator connection by not writing it in the first place.

As with any open-source project, of course, you're perfectly free to fork it and implement the feature yourself -- I'll even perfectly happily link your builds from the OP of this thread.

Edit to add: I'd like to warn everyone interested in this addon that development may be a little bit slow in future -- I recently got a new job and they're keeping me well busy. I'll try to keep on top of things during weekends, but if there's something you really, really want done and you have programming experience, you'll probably get it faster by forking the project and implementing it yourself. If you do, please do remember to make me a pull request so I can pull it into the official repository; building LiquidUU is a relatively simple and quick task, so I can do it just about at any time.

Indeed. I am choosing to do so by not baking it in in the first place.

You mean instant operation isn't OP enough, and we need to add remote linking? I'm sorry, I have a hard time accepting that.

I don't think that would fit with the way GregTech is intended to work.

Here's a picture of all three liquid transfer systems, for reference:

Is the wooden pipe pointing out from the tank? Are you providing Buildcraft power? Is there liquid visibly in the pipes?

Sure, it might be an incompatibility that's breaking Buildcraft, but it's not terribly likely.

It should work like any other machine that accepts liquids -- pipe the liquid out of your tank, into waterproof pipes or liquiducts or RP2 fluid pipes, and then into the accelerator. The face that connects to machines will not accept liquids and should also not visibly connect to pipes.

Here's the setup I had in the OP of this thread using buildcraft waterproof pipes and an autarchic gate: http://img.narc.ro/minecraft/m…erated-logistics-full.png. I can take pictures of setups using the other two liquid transport systems. It should work with a railcraft liquid unloader, as well, but that one I've honestly never tested.

Quote from MatLaPatate

If I remember right, you weren't here when the talk about breakdown mechanics appears. [...]there is one thing that can easily be resumed:
-The one who like having no Endgames were pro, and the one liking Automation were against.

I was there, I just didn't participate in the discussion because I couldn't be bothered to enter a minor flame war nor did I follow all of the suggestions closely. As far as I'm concerned, a breakdown mechanic isn't something IC2 *needs*, but it can be something to help the post-endgame situation. Tweaking it to allow for unlimited automation is not difficult (and speaking of endgame, I do have the LiquidUU Accelerator to help even further there) -- the one real-time month of MTBF that I mentioned earlier suggests most players would see three failures of the same machine over the span of a server's world. It does make more trouble the more machines you have, but as long as all the interesting knobs are configurable, one could even go as far as disabling the machine breakdown mechanic altogether if it was felt that it didn't fit in with what each specific group of players like.

Returning to that earlier discussion of breakdown mechanics, I personally recall being disappointed in all of the people wildly proclaiming that a breakdown mechanic would mean damnation and hellfire for all of IC2 when it was fairly obvious that such an important change from behaviour of machines in other mods would demand that there be a way to turn the breakdown mechanic off -- TE pulverizers don't ever break down, so it has to be possible to make macerators never break down, either. However, if it's done right and tweaked correctly, most people should never even think about wanting to turn it off -- the trick being to determine how much of this potential irritation people are willing to handle. I personally like the idea of having to pick up my toolbox once in a while and replace a circuit in a macerator that's made several hundred stacks of dust for me.

Inside I'll be tossing in the internal tank (spherical, a little more than half of the block in diameter, centrally-positioned) and a number of small blocks (something like 1/8th to 1/3rd the width of the block) positioned more or less randomly on the machine-connected side of the accelerator. I'll most likely have the corners of the block be solid at probably 1/16th the width of the block. It's harder to describe than to show, given that I haven't decided what it'll look like yet beyond "some black boxes thrown around the inside", so I'd much prefer to show you what we have to work with before I ask you to make anything texture-wise.

My only thought on the matter is "generic machine", i.e. something probably a bit like bedrock in appearance that just sits there and looks vaguely like it might contain the working parts of the accelerator. I don't specifically want to deal with a texture that isn't 16x16 -- I like being able to shove it into the same blocks.png I'm already using -- but this isn't a hard and fast requirement; if it'll look better as 32x32, I'll make it work. However, given that I'll be using a full block-size texture for things that are not full blocks, I think I can just scale and tile the full texture instead of chopping it up -- which will have the same end result.

Mmh... I can work up a little demo version to show the internal tank fairly quickly, but making it actually show all the important parts (including transparent outer and inner face textures) may take some time. Do you want to see just the internal tank, for an in-game idea of the size?

Oh, I see, an explicit texture for the face opposite the machine connection. I think the "see the inside" change is going to fix that better than patching the current temporary solution (and yes, I know, it's been "temporary" for months; we'll get there, I promise).

Will greatly appreciate anything you can come up with, and there's no time frame required -- I don't know when I'll get around to poking at this from my end, either.

This seems perfectly reasonable, with plenty of room to tweak things so that the breakage effects make electric tools neither useless nor irritating. I would even see this working as a maintenance mechanic for machines, in general, not just generators -- that certainly fits with the industrial theme we have going in IC2.

Machines should have a much longer mean-time-between-failure than tools (they aren't subjected to the same handling stresses), but should probably have a fair chance of becoming broken when picked up with a wrench as they aren't designed to be moved (in fact, replace lossy/lossless wrenching with this mechanic). A player who never picks up his machines might go for a month or more before any machine broke down -- that's longer than I've managed to play a single world in a long time.

As a final thought, if we use parts for repairs, it may be a good idea to add a Forestry backpack for spare parts, e.g. refined iron, circuits, etc., to somewhat mitigate the inventory cost of repairs away from home. Though I could equally see a Redpower canvas bag being a good enough alternative.

Um, were you going to link to the ideas you wanted us to read about? If so, you may have forgotten the link.