hoho

It depends largely on how the game is built up of course. Wow basically sends everything to everyone in a certain distance so if my tiny little spriest did a tick of damage with vampiric touch it healed 5 people + all their pets and generated mana to 10 people in raid in addition to doing that damage. That information had to be registered on server and all the information also had to be sent to clients so they can update their UI and other stuff. It is possible to pack together some stuff (e.g if multiple people are healing one guy you add up the healing over a certain period) but it has it's limits. I used to do some hardcore combatlog analysis when I raided and it was usual to get around 400MB of log files over an average 4h 25-man raid night with all the events individually listed and timestamped. To do that client MUST get all those events. You can pack several of them in a single packet but you can't add them together. You can't do something like boss taking x damage from 10 people -> send packet "boss took 10*x damage", there has to be 10 events with different sources, spell type, timestamp and damage values. Obviously that 400MB was in somewhat human-readable format and network data was somewhere around maybe 10% of that but also consider it was just 25 people. 25 players, each do a single event, server receives 25 events, server sends out 24x25 = 600 events in total 100 players -> 99*100 = 9900 events sent out 250 players -> 249*250 = 62250 events From the little I know GW2 is far less spammy compared to wow due to slower combat with less (aoe) healing and dots so it will scale somewhat better and somewhat bigger battles become possible. Having people spread out over big area so they don't affect each other also helps immensely. Have you ever played wow before last couple of content patches in WotLK? Giong into wintergrasp in a half-decent server meant server response time dropping to over a minute. Once they limited the are to 2x100 player instances and separated them entirely from the rest of the game world things got better but still once people reached the main gates you had all of them in some 50x50m area with lag going through the roof.

Generally I see that kind of redundant code coming from college freshmen who have written their first ever programs, some hardheads need maybe a couple of months to evolve further from that. Main problem with the code is that gets incredibly hard to maintain and error-prone. That specific example isn't too bad performance-wise as it's comparing integers but I wouldn't be surprised if there are other cases where they call some expensive functions in similar ways.

I remember the makers of Lord of the Ring Online saying they quadruppled their revenues after going to F2P model and they also were selling pretty much only cosmetic stuff. Later on they added things for boosting reputation/XP farming and profession leveling. And also I'd say 5$ spent on a game that you'll be playing for hours is unimaginably better investment than using it on pretty much any other form of entertainment. E.g I've spent around 15$ on MC and have played it at least around 500-ish hours and had tons of fun. Using the same money to e.g see a movie would have only provided me with a few hours of entertainment and considering how bad most movies are it probably would have been worse on fun/hour metric as well.

IT is actually pretty awesome. You only need to stay away from people you are doing stuff for. I've yet to see a non-retarded client that has a clue what they really need. As long as you have someone between yourself and the client who can translate their stupidity into their actual needs things are good. <- a programmer for 8 years

Re: Next Go-Around, please configure the pack better for balance and gameplay

Actually I believe the most certain way not to miss diamonds is to dig 1-wide tunnels from 16 to bottom layers. If you only do 1x2 then you may miss some in rare cases*. Though if you don't care about missing things then yeah, 1x2 is fastest. *) 0 - missed blocks 1 - visible blocks _ - empty space oxooxo x_xx_x x_xx_x oxooxo oxooxo x_xx_x x_xx_x oxooxo

Holy bajeebus. I knew MC code was horrible but I never could have hoped that it's worse than the 10 year old legacy winCE stuff I've been beating back to life for past year o_O

I kind of feel bad that he can't reply any more as seeing this kind of logic just breaks my mind. I'd say it might be useful for the other future to-be-banned users but I don't think they'd ever read this thread anyway

Change NEI to cheat mode from options. It's on recipe mode by default.

Got the stuff as well but I'm not really sure if/how much I get to play it. Got plans for Friday+Saturday with GF and considering I entirely skipped the D3 open weekend in favor of playing around with the updated 1.2.5 mods I wouldn't be surprised if I end up doing the same with GW2.

For one thing the gnome devs seem to think their users are as dumb as an average brick so they don't give them many options for customizing stuff and instead hide them away in obscure config files or simply don't give any options at all. Though I admit this has seemingly been their direction for years now and not just with Unity. I mean seriously, who the hell can't manage having more than a few things in their menus and break down in fetal position if they see more than a couple of tabs for configuring file manager? I probably shouldn't even begin to talk about their file picker dialog that has been awful since forever.

I found an awesome valley in a jungle biome and I'm wondering should I cut it down to burn up or just pump it full of lava. Technically now that I have access to easily collectible lava I don't really need all those trees any more

Re: [MC 1.1/SSP 6.0.7] JAKJ's "Fair Trade" 0.1.0.0 (Apr. 8, 2012) I'd love to see that kind of tree-chopping/mining changes. Will those work with all trees, including redpower gigantic rubber ones and thaumcraft stuff (meaning is it easy to make it work with them, treecapitator doesn't seem to work)? Will the mining stuff work with non-ores as well (target cobble -> mine a ton of it without moving)? I guess the mining thing could be made into a configuration option Also, I finally got around to testing the liquid stuff and it works awesomely. Just RP2 pumps seem to have a tiny bit of problems depositing it as waterline isn't always spreading as far as it should and I'm getting just 1-2 blocks sometimes instead of 8 that it should spread. Quite definitely it has nothing to do with your mod though.

And that's why being an asshat primadonna pays off in the end.

Of course it is possible but you have to design the game for it from grounds up. Proper multicore scaling can't be bolted on later on with spit and gum. I've written software that gets data streamed to it at around 70MB/s over LAN, massage it through a crapton of weird algorithms and display to screen with minimal delays while also logging the entire stream to sqlite database at same time. The whole thing ran on some crappy low-end dualcore laptop without a hitch, only if I wanted to run it in debugger I had to use a beefier quadcore. So yeah, I'd dare to say I do know something about programming multithreaded and effective stuff That's not a problem with using multiple cores in general, it's a "feature" of the awfully coded minecraft. Proper algorithms are the key to everything. Memory layout and not doing pointless new Object everywhere instead of storing intermediate results is another. MC seems to be using the worst of everything. If you don't get near-linear scaling with adding 4-8 cores you haven't used proper multithreading-friendly algorithms. It's not a problem with multicore being inefficient, it's a problem with lazy/stupid/bad programmers. Of course there is also the excuse that the app was good enough already so further optimization wasn't needed. As parallel programming is new to most people they don't want to use it and instead use as much of the "good-old" linear stuff that they've been using since forever. Yes, locking is slow (not sure if Java actually supports having a lock active and run other unrelated threads during the lock or not. I know it was added to Python not too long ago) and that's why you shouldn't be using algorithms that require it. It is possible to build working queues with zero locks and no busyloops. Yes, that would be a bad thing to do but that just shows things are coded the wrong way. Having lighting calculated one frame/tick behind redstone signals would allow to "double-buffer" the redstone data and thus eliminating any need for locks or other complex stuff to be able to parallelize things effectively. Also lighting is only one part of the load, there are tons of other things that are not blocking behind that that can be run simultaneously. I haven't coded in Java for about 7 years and instead have been doing plain-old C++ instead. C++ gives you a TON more tools to write stuff efficiently and safely. I'd even dare to say that it's far easier to write non-leaking stuff in C++ than in Java as proper RAII is far easier to do with C++ exception handling, smart pointers and destructors than with Java finalize() functions. Also it's completely possible to write applications that have very little memory reallocation during runtime. Yes, you can't eliminate it fully but seeing MC memory usage go up and down by several hundred MBs in a few seconds is clear sign of something being terribly wrong somewhere. Also using future pattern makes quite a few parallel programming tasks almost trivial. So to recap once more, MC is awfully coded and I fully blame it's creators in it's awful performance [edit] Reading more on the bukkit thread, all the talk about having to use locks for everything is a clear sign those people haven't really done half-decent parallel programming in their life and/or they are stuck in 10y+ old patterns and solutions. [edit2] And to whine some more about Java and VM-based languages in general I'm currently working in a relatively big company writing software for enterprise-level mobile stuff, other teams are working on other stuff. When we occasionally bitch about how bad our stuff is then I'm hearing far more about memory management from the VM based stuff (Java and .Net) than from the C++ guys. Properly written constructors-destructors and using smart pointers instead of raw ones pretty much guarantee everything will work in C++. In Java/.Net you need to manually free up anything on problems as you can't rely on the garbage collectors to do stuff for you. Also all the goodies of C++11 are just pure awesomeness. If MC was written in C++ or at least supported addons written in it I'd be all over it in a heartbeat. Going back to Java after all those years is huge step back for me in terms of ease of coding.

I'd really be interested to see him explaining his point in detail. "i am not going to stand by while people who bought the game cant play this on 1.2.5." followed by "i will not use Technic nor tekkit at all" is kind of odd and I'm very interested in seeing the trail of thought that produced this.

I believe if there are bugfix releases for mods for the MC versions that technic is using then those may get updated.

So what's the problem? Go and implement it!

Re: Could this remove the need for a Technic pack? Another reason for the modpack to keep existing is that I highly doubt mojang comes up with good enough API to allow stuff like NEI item groups to Just Work, adding all the axe-like tools to treecapitator or making BC miner to dig up all the better-than-cobblestone stuff (though last I looked it still ignored bunch of stuff in technic). In a modpack those configuration changes can be made manually and thus have a properly working modset.

Re: [MC 1.1/SSP 6.0.7] JAKJ's "Fair Trade" 0.1.0.0 (Apr. 8, 2012) Getting my stuff built up without using EE is taking longer than thought so I still haven't managed to test how the liquid stuff works. Though I did find a somewhat funny bug/feature with the explosion change. Basically I had a steam engine overheat on me and it just sat there exploding endlessly as fast as it could like a firecracker. I bet it would be even funnier with nuclear plant going supercritical :)

Wintergrasp on Al'Akir was just broken. The server has about 1 alliance per 20 hordes and it was a rare sight to see more than 3 of alliance in WG during any battle. When they were there they were like friggin bosses with the tens of stacks of tenancy or whatever that buff was called. Luckily for me I couldn't care less about pvp :D