olagarde

Members
  • Content Count

    9
  • Joined

  • Last visited

About olagarde

  • Rank
    Member
  • Birthday 11/01/1966
  1. Power teleport pipes have a settings GUI with only the most basic options -- frequency and can-receive -- which makes them painful to configure and manage in any significant numbers. Item teleport pipes have a great advanced-settings GUI with clear-text labels for specific frequencies, which makes them trivial to organize at practically any number. Any chance the power teleport pipe's in-game options code could be scrapped in favor of a clone from the item teleport pipe?
  2. Title: return(?) of power teleport pipe issues, distance-dependent behavior Version: 3.0.3/3.0.4 OS: OSX 10.7.4 Java Version: 1.6.0_33 Description of Problem: The problem appears to have been briefly fixed but is back with the latest recommended version (as of yesterday night @ 2200 CST) and persists in 3.1.1 also. Same conditions as is the plethora of previous "power teleport pipe broken" threads, with 1 new characteristic: the detection of the correct number of connected pipes on a given frequency and the successful transmission of power now both appear to fall off sharply but not regularly or predictably when the source and target are more than 13 chunks away (straight-line), and there is a distinct "jumper" effect attainable by adding a lone teleport pipe block midway between source and a non-functioning target situated just beyond the 12-chunk-distant mark. Reproducer is: in source chunk: coal-driven generator fibre cable energy link conductive wood power teleport on frequency A, receive=no In each target chunk from same-as-source to 16 chunks out on any gridline: power teleport on frequency A, receive=yes gold conductive quarry Turn one quarry's pipe's "receive" setting on, then off, at successively increasing distances from the source, and the first failure usually occurs at a 13-chunk distance from the source. Leaving them all on fails when and as expected/documented. Do the same at successively decreasing distances, and the first success will usually occur at a 12-chunk distance from the source. There does not appear to be a significant difference if there are too many pipes already configured on frequency A, so long as they are all more than 13 chunks from the source. Failure to receive power and failure to accurately track the number of connections on frequency A always occur together. Detected connections in failure cases is usually 1 less than the number of connections within a 12-chunk distance from the failing pipe, unless there is at least one more pipe in the same chunk, in which case the detected connections is usually the number of receiving pipes in the current chunk only. Assuming there are available connections, the closest 3 to 4 failing pipes can be made to reliably succeed by placing a single, iosolated power teleport pipe roughly 8 to 10 chunks away from the source and toward the failing pipes. This isolated pipe does not have to be connected to anything else and must be initially set to frequency A and receive=yes. After this is done and failure cases around the 13- to 16-chunk distances start working, the isolated pipe can be repeatedly removed and returned to switch between failure and success. It does not appear to be necessary to set receive=yes after the initial placement and removal, so long as neither the source nor any other successfully receiving pipes are changed. Error Messages: none Error Log: not applicable
  3. Who's used [intentionally] chunk deletion? How did it go? I've found a number of claims of varying success, but is it a sane practice for repeated use? Put another way: would you categorize this more as a sane surgical procedure for a specific scenario or as the square-peg-round-hole-plus-heavy-mallet thing? Background: I have a world with a large chunk count loaded prior to copying/converting/massaging/beating into Tekkit. Some boob (that would be me) got curious about chunk generation patterns, went flying far, and well, map's damn big now. Tekkit ores and rubber are way out there, and 99% of the map between here and there is completely worthless [for Tekkit sciency stuff]. I'd like to reset those portions of the map. Basically I'm thinking about setting the spawn point within the area I want to retain, deleting all chunks outside of that area, loading the map up, and causing new chunk generation by traversing the deleted area again. Environment: OSX 10.7.4 java version "1.6.0_33" Java SE Runtime Environment (build 1.6.0_33-b03-424-11M3720) Java HotSpot 64-Bit Server VM (build 20.8-b03-424, mixed mode) Client: Technic Launcher 1.0.1.3 (Tekkit) Server: Tekkit Server 3.0.4 java launched with "-d64 -Xmx3092 -Xms2048" Mods: AdditionalPipes-2.1.3-MCPC1.2.5-r3 CraftingTable3_1.8 EE2ServerV1.4.5.1-bukkit-mcpc-1.2.5-r2 PowerConverters-1.3.4-mcpc78-r1 Railcraft-5.2.4-MCPC-1.2.5-R1 advancedMachines_4.0_bukkit buildcraft-2.2.14-mcpc1.2.5-r6 codechickencore-server-0.5.2-bukkit-mcpc-1.2.5 enderstorage-server-1.1.1-bukkit-mcpc-1.2.5 industrialcraft2-1.95b-mcpc1.2.5-pre1 mod_IC2NuclearControl-1.1.6-mcpc1.2.5-r3 mod_chargingbench-server-1.95b-mcpc1.2.5-r1 mod_compactsolars-server-2.2.0.5-bukkit-mcpc-1.2.5 mod_ironchests-server-3.3.1.22-bukkit-mcpc-1.2.5 notenoughitems-server-1.2.1-bukkit-mcpc-1.2.5 redpower-all-2.0p5b2-mcpc1.2.5-r2 wrcbe-addons-server-1.2.1-bukkit-mcpc-1.2.5 wrcbe-core-server-1.2.1-bukkit-mcpc-1.2.5 wrcbe-redpower-server-1.2.1.1-bukkit-mcpc-1.2.5 zimmibis-core48.2.1-tubestuff-48.2.1-mcpc1.2.5-r1