NEI not working

[roksraka]

I just bought minecraft 2 days ago and immediately installed tekkit...it's bun running fine for 2 days now, but when i logged in today, there was no NEI :/ other mods appear to work fine i guess...any suggestions? please help

(i'm running Mac OS X Mountain Lion and minecraft is fully updated...)

[Honeyderp]

Press "o" and you would hope minecraft isn't fully updated, as tekkit is not compatible with 1.3

[olagarde]

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....

[olagarde]

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. ;-