Hey UM me and Eury have been banging out how to use the new opencontainer event and I think we have an implementation you can use as an example.
It's a bit heavy in reflection but should be able to handle most if not all intractable containers
Cool. Maybe once I get updated past that Forge version I'll give it a look. How do you handle little Workbenches and Enchantment Tables?
I'll probably use that hook when possible, but I dunno that it'll cover everything well enough to account for more complex interactive GUI block types, especially when doing different access restrictions at different sizes.
1. tile entity = which we then check the TE's world object to ensure it LB,
if so then we do a distance check to ensure the user is withing 4 blocks then
create a fakePlayer object with the same coords of the TE
2. (workbench, anvil) World ,x ,y ,z = find the world object change the world to Little world, attempt to find coords
if found use them for distance check and if that is satisfied create the fake player
if not found set the fake player coord = real player coords * 8
EDIT: After the world check we set the World OBJ back to realworld just in case it was in the real world
3.(large chest, enderchest) IContainer = This is the complicated one, what we do here is just loop through the IContainer object fields looking for TE or WOrld x y z
And that should handle must containers
EDIT:
oo and if we can't find any fields we just do a check using the fakeplayer at pos = player pos * 8
Howdy UncleMion, I have a few suggestions for the mod that I'd like to show
1. Shrink Rays/Growth Rays, I think it would be pretty cool to implement
2. New biomes, kind of like the big and small world in Super Mario 64, that has mobs of all shapes and sizes.
Or maybe a naturally spawning structure that has like a giant castle in it with a giant zombie in it sort of as a boss.
That's about it. I'd also like to say that you are my favorite modder and I expect great things from you.
Stay Awesome
This changes blocks, worldgen, and items. UM will not do this but when she is satisfied with her work in Gulliver she'll create an api for other modders to add the shrink rays, and areas in the world large/tiny mobs spawn naturaly
1. Tell java to get ALL fields from the open container, this usually includes the following types TileEntity, World + world Coords, or IInventory (which is basicly a class to hold inventory info such as TE or world+ world Coords)
a. We have to do this since the container does not have a default TE, or world + coords varibles in them and we don't necesarly have access to the container classes that mods make.
2. Find Either Tile Entity or world coord
3. Use the information we get to check against our own rules to keep the GUI open (i.e. LB will only stay open within four block distance), Gulliver can check player size and determine proper reach distance from there.
4. If rules check out then set a fakeplayer object that will be directly on top of the containers world location and do a vannila check (this is so if there is added logic for the gui to be open we don't accidentally override them)
5. If we find an IInventory go back to step 2 searching within that IInventory.
BTW UM Glad your not dead lol. Looking forward to playing with Gulliver and LB together in 1.6 ^^ It will be a grand time, We are currently looking into make LB light LVLs to bleed through the LB world like it does in the real world
1. Tell java to get ALL fields from the open container, this usually includes the following types TileEntity, World + world Coords, or IInventory (which is basicly a class to hold inventory info such as TE or world+ world Coords)
a. We have to do this since the container does not have a default TE, or world + coords varibles in them and we don't necesarly have access to the container classes that mods make.
2. Find Either Tile Entity or world coord
3. Use the information we get to check against our own rules to keep the GUI open (i.e. LB will only stay open within four block distance), Gulliver can check player size and determine proper reach distance from there.
4. If rules check out then set a fakeplayer object that will be directly on top of the containers world location and do a vannila check (this is so if there is added logic for the gui to be open we don't accidentally override them)
5. If we find an IInventory go back to step 2 searching within that IInventory.
That makes sense, reflection-checking for a TE, IInventory, or World and 3 int fields in a row. Creating a fakeplayer feels hacky, but I can't think of a better solution off the top of my head that doesn't modify base classes.
One possible remaining issue is with these "displayGui" methods in EntityPlayer: displayGUIEnchantment(), displayGUIAnvil(), and displayGUIWorkbench(). They get passed the block xyz positions (in the LBWorld!) but not a World parameter, so when the GUI's Container object is created, it uses the player's World instead of the block's LBWorld. I got around the problem by adding displayResizedGUIWorkbench() etc. methods to EntityPlayer that take an additional World parameter, so that the Container will have the LBWorld instead of the player's World. How are you guys handling that? Does it seem to matter? (Come to think of it, that issue is pretty much just with Little Blocks and not Gulliver...)
It will definitely be good to have interaction for Little Blocks and/or resized players work with mod-added block types and GUIs, since right now my changes are limited to just the vanilla blocks
That makes sense, reflection-checking for a TE, IInventory, or World and 3 int fields in a row. Creating a fakeplayer feels hacky, but I can't think of a better solution off the top of my head that doesn't modify base classes.
One possible remaining issue is with these "displayGui" methods in EntityPlayer: displayGUIEnchantment(), displayGUIAnvil(), and displayGUIWorkbench(). They get passed the block xyz positions (in the LBWorld!) but not a World parameter, so when the GUI's Container object is created, it uses the player's World instead of the block's LBWorld. I got around the problem by adding displayResizedGUIWorkbench() etc. methods to EntityPlayer that take an additional World parameter, so that the Container will have the LBWorld instead of the player's World. How are you guys handling that? Does it seem to matter? (Come to think of it, that issue is pretty much just with Little Blocks and not Gulliver...)
It will definitely be good to have interaction for Little Blocks and/or resized players work with mod-added block types and GUIs, since right now my changes are limited to just the vanilla blocks
Ah forgot to add in this version
we set the worldObj if it's not LBworld to the relative Littleworld then do the checks, this has been tested with crafting, enchantment tables, anvils
then after the check we set the worldOBJ back just in case it was supposed to be a real world.
Not sure how you'd be able to figure out the access rules for the craftingtable but I geuss we could look to see if gulliver is installed and do the checks you want in our code, or reflectively call a static function that you control.
EDIT:
oo one thing you could do is set the player's entity object pos instead of a fakePlayer but you run the risk of accidentally teleporting them if the code errors.
I wouldn't worry about it UM would have to wait for CPW and Risugami to update and they need to wait for MCP which following twitter. CPW says it's going to be a while, and MCP won't be ready for another week or two
we set the worldObj if it's not LBworld to the relative Littleworld then do the checks, this has been tested with crafting, enchantment tables, anvils
then after the check we set the worldOBJ back just in case it was supposed to be a real world.
Not sure how you'd be able to figure out the access rules for the craftingtable but I geuss we could look to see if gulliver is installed and do the checks you want in our code, or reflectively call a static function that you control.
EDIT:
oo one thing you could do is set the player's entity object pos instead of a fakePlayer but you run the risk of accidentally teleporting them if the code errors.
Okay. Right now Gulliver adjusts the allowed-access range (8m for regular blocks) based on player size, but it also does some particular checks for accessing things like LB Chest - preventing huge players from opening them, not requiring tiny players to hold something pointy, etc. So I'd pretty much always be processing that OpenContainer hook. I may need to do the LB checks in my code, so that yours doesn't process them; I wouldn't mind, since I kinda do that already
I wouldn't worry about it UM would have to wait for CPW and Risugami to update and they need to wait for MCP which following twitter. CPW says it's going to be a while, and MCP won't be ready for another week or two
Yeah, it could be quite some time before anyone is able to update their mods to 1.7, so I'll just stick with the plan of doing 1.6.2 & 1.6.4 updates first.
Hi my name is DragonSlayer86.
With the gulliver mod I cannot put the mushroom in the Brewing Stand anyone know why thanks for your time!
PS. Im using the 1.5.2 version.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYay, mod folder mod!
Forum signatures are so 2012.
Upshot: No, I'm not dead, but I'm too exhausted to respond to suggestions.
Cool. Maybe once I get updated past that Forge version I'll give it a look. How do you handle little Workbenches and Enchantment Tables?
I'll probably use that hook when possible, but I dunno that it'll cover everything well enough to account for more complex interactive GUI block types, especially when doing different access restrictions at different sizes.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumlooking for
1. tile entity = which we then check the TE's world object to ensure it LB,
if so then we do a distance check to ensure the user is withing 4 blocks then
create a fakePlayer object with the same coords of the TE
2. (workbench, anvil) World ,x ,y ,z = find the world object change the world to Little world, attempt to find coords
if found use them for distance check and if that is satisfied create the fake player
if not found set the fake player coord = real player coords * 8
EDIT: After the world check we set the World OBJ back to realworld just in case it was in the real world
3.(large chest, enderchest) IContainer = This is the complicated one, what we do here is just loop through the IContainer object fields looking for TE or WOrld x y z
And that should handle must containers
EDIT:
oo and if we can't find any fields we just do a check using the fakeplayer at pos = player pos * 8
Good Job!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis changes blocks, worldgen, and items. UM will not do this but when she is satisfied with her work in Gulliver she'll create an api for other modders to add the shrink rays, and areas in the world large/tiny mobs spawn naturaly
Could you dumb this down for me, please?
Forum signatures are so 2012.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat we do is...
1. Tell java to get ALL fields from the open container, this usually includes the following types TileEntity, World + world Coords, or IInventory (which is basicly a class to hold inventory info such as TE or world+ world Coords)
a. We have to do this since the container does not have a default TE, or world + coords varibles in them and we don't necesarly have access to the container classes that mods make.
2. Find Either Tile Entity or world coord
3. Use the information we get to check against our own rules to keep the GUI open (i.e. LB will only stay open within four block distance), Gulliver can check player size and determine proper reach distance from there.
4. If rules check out then set a fakeplayer object that will be directly on top of the containers world location and do a vannila check (this is so if there is added logic for the gui to be open we don't accidentally override them)
5. If we find an IInventory go back to step 2 searching within that IInventory.
BTW UM Glad your not dead lol. Looking forward to playing with Gulliver and LB together in 1.6 ^^ It will be a grand time, We are currently looking into make LB light LVLs to bleed through the LB world like it does in the real world
That makes sense, reflection-checking for a TE, IInventory, or World and 3 int fields in a row. Creating a fakeplayer feels hacky, but I can't think of a better solution off the top of my head that doesn't modify base classes.
One possible remaining issue is with these "displayGui" methods in EntityPlayer: displayGUIEnchantment(), displayGUIAnvil(), and displayGUIWorkbench(). They get passed the block xyz positions (in the LBWorld!) but not a World parameter, so when the GUI's Container object is created, it uses the player's World instead of the block's LBWorld. I got around the problem by adding displayResizedGUIWorkbench() etc. methods to EntityPlayer that take an additional World parameter, so that the Container will have the LBWorld instead of the player's World. How are you guys handling that? Does it seem to matter? (Come to think of it, that issue is pretty much just with Little Blocks and not Gulliver...)
It will definitely be good to have interaction for Little Blocks and/or resized players work with mod-added block types and GUIs, since right now my changes are limited to just the vanilla blocks
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAh forgot to add in this version
we set the worldObj if it's not LBworld to the relative Littleworld then do the checks, this has been tested with crafting, enchantment tables, anvils
then after the check we set the worldOBJ back just in case it was supposed to be a real world.
Not sure how you'd be able to figure out the access rules for the craftingtable but I geuss we could look to see if gulliver is installed and do the checks you want in our code, or reflectively call a static function that you control.
EDIT:
oo one thing you could do is set the player's entity object pos instead of a fakePlayer but you run the risk of accidentally teleporting them if the code errors.
Since she's currently updating to 1.6, I assume that update will be released, not skipping it altogether to update to 1.7.
Forum signatures are so 2012.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOkay. Right now Gulliver adjusts the allowed-access range (8m for regular blocks) based on player size, but it also does some particular checks for accessing things like LB Chest - preventing huge players from opening them, not requiring tiny players to hold something pointy, etc. So I'd pretty much always be processing that OpenContainer hook. I may need to do the LB checks in my code, so that yours doesn't process them; I wouldn't mind, since I kinda do that already
Yeah, it could be quite some time before anyone is able to update their mods to 1.7, so I'll just stick with the plan of doing 1.6.2 & 1.6.4 updates first.
With the gulliver mod I cannot put the mushroom in the Brewing Stand anyone know why thanks for your time!
PS. Im using the 1.5.2 version.
I forgive you!
Forum signatures are so 2012.