Jump to content

IceMetalPunk

Members
  • Posts

    402
  • Joined

  • Last visited

Posts posted by IceMetalPunk

  1. Just now, larsgerrits said:

    Store the Field instance in a static field somewhere. Calling Field#get will pretty much be the same as normal field access performance wise.

    So... cache it, like I said? XD The actual reflective call is only happening once in that case, which is why it's fast. But if you were to call the reflection access methods as often as you'd otherwise call a field name, the performance drops significantly.

  2. On 6/26/2018 at 2:20 PM, pr0racing said:

    Being a first time developer for MC, should I just wait for 1.13 to drop to continue programming my idea since there is going to be a fundamental change to how items are handled? I've got about 3 years of Java under my belt already so it isn't a familiarity with coding that has me worried, but familiarity with the libraries and how things work with forge.

    100% wait. The fundamentals of the Minecraft codebase have changed quite a bit; as such, the Forge layer on top of it will need to change drastically. I'm almost certain that even those of us who have been using Forge for awhile will have to "re-learn" the 1.13 structure, as it were. So you may as well wait until then to start learning so you don't have to start all over :)

    • Like 3
  3. Mods always need to be updated to work with new versions, because they depend upon bits of the Minecraft source code, and the Minecraft source code changes with each update. It's rare to have none of Mojang's changes affect your mod. But even more than that, don't forget: before Minecraft 1.13 was the Update Aquatic, it was first the Technical Update. It used to be that 1.13 was the Technical Update, and 1.14 was the Update Aquatic. But then the two updates got merged into one, blah blah blah, and now here we are.

    I mention all this because the Technical Update, as its name suggested, changed a lot of the core Minecraft code, more than usual. The command system was totally rewritten, so any mods that added or used commands will break from that alone. But even worse (better?), the Flattening happened. Block and item IDs were removed. Block data values were removed. All identifiers are now strings, and all extra block data that doesn't require processing is now a block state with no backwards compatibility for numerical metadata. (I mean, to be fair, it's been 5 versions since block states were introduced, so it's about time the transitional period ended.) Which means any mod that adds, removes, or interacts with blocks or items must be updated.

    So unless you have a mod that does nothing with commands, blocks, or items, you're guaranteed to have to update it. And there's no promise that even if you have such a limited mod, you won't have to update, because there are many more changes under the hood than what I've mentioned (for instance, item entities now behave differently, too, so some entity code would need to change as well!).

    • Like 1
  4. I've been working on a 1.12.2 mod for about 6 months, on occasion. For some reason, I never put it in a repository. Why? I don't know. I was a fool.

    So this past Monday, I decided it should be in a repo, finally. I was almost done with it, too; just a few more features to add and it would be ready for release. So I set up the repo, and then... I mixed up two commands and accidentally perma-deleted the entire project. Before the first commit. I even tried a file recovery tool, and it was just gone. Disappeared forever into the ether.

    Now, I'm taking this as a sign that I should just wait for Forge for 1.13 and start over fresh. But man, watching those files disappear unexpectedly (literally: I had the folder open in Explorer behind the terminal, and I saw them disappear)... that was the most disheartening thing I've ever seen. Six months of work, all for nothing...

    So what I'm saying is this: I needed to vent about it, and I need someone to hold me so I can cry on their shoulder :( *Sigh* At least I learned my lesson: I will never start a project until the repo is set up first >_<

  5. A tile entity is the most flexible way. However, if you're only storing 4 or fewer types of liquid, you can simply use block states. Create a block state property that's an enum of the types of liquids you want to store (lava, water, etc.). Give them each a unique index starting at 4 and counting up. Then, assuming you're still using the same LEVEL property from the vanilla cauldron (an integer from 0 to 3), you can calculate the metadata as level | type.getIndex() and you can get the type back from the metadata by doing simply metadata & 12 to get the index of the type (again, they should start at 4). And of course, you can get the level back from the metadata by doing metadata & 3.

    If you're storing more than 4 types of liquid, or going beyond the vanilla 3-level system, you'll need that tile entity.

  6. Also, it may be better to use the ReflectionHelper class; that allows you to specify multiple field names (i.e. the deobfuscated one, the SRG name, and the Notch name) and the first one found will be used. Which means you can test the same code you build with and they'll both work :)

  7. 33 minutes ago, diesieben07 said:

    Then you are doing something wrong here... PlayerLoggedInEvent is definitely server-side only. Please show updated code if you still have an issue with this.

    I haven't been using any version control (I know, shame on me; this was meant to be a small hobby project!), so that code is gone now. But I tried to reproduce it from memory to post here, and... my reproduced code works with that event >_< (Or at least, it has the right seed; I haven't tested it with the rendering aspect yet.) So either I'm going crazy, or I had a stupid mistake in my original code that I missed, or the entire problem was a multithreaded race condition the whole time and now that that's fixed the proper event works as expected.

    Either way, I'll switch back to using the PlayerLoggedInEvent and do another full test. *Sigh* Heisenbugs are a pain...

    *EDIT* And it works perfectly. Because of course it does. Now I get to mark this topic as solved accurately this time. Thank you to everyone who helped!

  8. 10 minutes ago, diesieben07 said:

    PlayerLoggedInEvent is fine. It only fires on the server (unless you meant "dedicated server", in which case: you should not care about whether you run in single player or on a dedicated server). However you also need to send the seed again in PlayerChangedDimensionEvent and PlayerRespawnEvent.

    Um, no? I didn't mean dedicated server; I was testing in a single player world on the client build. The server world has the proper seed, but when I use the PlayerLoggedInEvent, the message is only being sent from the client (as evidenced by the fact that the code which sends the message outputs a seed of 0 before sending the message).

    Quote

    What you are observing is (I think) threads being weird because you are not properly synchronizing. If you write to a field from more than one thread without any synchronization guards in place, basically anything can happen. Message handlers are by default ran on the networking thread, not the main client thread. Read the warning in the documentation.

    Ah, I guess that's a possibility. I'll try changing it to a scheduled task and seeing if that fixes anything. Thanks!

  9. 48 minutes ago, Draco18s said:

    But vanilla doesn't do that, so it doesn't need the seed, so it doesn't synchronize it.

    Which is why I said " Other than 'because vanilla Minecraft hasn't needed it yet'...". It just seems like a lack of foresight on the devs' part to not sync an identifying bit of data, that's all. An ounce of prevention and all that.

    On another note, I tried switching from the PlayerLoggedInEvent to the ServerConnectionFromClientEvent. On the bright side, this one does seem to fire only on the server. On the downside, it also fires before the entity passed to it exists (or something like that -- it errors when sendTo is called there, without crashing, giving an NPE in the FMLOutboundHandler$selectNetworks method when trying to get the supplied player's dispatcher; the player entity itself is a valid EntityPlayerMP representing the player).

    So now I'm at a loss as to where to go from here. I can't send messages at all with the ServerConnectionFromClientEvent, but the PlayerLoggedInEvent only fires on the client. So where do I send a message from the server to a newly-connected client?

     

    *EDIT* Well, it looks like I finally got the message part working. I'm using the EntityJoinWorldEvent. It seems like this would be much less efficient than it needs to be, as it fires for every entity and then checks if it's a player, and it still fires and runs every time the player respawns, changes dimensions, etc. But at least it works, I guess. Now I'm just going to update the block code to use the ServerData for the seed, and if that works, I guess this thread will actually be solved then.

     

    *EDIT 2* It's so weird... it worked. Once. And now it doesn't work anymore. I don't understand...

    HandleEvents.serverData is the static instance of the ServerData class (child of WorldSavedData). Here's the code I have in my message handler:
     

    public class ServerSeedMessageHandler implements IMessageHandler<MessageServerSeed, IMessage> {
    
    	@Override
    	public IMessage onMessage(MessageServerSeed message, MessageContext ctx) {
    		HandleEvents.serverData.setSeed(message.getSeed());
    		System.out.println("Received message with seed " + message.getSeed() + " on side " + ctx.side);
    		System.out.println("The new seed is " + HandleEvents.serverData.getSeed());
    		return null;
    	}
    
    }

    And here's the corresponding output, which looks perfectly correct:
     

    Quote

    [00:56:56] [Netty Local Client IO #0/INFO] [STDOUT]: [com.icemetalpunk.microaesthetics.data.ServerSeedMessageHandler:onMessage:14]: Received message with seed -5415528417089611098 on side CLIENT
    [00:56:56] [Netty Local Client IO #0/INFO] [STDOUT]: [com.icemetalpunk.microaesthetics.data.ServerSeedMessageHandler:onMessage:15]: The new seed is -5415528417089611098

    So the client-side is getting the proper seed, and it's setting the serverData' seed to that value. Great!

    And yet... here's the new code in the randomDisplayTick() method of the block:
     

    	@Override
    	@SideOnly(Side.CLIENT)
    	public void randomDisplayTick(IBlockState stateIn, World worldIn, BlockPos pos, Random rand) {
    
    		Material material = worldIn.getBlockState(pos.down()).getMaterial();
    		double d0 = pos.getX();
    		double d1 = pos.getY();
    		double d2 = pos.getZ();
    
    		Chunk chunk = worldIn.getChunkFromBlockCoords(pos);
    		long seed = HandleEvents.serverData.getSeed();
    		Random slimeChunkRNG = new Random(seed + (long) (chunk.x * chunk.x * 4987142) + (long) (chunk.x * 5947611)
    				+ (long) (chunk.z * chunk.z) * 4392871L + (long) (chunk.z * 389711) ^ 987234911L);
    		int slimeChunkCheck = slimeChunkRNG.nextInt(10);
    
    		if (pos.getX() == -73 && pos.getY() == 38 && pos.getZ() == -8) {
    			System.out.println("Seed: " + seed);
    			System.out.println("Result: " + slimeChunkCheck);
    		}
    
    		if (slimeChunkCheck == 0 && worldIn.rand.nextInt(10) == 1 && d1 <= 40.0d && material == Material.AIR) {
    			double d3 = d0 + (double) rand.nextFloat();
    			double d5 = d1;
    			double d7 = d2 + (double) rand.nextFloat();
    			Particle part = new ParticleSlimeDrip(worldIn, d3, d5, d7);
    			Minecraft.getMinecraft().effectRenderer.addEffect(part);
    		}
    	}

    And here is the (extremely frustrating) log output from this:

    Quote

    [00:56:59] [main/INFO] [STDOUT]: [com.icemetalpunk.microaesthetics.blocks.BlockSlimeChunkStone:randomDisplayTick:46]: Seed: 0
    [00:56:59] [main/INFO] [STDOUT]: [com.icemetalpunk.microaesthetics.blocks.BlockSlimeChunkStone:randomDisplayTick:47]: Result: 9

     

    So can someone please explain to me why, according to the message handler, the static serverData instance on the client has a proper seed, but when the randomDisplayTick() method queries that static serverData (on the client side) for its seed -- using the SAME METHOD as the debug output in the message handler -- it's getting 0?

    I literally have nowhere else I'm calling serverData.setSeed(), and the only place I instantiate serverData is in the WorldEvent.Load event handler, which occurs before the message is even sent (which is, of course, on the EntityJoinWorldEvent for EntityPlayerMP types).

    I'm so confused.

  10. 35 minutes ago, Draco18s said:

    You basically just need to do it once (when the player joins the world) and store it.

    Every block can then query that stored seed.

     

    And yes, you need to do this, because how else would you get the data when the player connects to a server?

    I understand *why* it's required, where I'm on the fence is in understanding why the seed, which is integral to the identity of a world, is not already synchronized between both copies of the world. Other than "because vanilla Minecraft hasn't needed it yet"...

    Anyway, I'm having an issue implementing this solution. I was under the impression that the PlayerLoggedInEvent fired on the server when a client connected. But instead, it seems to be firing on the client when it connects. This means the client, whose initial world seed is 0, is sending a message to itself saying to set the world seed cache to 0. Clearly, that doesn't work. Should I be using a different event (and if so, what? There doesn't seem to be anything else like ClientConnectEvent or something)?

    Here's the current code I'm using (this.serverData is an instance of ServerData, which extends WorldSavedData):

     

    	@SubscribeEvent
    	public void startSever(WorldEvent.Load ev) {
    		World world = ev.getWorld();
    		this.serverData = ServerData.get(world, world.getSeed());
    		System.out.println("Setting server data: " + this.serverData.getSeed());
    	}
    
    	@SubscribeEvent
    	public void clientConnect(PlayerLoggedInEvent ev) {
    		if (ev.player instanceof EntityPlayerMP) {
    			MessageServerSeed message = new MessageServerSeed(this.serverData.getSeed());
    			System.out.println("Sending message: " + message.getSeed());
    			Microaesthetics.NETWORK.sendTo(message, (EntityPlayerMP) ev.player);
    		}
    	}

     

    The output shows that the proper world seed is getting set on the server, and 0's are getting set on the client -- which is expected. But it's also showing that the only message being sent is from the client -- i.e. it's sent after the client sets its seed to 0 instead of after the server sets its seed properly -- which is the opposite of what I want. (Note: the message handling works just fine, the message gets sent and the handler calls its onMessage method properly and has a valid MessageServerSeed passed to it -- that message just has a seed of 0 because it's only sent from the client, which has a seed of 0.)

    So if PlayerLoggedInEvent fires only on the client, what's the equivalent event that fires on the server when a new client connects?

  11. 15 hours ago, diesieben07 said:

    You send the server seed over using a custom packet.

    Oh... so I need to add a message class, a message handler, and an event handler that sends the message (and possibly a WorldSavedData class? What's the best way to save the seed on the client?)... all just to get one number that defines the world into the world on the client side? That seems overly elaborate... but if I have no other choice, then I guess I'll get to work...

  12. 51 minutes ago, diesieben07 said:

    No, what you are doing is known as reaching across logical sides and it is a very bad idea. This will crash as soon as you play on a server and it will cause random inexplicable crashes during normal single player gameplay.

    In that case, what is the best way to actually achieve this? The randomDisplayTick() method has to be client-side only, but the client world doesn't actually have a seed to use to detect slime chunks. So how do I determine whether the place I'm trying to render is a slime chunk or not if I can't access the server's seed?

  13. AHA! After a little research, I've managed to get it all working. I'm using the DimensionManager to get the server World instance for the current dimension based on the client World passed to the randomDisplayTick() method. I don't know if this is the "proper" or "best" way to achieve this, but it works! :D

    Here's the final, working code (which may be updated later to only apply to the overworld, depending on how it behaves in other dimensions):

     

    @Override
    	@SideOnly(Side.CLIENT)
    	public void randomDisplayTick(IBlockState stateIn, World worldIn, BlockPos pos, Random rand) {
    		Material material = worldIn.getBlockState(pos.down()).getMaterial();
    		double d0 = pos.getX();
    		double d1 = pos.getY();
    		double d2 = pos.getZ();
    
    		WorldServer server = DimensionManager.getWorld(worldIn.provider.getDimension());
    
    		Chunk chunk = server.getChunkFromBlockCoords(pos);
    		int slimeChunkCheck = chunk.getRandomWithSeed(987234911L).nextInt(10);
    		if (slimeChunkCheck == 0 && worldIn.rand.nextInt(2) == 1 && d1 <= 40.0d && material == Material.AIR) {
    			double d3 = d0 + (double) rand.nextFloat();
    			double d5 = d1;
    			double d7 = d2 + (double) rand.nextFloat();
    			Particle part = new ParticleSlimeDrip(worldIn, d3, d5, d7);
    			Minecraft.getMinecraft().effectRenderer.addEffect(part);
    		}
    	}

     

  14. 23 hours ago, Draco18s said:

    This is what clever programmers are for.

    if(pos.x == N && pos.z == M && pos.y == 39) { log.message("hey! listen!"); }

    Hm... I suppose I could do that xD I feel a little weird hardcoding coordinates like that, but I guess that's ridiculous since it's only for temporary debugging, isn't it? Habits are forceful things...

    Aaaannnddd the problem is discovered: the result is 9, so it's not a slime chunk. Wonderful. But that leads me to another question: what's the most reliable way to find a slime chunk for testing this feature? Clearly ChunkBase is inaccurate, and flying around looking for one could be unbounded in time... I suppose I could pick an arbitrary x coordinate and then solve the equation for z? Is there an easier way (since having a list of slime chunks would provide much easier testing than just one at a time)? (EDIT: Yeah, reverse the Random class's methods, that was a genius idea xD )

     

    *EDIT* Or, of course, just iterate in multiples of 16 across (x,z) coordinates and check for each, which I suppose may be easier, though a bit brute force?

    *EDIT 2* I am now thoroughly confused. I did it the brute-force way and, on the WorldEvent.Load, generated a list of all (x,z) values which produced 0 for the getRandomWithSeed call. One of those is, in fact, (-80, -16) like ChunkBase said. Yet when I go to that coordinate, there are no particles; and when I check the output from the randomDisplayTick() method's call, it's still 9!

    Does the client have a different seed than the server or something? Why is it always 9, even when a brute-force check on world load showed those coordinates to produce a value of 0 for the same function calls?

     

    *EDIT 3* Well, testing this found... the client's seed is always 0, regardless of what the server's seed is. So how do I get the proper seed in the randomDisplayTick(), which is client-only? Or is there another way to figure out, in the client-side display tick method, if I'm displaying in a slime chunk or not?

  15. 27 minutes ago, Draco18s said:

    Add a logging statement to tell you what the output of that method is.

    The issue there is that this class is being registered to replace the vanilla stone block. If I make it give any console output, I'll be getting output from every loaded stone block in the world, which would be impossible to sift through for the proper blocks.

  16. I have a block which spawns some custom particles below it. The idea is that it should show slime dripping in slime chunks under Y=40. I got all the particle spawning and rendering to work, but as soon as I add the check for if it's a slime chunk... no particles spawn. I've put the world seed into an online Slime Finder (the ChunkBase one) to verify I'm in a slime chunk, and according to that web app, I am. But no particles. If I remove the one condition that checks for slime chunks? Then it properly spawn particles at all such blocks under Y=40.

    Here's the relevant code in the block's class:

     

    @Override
    	@SideOnly(Side.CLIENT)
    	public void randomDisplayTick(IBlockState stateIn, World worldIn, BlockPos pos, Random rand) {
    		Material material = worldIn.getBlockState(pos.down()).getMaterial();
    		double d0 = pos.getX();
    		double d1 = pos.getY();
    		double d2 = pos.getZ();
    
    		Chunk chunk = worldIn.getChunkFromBlockCoords(pos);
    
    		if (chunk.getRandomWithSeed(987234911L).nextInt(10) == 0 && worldIn.rand.nextInt(2) == 1 && d1 <= 40.0d
    				&& material == Material.AIR) {
    			double d3 = d0 + (double) rand.nextFloat();
    			double d5 = d1;
    			double d7 = d2 + (double) rand.nextFloat();
    			Particle part = new ParticleSlimeDrip(worldIn, d3, d5, d7);
    			Minecraft.getMinecraft().effectRenderer.addEffect(part);
    		}
    	}

     

    The chunk.getRandomWithSeed bit is the "slime chunk condition"; I copied it directly from the slime spawning code, and it lines up with what the Gamepedia Wiki says about how slime chunks are calculated. The world seed is -5415528417089611098, and ChunkBase's Slime Finder says that seed means there should be a slime chunk from (-80,-16) to (-65,-1), but if I go in that range, dig down below Y=40, and place one of these blocks...no particles. If I remove the chunk random value check, it spawns everywhere below Y=40, regardless of chunk.

    Am I missing something here? What's the proper way to detect if a given block is in a slime chunk?

  17. Okay, so after a lot of debugging, I finally got it working. I took some inspiration from how the observer block works and manually called World#notifyNeighborsOfStateChange, on all adjacent blocks, after setting the powered or unpowered block states of the Gazing Glass. It now works just fine :) I was under the impression that such block updates occurred automatically when you set a block state, but apparently not.

    Is there a better way to do this, or is that the correct way?

    • Like 1
  18. Object instantiation is a basic programming concept. As the description of this forum says, "please keep in mind that this is not a Java school. You are expected to have basic knowledge of Java before posting here." I'd suggest taking a break from modding for a bit to go an learn the basics of Java, then coming back to modding once you're more familiar.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.