Recent Events Discussion (RED) Thread

Strikingwolf

New Member
Jul 29, 2019
3,709
-26
1
From what I understand - with forge, if a mod author needs to something that forge can't do, they can submit a pull request and it'll be added. This won't be possible with an official api, and so Forge will probably still be required for anything beyond very basic mods.
More than that, we can access the very source code of MC itself. Forge basically decompiles MC for us modders to mess around with and provides some API sugar on top of that. Forge Mod Loader just takes that and loads them in a compatible way
 

NJM1564

New Member
Jul 29, 2019
2,348
-1
0
There's been talk of this "API" for years, I wouldn't hold my breath on it coming any time soon. I was always under the impression that it's actually the obfuscation that's the biggest pain with updating everything, but I'm not a modder so I really don't know.

From what I understand - with forge, if a mod author needs to something that forge can't do, they can submit a pull request and it'll be added. This won't be possible with an official api, and so Forge will probably still be required for anything beyond very basic mods.

That's true. But the point isn't that the API is supposed to a do everything code for moders. It's a hunk of code that moders can hook into that will never change. So minecraft can update vanilla with out effecting mod devs at all.
So there won't be 1.7 mods and 1.8 mods but just mods. And that way mod deves would never need to update there mods unless they have bugs to fix or want to change/add something.
 

keybounce

New Member
Jul 29, 2019
1,925
0
0
From what I understand - with forge, if a mod author needs to something that forge can't do, they can submit a pull request and it'll be added. This won't be possible with an official api, and so Forge will probably still be required for anything beyond very basic mods.

It's more accurate to say that if you need something forge doesn't do, you can submit a pull request.

Whether or not it will be added is entirely separate.

Just as an example, it is highly unlikely that anything will be added to 1.7.10 at this point.
 

VapourDrive

New Member
Jul 29, 2019
536
-8
1
So I have been posting some sneak peeks in the whats new news thread, nothing much, just pictures in spoilers... is this bothering anyone? It's not technically legit news but I figured it's non-intrusive enough. I'll keep doing it if people enjoy a bit of a preview for upcoming things.
 

NJM1564

New Member
Jul 29, 2019
2,348
-1
0
So I have been posting some sneak peeks in the whats new news thread, nothing much, just pictures in spoilers... is this bothering anyone? It's not technically legit news but I figured it's non-intrusive enough. I'll keep doing it if people enjoy a bit of a preview for upcoming things.

I don't mind but some context would be nice. Are they spoilers for a new mod or for an update to an existing one?
 

Qazplm601

Lord of the Tumbleweeds
Sep 21, 2013
2,754
3,282
308
Where else?
Don't go out there. Mobs spawn in the wild and not in a controlled mob spawn/grinder vacility. Testificates are allowed to run free around little huts they call villages. Also don't forget the rain, always the rain.
i solved the mob problem by name tagging a bunch and shoving them in a chunkloaded cage under my base. it works(usually) this was a while ago tho, i bet it was fixed or something :p
 
  • Like
Reactions: VapourDrive

HeilMewTwo

New Member
Jul 29, 2019
1,179
-45
0
So skyboy found something interesting in minecraft's code: IRC Log

If you are interested, here is the method causing the issue (The problem occurs on line 25): Pastebin

More technical description of issue:
Basically the method I have linked in the pastebin will check if the number of tiles that need to update is equal to 64. If it is equal to 64, use this method that sends data related to tiles that are in the y-levels the player will see. If it is anything else (above or below) then use this method that sends data for every tile (even underground). In 1.6 instead of it only being 64 it would send only needed tiles if the number of tiles was 64 or greater and send all if it was less.

I should also point out that net.minecraftforge.common.ForgeModContainer.clumpingThreshold is equal to 64
So as a result skyboy has put a fix into the latest CoFHCore which patches this method. The latest update can be downloaded here

http://minecraft.curseforge.com/mc-mods/69162-cofhcore/files/2222240
Wow... 0_o
 
  • Like
Reactions: Equitime

LivingAngryCheese

Over-Achiever
Aug 22, 2014
676
1,580
228
A place
So skyboy found something interesting in minecraft's code: IRC Log

If you are interested, here is the method causing the issue (The problem occurs on line 25): Pastebin

More technical description of issue:
The method I have linked in the pastebin will check if the number of tiles that need to update is 64. If it is equal to 64, use this method that sends data related to tiles that are in the y-levels the player will see. If it is anything else (above or below) then use this method that sends data for every tile (even underground). In 1.6 instead of it only being 64 it would send only needed tiles if the number of tiles was 64 or greater and send all if it was less.

The problem is that in 1.7 pretty much every time it will send data for every single tile to the client regardless of whether it is visible. Even if there are 4000 or so tiles. The intended method is to reduce the amount of tiles we need to update by only updating tiles that are in a given range of y values. However since mojang used == (equal to) instead of >= (greater than or equal to) we get the terrible worldgen lag

I should also point out that net.minecraftforge.common.ForgeModContainer.clumpingThreshold which you see in line 25 of that pastebin is equal to 64
So as a result skyboy has put a fix into the latest CoFHCore which patches this method. The latest update can be downloaded here

http://minecraft.curseforge.com/mc-mods/69162-cofhcore/files/2222240
He could have not wasted his time. This issue has been spoken about, that is why it was fixed in 1.8, however if he can solve it for 1.7 that is good.
 

NJM1564

New Member
Jul 29, 2019
2,348
-1
0
So skyboy found something interesting in minecraft's code: IRC Log

If you are interested, here is the method causing the issue (The problem occurs on line 25): Pastebin

More technical description of issue:
The method I have linked in the pastebin will check if the number of tiles that need to update is 64. If it is equal to 64, use this method that sends data related to tiles that are in the y-levels the player will see. If it is anything else (above or below) then use this method that sends data for every tile (even underground). In 1.6 instead of it only being 64 it would send only needed tiles if the number of tiles was 64 or greater and send all if it was less.

The problem is that in 1.7 pretty much every time it will send data for every single tile to the client regardless of whether it is visible. Even if there are 4000 or so tiles. The intended method is to reduce the amount of tiles we need to update by only updating tiles that are in a given range of y values. However since mojang used == (equal to) instead of >= (greater than or equal to) we get the terrible worldgen lag

I should also point out that net.minecraftforge.common.ForgeModContainer.clumpingThreshold which you see in line 25 of that pastebin is equal to 64
So as a result skyboy has put a fix into the latest CoFHCore which patches this method. The latest update can be downloaded here

http://minecraft.curseforge.com/mc-mods/69162-cofhcore/files/2222240

3 cheers for skyboy. Hip hip...
 
  • Like
Reactions: SynfulChaot

VikeStep

New Member
Jul 29, 2019
1,117
0
0
He could have not wasted his time. This issue has been spoken about, that is why it was fixed in 1.8, however if he can solve it for 1.7 that is good.
I just double checked, the bug is still in 1.8. Maybe you are thinking of another bug, but this is the first time it has been seen