Jump to content

olagarde

Members
  • Posts

    9
  • Joined

  • Last visited

About olagarde

  • Birthday 11/01/1966

olagarde's Achievements

Dirt

Dirt (1/9)

0

Reputation

  1. BTY, sorry mind not on what I am doing. Modified jar is launched with script which wraps java within pushd/popd to unique directory, immediate goal is to have launcher file tree created within that unique directory instead of always within "~/.techniclauncher". Linking and/or mount encapsulation would move the install directory, but there would still only be *one* install directory. Or just say "go make your own", if I could take source and develop myself this too is I suppose a valid answer.
  2. Lacking source to PlatformUtils (and lazy admittedly) I have tried an obvious experiment, made a test jar with appropriate ".techniclauncher" binary-replaced with ".", space-padded to enforce UTF8 const pool integrity. Launched and ran fine in original "~/.techniclauncher" location, though now install directory ".techniclauncher" does not exist jar file? Then noticed network. Disconnected network, launcher hung before presenting login panel as expected, "~/.techniclauncher" not created or existing. Started strace (-fFvp) on re-launched child and reconnected network, launcher immediately proceeded as expected. Directory "~/.techniclauncher" is created with timestamp of network stack and route table update on network reconnect. Output of strace on re-launch of jar per manifest.mf mainclass implies that network comms is informing install location. True or bad guess? Please allow me a clarification: my goal is to have sweet Launcher update capability but also have Technic installs be self-contained and/or relocatable. Enforced common install directory makes very cumbersome to have multiple different-version technic instances concurrent. Makes side-by-side comparison of two Technic trees with different mod/content on one system very inconvenient. Configurable install directory makes installing, backing up, and testing multiple versions of launcher, technic, mod collections, etc., quite trivial, just operations on file trees really.
  3. Launcher Version: 1.0.1.3 Operating System: RHEL5 Linux 2.6.18-194.8.1.el5PAE and OSX10.7.4 Darwin 11.4.0 Java Version: 1.6.0_33 Antivirus Program: Description of Problem: Please excuse language failure, am C and perl, not java. Also unsure where to put feature request so here it goes, please correct if this is wrong.... Feature request: for installation directory in PlatformUtils.class, id 020 offset 0x0001244, please advertise argument to main class so that location can be runtime changed like "java -Xmx1024m -jar {launcher JAR} {installdirtag}={installdir}", or add widgetry to launcher option panel to do same? Error Messages: Error Log:
  4. I suspect it's a combination of local I/O latency and cycle starvation. IMO race conditions on writes to disk are *loosely* implied, but it's kinda flaky for me to try to point a finger on the sparse results here.... Found player dat file garbaged and NEI cfg OP tags truncated at '= ' after leaning hard on cycle-starving the server. See below, nice() is your frienemy. 8-p Rate of failures can be dramatically increased by going from stock 64x texture to 128x, to 256x, with re-nice-ing of the lead java pid/tid up (giving the server successively poorer priority in the competition for local resource contention handling). Scrub the server, launcher, and technic dirs, reinstall, restore the world(s) backup, and start the server nice'd to place the child tid tree just under the kernel soft irq handlers, and I can't make it fail at all. After that, stop the server and launcher/client, limit the properties and ops files as normal, start the server, and restart the launcher/client, and all the NEI widgetry is present, accounted for, and seemingly stable. Moving server PRIO down to a reasonable-but-not-zero value (zero on this box is effectively "competing evenly with everything else using the default prio") and I haven't *yet* seen a burp, so that's a thumbs up. So, yea, fairly easy fix, and I guess it's not unexpected what with SMP, hd textures, big map, high load, blah blah blah. Don't have the bits at hand to isolate network, paging, and disk resource contention, so confidence is high that it's load related and low that there's a race condition with data-at-rest getting completely written under high load conditions. But IME if it's java, perl, or python, and I see this sort of thing, it usually turns out to be an async write that's getting blocked, then timing out or getting killed or interrupted or whatever, with insufficient (or no) sanity checks after the write to ensure everything made it down. Just my WAG, and worth exactly what you paid for it. ;-
  5. 3.1.2 / 1.2.5 and latest launcher as of today java 1.6.0_33-b03 RHEL5 / 2.6.18-194.8.1.el5PAE I have the same problem, the issue is not that "o" was inadvertently pressed. NEI is enabling and disabling on the fly -- for example, thinking the NEI enable state for its various options might be stashed in the world somewhere I restarted server and client with fresh installs and a newly gen'd map. The NEI interface appeared on first spawn. Pressing "o" toggled visibility as expected, several times, in the first 20 seconds or so of play. I walked for 30 seconds and found that pressing "o" stopped having any effect (NEI not shown). On repeats of the entire install/update/start sometimes NEI would work, sometimes not, either starting or stopping responsiveness (to "o") at varying lengths of time after first spawn, but usually within 30 seconds NEI would be unresponsive. No complaints in the logs, on the server console, etc. Feels like NEI's tracking of it's kbd events is dropping into the weeds. Either that or some part of NEI enable/disable state written into the world and is getting trashed. Don't have a bigger system to see if failure rate goes down with more horsepower, but it would be interesting if it did....
  6. Had the same problem and conditions; turned out to be a corrupted player file ({world}/players/{login}.dat). Remove, respawn, all good.
  7. 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?
  8. 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
  9. 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
×
×
  • Create New...