Posts by MJEvans

    Best would be for the glass to copy whatever edge towards the center from the shorter length sides.


    So a long window along a wall would 'roll down' and 'roll up' what it copies. While a taller stretch would roll in from the sides.


    The largest swaths should be isolated first, but the smaller areas should fill in before they do (FILO (first in, last out) for fill/texture copy).

    Aside from modifying all of the stuff to make yet another dimension (actually it might not be that much, but I'd guess it's still a huge pain) there's /also/ the added badness of /using even more/ block IDs for all of the new stuff you'd find in it.


    Gravity and air/lack there of changes would be a whole other level of likely to break in the future mods.

    I was bored, and the owner did say that they wanted anything that would stress test the node done...


    Since I'd already tried (and rolled back) a mountain to bedrock leveling number of nukes I decided to actually toy around with sprayfoam...


    Pictures through the spoiler (warning about 2-3 MB total)



    Here's what I've done near spawn. It has more than enough goodies in it to set-off and live through some 'firecrackers' (even without 'creative' mode); but if you actually wanted to build something fun, or see what else was already tested for stressing the world 'normally' go ahead and play around.


    If someone else wants to pick up hosting the map when this is done I've already explained that above.


    The single dot on the MFSU is where the cable hooks up? That then runs to your mod thing, and (how far) to the three-dot face of your MVTF at your base?


    One of the single dot sides of the MVTF is pointed at the LVTF and one or more single dots from there is/are connected to your equipment?

    Please be slightly more specific.


    How many of what kinds of cable are between your MFSUs and your mass fab? Are any MFSUs or the MVTFs redstoned?


    Your mass-fab can actually handle the 512eU/t output the MFSUs want to provide, but you can also use the MVTFs to limit it's input rate.

    If your goal is only to milk a single chamber to it's limits this is probably about it:


    http://www.talonfiremage.pwp.b…=1p10101001501521s1r11r10



    Notice that it cannot be run continuously. It's so tight on thermal budget that /only/ IHDs /and/ stuffing it full of cooling cells was required.


    Still, the cost is 'only' a few more glowstone dust and some stuff you probably have laying around. You'll also be getting more power out of the uranium without much less 'instant' power from the reactor. Actually at the stage in the game where I could not afford larger reactors I'd /prefer/ to build the smaller one for it's continuous operation and compatibility with 32eU/t limit wire. (If you use two gold to an LVTF you can work around this, but you'll still have the problem of using all that power at once.)

    The server is currently down for upgrades. There are backups every 15 min, but I want to make sure it's stable before leaving it online. I'll check again when I wake up.


    Hopefully the changes tonight will improve the network latency one user was kind enough to report. I actually noticed a vast improvement in IO and memory allocation relative to a different benchmark, so I'm looking forward to further improvements.


    PS: It is setup to auto-load the server on reboot, however if there is level corruption I'll revert to the most recent clean backup.



    Edit: I had to roll back to slightly before the updates. I don't believe any actual user-data was lost.


    Spawn seems to be near 7, y, -141 If you connected previous and ventured far from that area you might want to let a mob finish things off and send you back... Just watch out for the creepers; if they blow up something near spawn let me know and I'll fill it in with sprayfoam.

    Sounds like it... BUT! I've noticed that sometimes certain machines can take the full packet, even if it brings them over their limit. Take an MFE or MFSU that's one EU short of full, and send the largest input packet they can take - you will notice it brings them up to 600,127 or 10,000,511 respectively. Not sure how other machines respond because it's not as easy to track the power transfer reliably.

    I /believe/ this behavior was documented in other posts and is likely only the case in the various storage tier devices. Still I wouldn't rely on a batbox buffer alone on the receiving end to be sufficient without first running tests. In my cases I've already laid out the investment, or (in the server section) am running a temporary test server where the entire point is to test the container and thus short-circuit directly to the higher tiers of technology which are more likely to stress the server.

    I believe that a /wrench/ should have a chance of destroying things, but even more so that an /electric wrench/ should -never- destroy things. As such I have fixed his balance mistake with the offered mod/patch on all of the IC2 installs I control.


    The whole point of advanced technology is to make life better. It's silly to think that an advanced wrench might not return something (or that if it doesn't it should have the same pathetic success rate a normal wrench does).

    Your observations are valid, but the correct kit is an MFSU, 3-6 lapotronic crystals, the transformers and enough glass fiber cable to service things.



    If you insist on using HV cable to supply things then you're still going to need some kind of buffering (a batbox per mining rig will suffice), but you'll need to use a redstone clock to gate the step-up transformer back at base with a pulsing waveform. It will have to be on for only the portion of the cycle that correlates to the needed portion of a single packet. I've noticed that the fully upgraded miner and pump tends to draw about 24 eU/t while running well (less with the pump). That translates in to ~ 20.48/2048 per tick, or 1/10th duty cycle per mining rig. If you run two rigs at once a standard 5-clock with a pulse former will work. http://www.minecraftwiki.net/wiki/Redstone_circuits (I'd use redpower2 now, but it's doable).


    It should also be noted that each redstone tick is 0.1 seconds, where each IC2 power tick is 0.05 seconds (real time).

    Sorry for anyone who connected after I went to bed last night. Other testers ground the node to a complete standstill and the administrative action of the operators resulted in data-loss bad enough for minecraft to complain about decompression errors on startup. I've rolled back to where things were when I went to bed.


    Since no one was able to get in and build up during the time before I planned to turn on mobs I'll be populating chests with armor just outside of the spawn protected zone and erecting some sprayfoam walls around said zone. (I need to do some tests to determine where this is)


    Automated backups now occur every 15 min thanks to a shell script. The worst case scenario is thus system lock during backup resulting in 15 min of data-loss. (Actually that's not quite true, that's the worst /normal/ failure case; the worst total is someone corrupts the whole node; which is very unlikely.)


    I'll work on automating movement of 'off node' backups later this afternoon when I have spare time.

    Thank you the few who did hop on. Not much happened, but I did gain some valuable information from setting it up again from scratch and automating everything properly.



    ---
    209.141.54.44


    [2607:f358:1:fed5:22:0:e0e5:8514]



    A hosting company in California is testing out the stability of a new kernel for their hardware and it's reached the stage where they wanted real world usage loads stress testing the hardware instead of just synthetic benchmarks.


    This is an OVZ 1024 server with the 2.6.32 memory map (virtual memory is actually virtual) and the following sever launch script:



    Please feel free to test this out, abuse Redpower tubes, buildcraft pipes, and anything else that isn't griefing related.



    Rules:
    1) Play fair, have fun.
    2) No one is responsible for your data loss.
    3) If possible I'll export schematic files via MCEdit run on whatever backups might still exist when asked nicely, as I happen to have spare time.


    Monsters (mobs) get turned on starting at the beginning of Nov 27 at Midnight GMT. They're off right now since it's difficult enough starting up with just hunger and the point is to load test higher levels of pipe/tubes/solar/nuke abuse.


    4) This may go offline at any time. It is running off of an extra free account setup /just/ for testing this hardware. When the tests are over, so is this server (unless someone else wants to host it). Someone else -may- be allowed to host it. If you build an area and plant your flag (a personal chest) in that area you can ask to have that area's chunks cleared if someone else does pick up hosting.



    Edit:


    PS: if you have trouble connecting please retry a few times. It seems to be very stable once connected. Also, if requested I'll likely alter which non-core mods are included (some/none) or change the mob/pvp settings.


    Edit 2:
    It would have been nice if someone let me know about BC2 having updated. I checked their sourceforge page before starting this but it's still at 2.2.4.


    Core mods:


    mod_IC2 v1.337b
    mod_RedPower(all) 2.0pr3b
    mod_BuildCraft(all) 2.2.5



    Addon mods:
    mod_IC2Thermometer v1.15
    mod_EnergyCoupler 0.21.1 (Does this still work?)

    See, I hadn't seen -any- post stating that 1eU/t packets weren't the cause of lag, only the alternative theory. However, my suggestion /does/ simplify the number of nodes in the network, and thus (if a tiny bit of information is cached in the 'generator' nodes relating to their current generation capacity) would reduce the chunk load/unload issues.


    As for the topic format; we're already in the suggestion area, redundancy in topics is redundant. If it's a requirement, thank you whomever fixed it.


    Finally as for errors/removed/deleted posts. Please be like unix commands; when there's an error -tell the user-.