Before calling "ItemStack.tryPlaceItemInWorld", a recording flag is turned on for
setBlock to capture a blocksnapshot for each block that attempts to be placed.
If 1 block is captured, a "BlockEvent.PlaceEvent" is fired to notify mods.
If 2 or more blocks are captured, a "BlockEvent.PlaceEvent" is fired first with the first block
captured followed by a "BlockEvent.MultiPlaceEvent" with all captured blocks. This extra event
is required for items that have the ability to place 2 or more blocks such as a BlockBed.
If either event is cancelled, the recorded block snapshot(s), item stacksize, and item meta will
revert back to the captured snapshot(s).
If the events are not cancelled, a notification will be sent to clients and block physics will be updated.
What this means for mods is Forge will be able to capture all player block placement automatically and fire
a PlaceEvent and/or MultiPlaceEvent.
If for whatever reason your mod does not use the standard placement methods then you will need to fire the
appropriate placement events in order to notify mods/servers.
This commit also includes a new utility class called BlockSnapshot which is serializable. This new class is used in conjunction with
both PlaceEvent and MultiPlaceEvent in order to record a snapshot of block space before it is altered. This
allows us to restore the block(s) if an event is cancelled. The class also provides the ability to restore a snapshot
to any location using the restoreToLocation method. This should be helpful to many mods that are looking to be able
to capture block data then restore it to back to any location required.
MinecraftForge/FML@cbe2ccbda4 Add in ModType to the jar manifest. If it's present, and doesn't have value "FML" it will be skipped from the modloading cycle. This should let liteloader mods have a .jar extension.
MinecraftForge/FML@37cf0174fc OK, lets make that a csv list. It'll let you be liteloader and fml in one jar file!
MinecraftForge/FML@0475b15eb1 Change the mods and modListFile argument handling a bit. Other tweakers will get a chance at looking at them now - they're only removed right before launch.
MinecraftForge/FML@abeac06a2e Two new features. ModLists can have a "parent" mod list. Circularity will result in a crash, so be careful. Mods specified in a child will override ones from a parent (using the maven group:name:classifier triple to identify - ignoring the version component)
MinecraftForge/FML@7fcfedcfef Canonicalized file paths in modListFile handling with the minecraftDirectory.
MinecraftForge/FML@633fce19d4 Make Keyevent also fire for key releases
MinecraftForge/FML@57ba2339b6 Merge branch 'keyup-event' of github.com:diesieben07/FML
MinecraftForge/FML@1ff048062c Merge branch 'simple-netw-improve' of github.com:diesieben07/FML
might see two TEs for a single setblock where previously you saw one. This is a phantom TE being created by badly written neighbour triggers - I'm looking at you
redstone.
Anyway, with luck, this'll close a slew of bugs across Forge, IC2, MFR, TE, RC. Yeah, fun times. Thanks to LexManos, skyboy and KingLemming for helping figure this
issue out. Quite frankly, from now on, issues with phantom TEs will be mods behaving badly. Modders will need to adapt.
* Added ability to AnvilUpdateEvent to alter stackSizeToBeUsedInRepair (vanilla behavior is now reproducable)
* Added AnvilRepairEvent, fired when the player removes an ItemStack from the output slot of ContainerRepair, and allows the chance to damage the anvil to be altered.
MinecraftForge/FML@ab52901b8b Force preferIPv4Stack to true early in the load chain to combat netty loopback issues.
MinecraftForge/FML@11893fbbb7 Add system property to skip doing world backups when game registry changes. This is SEVERLY ill-advised, if you do this DO NOT ask for any support.
MinecraftForge/FML@fdb6b34b8f Update authlib and realms to latest json data.
MinecraftForge/FML@b3a74882b4 added slider controls for numerics. default control is textbox, but slider can be used as a custom list entry class. fixed constructor javadocs in GuiConfig
MinecraftForge/FML@7c6d1f7568 Merge pull request #468 from bspkrs/master
MinecraftForge/FML@692d955c1a Update tweaker login to use authlib.
MinecraftForge/FML@c2119eb1c1 Update realms library to 1.3.1, and implement network latch when connecting to Realms. Tested and working.
Adds a Forge event which controls whether an overlay is rendered.
Overlays include: First-person fire, Block (when inside a block)
and water when a player is inside a water block.
Patched for easier manipulation of event
Fixed for Lex
To be squashed
Removed Contructor
Added block XYZ parameters
TODO, the second block overlay event’s XYZ might not be correct
MinecraftForge/FML@7219061b05 Also patch in warnings for Vec3Pool - similarly removed.
MinecraftForge/FML@dff2204558 FML now sets a security manager (FINALLY!). It's primary purpose at this point is to catch rogue calls to System.exit so that they can cause a proper crash report, rather than silently abandoning the game.
When a player triggers a chunk load via walking around or teleporting
there is no need to stop everything and get this chunk on the main thread.
The client is used to having to wait some time for this chunk and the
server doesn't immediately do anything with it except send it to the
player. At the same time chunk loading is the last major source of file IO
that still runs on the main thread.
These two facts make it possible to offload chunks loaded for this reason
to another thread. However, not all parts of chunk loading can happen off
the main thread. For this we use the new AsynchronousExecutor system to
split chunk loading in to three pieces. The first is loading data from
disk, decompressing it, and parsing it in to an NBT structure. The second
piece is creating entities and tile entities in the chunk and adding them
to the world, this is still done on the main thread. The third piece is
informing everyone who requested a chunk load that the load is finished.
For this we register callbacks and then run them on the main thread once
the previous two stages are finished.
There are still cases where a chunk is needed immediately and these will
still trigger chunk loading entirely on the main thread. The most obvious
case is plugins using the API to request a chunk load. We also must load
the chunk immediately when something in the world tries to access it. In
these cases we ignore any possibly pending or in progress chunk loading
that is happening asynchronously as we will have the chunk loaded by the
time they are finished.
The hope is that overall this system will result in less CPU time and
pauses due to blocking file IO on the main thread thus giving more
consistent performance. Testing so far has shown that this also speeds up
chunk loading client side although some of this is likely to be because
we are sending less chunks at once for the client to process.
Thanks for ammaraskar for help with the implementation of this feature.
This commit is based off the following :
Bukkit/CraftBukkit@b8fc6ab2c1Bukkit/CraftBukkit@85f5776df2Bukkit/CraftBukkit@0714971ca2Bukkit/CraftBukkit@7f49722f45Bukkit/CraftBukkit@53ad0cf1ab
Fixes issue with biome decoration crashing on worlds with exposed void
Fixes same issue in JungleBiome decoration
Fixes forge bug in getting lighting from a block in chunk
