LexManos

You need to run 1.8 not 1.8.3 you can change your version in the edit profile screen.

There is nothing that needs to be secured on our site. No private information is transferred and if you have a compromised gateway you're screwed beyond that. If you want to you can grab the md5s from our site as it's a normal maven repo, so {URL}.md5 will give you the md5 of most of the files. But again, think about it, Legit Website: "Here is your MD5: 12345" Malicious Website: "Here is your MD5: 54321" For all intents an purposes, and for any user who would actually have the possibility of downloading from a malicious site wouldn't know what a MD5 is. Beyond that For Forge you can compile it yourself if you don't trust the download source. And enabling HTTPS is not a simple task. And not a free task. Beefing up our servers, spending thousands on a cert, and making pages lag for end users all in the non-existent case where they are compromised on a level in which none of our precautions could ever have any effect is not worth it. I've been doing network security for 10 years. Without going into a e-peen measuring contest or flame war just accept that I know what I am talking about. We're going in circles here, the fact that this site is trustworthy and you trust the project is enough security as needed. Any more is false security. If you're concerned about malicious code then don't download mods, you're far more likely to have issues from the millions of random sites that you get the actual mods from. So Closing this as i'm tired of this argument. Please don't presume that you have to explain basic network security/management to me.

It's there. 1337

Every time I hear that I have this run through my head: Its not that simple, it's not me who decides fundamental engine mechanics, it's Mojang. As someone who has a hex core as well, yes it would be nice if Minecraft was a bit more multi-threaded so that it could use all 8 cores {Protip: 100/8 = 12.5 not 13.5} Mojang is SLOWLY working on making it do that, 1.8 moved the networking away from the main thread into there owns so that freed up a lot of processing time. But it's not something Forge, or any other mod loader could do.

Mods need to be designed for threads, there is no magic bullet to make it work, Unless you want to spend 90% of your time re-writing other's mods to make them work this is a fools errand.

Whatever you're using that adds the extra hearts is not using the Forge system. In our system everything knows the height of everything and adjusts itself accordingly.

Why?

Short answer, Humans. You don't have to have my cert to make it appear that you have my cert. TLS means nothing when you control one of the end points. Gateways can be endpoints for all the end user cares. The end user just sees a fancy lock icon on there screen and thinks they are safe. Or beyond that most end users don't even notice the lock at all. I'm not going to get into a argument over the fundamentals of security with you. The fact is that Forge is not a security authority and as such we do not have the ability to give or force modders to use signatures nor do we have the authority to act as a root cert for mods. It's not our place. This is a stupid argument, we have the best we can do on our end to allow you to attempt to verify the file integrity when downloading. For SECURITY you're on your own. Only download from trusted sources.

The simple answer to what you want is a hell no. We're not re-writing the entire game engine to make blocks non-singletons. That would just be crazy. Long answer if depending on how many block states you want to take up your can in theory do whatever you want with them. You'd just be creating every permutation which can get cumbersome. Most things you want already have location sensitive versions you could hook into but there are just some things that cant be localized due to how Minecraft's engine works. So ya, you're not the first one to say 'I WANNA DO EVERYTHING' and programming simply doesn't work like that. It's not magic. Your 'suggestion' is not very well thought through and is not feasible in the Minecraft engine.

BlockPos has nothing to do with your speed issues. Had a second to look at your webpage and your test code. And I found out why your tests were showing 'instant' times for the int version. Simplified it into these 3 lines of code, to see if you can spot the issue: int x = 0; for(; x < 100; x++); for(; x < 100; ); See the problem? The second loop is never run, because the condition is satisfied by the first loop. This is the same case with your 'benchmarks' on your webpage. Point is, it's complicated, but int[] and BlockPos are almost identical. They are both roughly a 12 byte section of memory, they are pushed as pointers on the stack when calling through methods. On any modern system there field access times are almost identical. Last time I looked at the machine code generated for native field access it was a simple memory pointer. The reason 1.8 is different then 1.7 is cuz a lot of shit related to rendering has changed. A lot of shit related to a lot of things has changed. The rendering changes arnt the best, could be a bit more performant on some systems, however, OVERALL it's a bit of improvement on the average system. It is also a MAJOR benefit to the flexibility and functionality of the renderer {it's mojang so nothing is ever complete, but its a big step in the right direction} So, basically what you should do is learn how to digest a flight recorder log, or jprofiler. Dig around and see where, for you, the game is eating up time and see if you can find a clue to what could be fixed. There will not be any 'magic bullet', there is no way you can put everything on BlockPos's shoulders just doesn't fly. Everyone likes to throw out big numbers and complain about object churn. BlockPos is the EXACT type of Object Churn the JVM LOVES and is specifically designed to deal with without breaking a sweat. So ya, basically, BlockPos isn't your prolem, and it's not as bad as everyone makes it out to be. There is no need for Forge to re-write everything in Minecraft because people THINK they are bad.

Some mob you have in the world is not registered correctly and is trying to spawn on the client without the client knowing what it is. Make sure your mod configs are properly synced between your client and your server.

Update Forge this was fixed weeks ago.

The optifine people who started the smear campaign against BlockPos are not worth listening to. Tho your page is interesting it's not something I didn't already know. Your timing system is also off a bit. It doesn't take into account some of the eccentricities of how the jvm class system works. However, it is definitly not worth it to re-write the entire Minecraft codebase to do it. I've toyed with the idea of writing a generic class transformer that attempts to translate the use of BlockPos to ints at runtime but couldn't get anything that was worth the effort. It's all a balance of how much do I want to edit the core Minecraft engine. How much work in development and future support will I need to do for it. What impact it has on modder usability. vs What is the actual performance benefits are. And in this equation it's costs far outweigh its benefits. Unless someone can come up with a magic solution I don't see forge doing anything this radical.

If you have been compromised at that level you're fucked anyways and downloading mods is the LEAST of your concerns, so It's not really a valid argument. Either way when it comes to that there is no countermeasure around it. Self-signed certs can be forged, pages can be injected, files can be modified. There isn't anything you can do, and if you do have ideas explain them and I could probably come through and explain to you why they are not valid.

Sadly these errors are extremely hard to detect. Something in one of the mods you are running is not respecting threads correctly. Looks like something to do with unloading chunks. I would look into any mods you have installed that add chunk loaders.

HTTPS does nothing. Embedded md5s do nothing. The new downloads page Overmind is working on however will list the md5s/sha1s for downloads how this must be made clear that this is for corruption detection only as those md5s are only as good as the site they come from. Only thing you can really do is have a trusted source and only ever use that source. If that source also proides md5s then yay, but that's not security. Another possibility we are trying to push modders twards i SIGNING THEIR BUILT JARS. And when that becomes more popular I plan on doing a very basic USER CONTROLLED keystore/trust thing. Not sure how to work it out yet but thats the plan. TLDR: Only download from trusted sources.

Dev is binary Decomp is source

We do not touch mod ore gen at all. You have to configure that in the mods themselves.

Good good, now next time trust me when I say its your code and not ours, it's almost like I know what i'm talking about <3

You forget the part where I also said I don't have time to debug it for you. Should be simple and straightforward something is causing one of your entities to spawn. Hell you could even set a breakpoint in the spawn packet send function to see what is causing it on the server. This is basic level debugging stuff you should know how to do.

As stated, vanilla minecraft mobs do not run through the code that is erroring. You have something in your mod that is causing this. Wither works just fine on Forge alone. I don't have your code, and I don't have time to debug it for you. So I can't really do anything for you besides say something in your code is broken. Start disabling parts of you mod and figure out what.

That is a jar mod it does not work with forge, go ask the modder to make it compatible or don't use the mod.

One of the entities you're adding to the game and spawning is not spawning correctly. Oddly its not giving the error but its catching a error when trying to call that entitie's constructor. This should have nothing to do with the wither as that goes through normal spawning mechanics not the mod mechanics.

Sadly no, we officially do not support that old of a version. We will not be fixing any bugs that happen on that old version so we can't support it.

Just dont install 1.8.1/1.8.2...