LexManos

Its out of PermGen memory, give it more. -XX:MaxPermSize=128m

Alright, so looking into that latest snapshot with the client thread reveals some very interesting things. 1) Rendering the world takes up 38% of your client tick 2) Checking for gl errors takes up 36% of your client tick 3) You are receiving massive amounts of MultiBlockChanged packets which are taking up ~10% of your tick time. 4) World.tick actually only takes up 6% of the tick. Now lets look into that deeper, the part that actually complains about clientside chunk ticking is the last 6% up there World.tick That gets broken down into various functions that recheck lighting. Which is exacerbated by the number of block change the client is receiving. As noted above you're spending A LOT of time in MultiBlockChanged which would make me think that you're getting a lot of them. What are you doing in the game? Are you generating new chunks? Can you provide logs from this profiling session so I can see? You should not be getting that many lighting rechecks unless you're actually doing something in the world {like generating new chunks which is just always laggy, or there are mods doing things} Have you tried pre-generating chunks and then sitting waiting for the initial flood of lag caused by rendering EVERYTHING to subside? Also, I am REALLY concerned about #2, CHECKING for gl errors should not take THAT much of your time... As it's done once after the world renderer... Unless GL is really screwed up. You may want to try cleaning out and cleaning your graphics drivers. I am not a graphical person so honestly I have no idea when it comes to that end. You might also want to try running with the jvm args: -Dforge.forceNoStencil=true To disable Forge's enabling of GL's StencilBits. It may be that we do not detect that your card doesn't support Stencil, and thus its erroring A LOT in the gl code causing lag. But This is just a wild guess, as stated im not a graphics guy. {this also has nothing to do with the client stating 'tick took to long'}

[22:29:49] [main/ERROR] [FML/]: Unable to read the jar file Mekanism-1.7.10-7.0.0.75.jar - ignoring java.util.zip.ZipException: error in opening zip file Your mekanism jar is corrupt.

There are log files you can see them in your screen shots. We need those for full details -.- By guessing by what you have posted: 10:55:23 AM CONSOLE: java.lang.OutOfMemoryError: PermGen space You need to give your server more permgen.

There are MANY MANY sites out there that let you paste large text files -.-

No there is nothing like this, or any plans to have anything like this. the best you're gunna get is to subscribe to a thread and get e-mail updates when replied are posted.

Perhaps we could know that if we had the log file...

We would need full stack traces and code. There shouldnt be a limit, but as this is computing there is always a limit, so its jsut a question of are you doing something crazy. Also this should be in modder support not forge support as its your own code causing the issues.

Feel free, also feel free to come back with some actual useful information and I may take you seriously, but acusations with nothing to back them up or help diagnose/fix are not welcome here. 1) That is always a lie as to make a windows computer run there are HUNDREDS of other processes at all times, and 2) Did I say something else, It may be something in minecraft itself thats pegging your core. You are trying, he was not, he was bitching without providing any useful input. Hence being annoyed -.- This is... interesting... It has the profile information for server thread {'Server Thread'} and the network threads {Netty IO/Netty Client IO}, but not the client thread {'Client Thread'}. The Client thread is where the 'lag' is which means this snapshot is pretty much useless. I need that data But I do notice, that the Chunk IO Thread is taking a infinitesimally small time which is what 'modder99' was claiming caused the issue. Any way I can get you to try profiling again and see if you can get the client thread in the snapshot? Being as thats the important thread. I also notice you have quite a few mods installed, have you reproduced this with JUST Forge and NO other mods?

try with just dev workspace not decomp workspace.

We do not support 1.6.4, you'll have to figure it out on your own protip: this is common search -.-

Let me retstate this so it is abundantly clear. NO We will not 'use the old chunk loading. Your computer can not handle hosting the server and client at the same time. There is nothing we can do about this. There is a slight change that cpw did recently that may fix SOME issues related to it {but not the ones you are seeing} @Belter: For you, if you're pegging at 50% cpu that means that 4 f your cores are being pegged {considering you're a 8-logical, 4 physical} seems to me you have something that is eating up massive amounts of your cpu. As for 'TCP Connection' being 100% of the cpu time, you're reading the log wrong it's 100% of that threads cpu time, which is the point of a thread. Anyways, I would need the profile information to do any more actual help. This is not a Forge thing unless proven other wise, which you have not. Getting annoyed with it -.-

This is all on your hosts end, we cant really do anything, if you run the server as we install it it will work. It is also possible that the mods are causing the server to crash, it's also possible that there is a monkey in the data center punching your server. We do not know unless we get logs.

You're not posting the FML log as diesieben is saying. Forge does not disable all mobs, obviouly this would not fly and would get immediatly fixed if this did happen. We need your logs, we need your .minecraft folder, all mods, all saves, etc.. 90% of the time it is caused by a mod you installed previously allocating mobs somewhere they should not be and they actually exist, but you just don't 'see' them.

No, this is recursion protection, it is there for a very good reason. And you're saying.. that when you use a specific subset of events that force the state into a small structured method you don't get errors... And when you expand to a larger decoration system you get errors... you dont say... Basically, the point is, if you decorate the same chunk twice you're doing something wrong. No, we're not going to remove this. I know for a fact that it has actually prevented quite a few mods from making it to the market that would break everything.

You followed every tutorial except the one at the top of every page that says POST YOUR DAMN LOG FILES so we can help you. We NEED log files.

This was specifically done BECAUSE we are tightening the coremods down and we DO NOT want people making coremods. Yes you can fuck things up with a AT but a hell of a lot less then with real transformers. And from our research most coremods were just for access transformers. Hence we gave the modders what they want in a restricted manor and will be locking down the other side to make modders behave. Anyways this is going in circles, let me just lay down the final answer: Coremods ARE NOT supported Coremods SHOULD NEVER be made aside from when there is LITERALLY no other option Anyone who makes Coremods will get NO official support from us as they should already know {or be able to do there own research} on how to do things. The plan is to make coremods harder to make/use for both the end users protection, and to discourage there usage which has become to prolific. Note: By 'harder' I mean standard java functionality and practices that any library should have to go through but we don't in MC modding because it's a hacky system. Anyone who DOES make a coremod should have no issue adapting and those who can't should never be making base edits in the first place. Anyways your original question is simple, you should be able to address it yourself. I would also advise you stop using a coremod as you have no real need to. Locking thread.

Maven central doesn't control our servers, nothing was renamed. We will however keep that in mind when we update next to keep our names in line with theirs.

Coremods were created to stop people from editing base classes directly, as a compromise because modders would not stop. Thats it, full stop. Coremods are bad and should always be avoided. Anything a coremod does should be scrutinized and evaluated on if it is necessary. The proper way for situations like this is for one mod in your mod pack to lay claim to 'I am replacing vanilla block X, I am 100% in control of it.' If you have two mods who do that let the player decide which takes precedence. Same concept goes for editing any other mod item, you should always go the route of arbitration and communication with the original author {In vanilla's case PRs to Forge} opposed to injecting your own things. A note: In the future I plan on making it A LOT more of a pain in the ass for the end user/modder to create/use coremods. I'm trying to wipe out all these 1/2 thought through coremods that can be done in cleaner ways. Also combine this with the fact that if you think you are important enough to change vanilla code, you should take the time to research how coremods actually work and what order they are applied in. And how java bytecode works, the fact that you even asked this question shows that you have not. I hold coremodders to a higher standard, because they should know better. No help is given when making coremods.

Do not edit ANY JAR FILES EVER. Seriously, you break shit. We've worked had to make it stupid simple. Anyways, Piekng: Don't bump others threads with rantion guesses, lordgek: Don't just post 'what?' -.- His issue has been addressed correctly by SanAndreas

Neither of those tasks need a coremod, you can replace the rendering model for the entity in an event. And you can replace the spawner tile entity with your own. Coremods should be a LAST resort.

Alright im getting tired of repeating myself, you're to thick to digest anything I am saying. Thread locked.

Your mod does not work on 1.7.10 it's for 1.7.2 as listed in the mods file name -.-