Jump to content

Block set in code doesn't save


Jwosty

Recommended Posts

I've been trying to get my mod to place blocks (using things like the Nether portal code for reference), and it seems to work. But when I reload the world, they're gone! I speculate that it's not sending the information to the server... Here's the process I use:

world.editBlocks = true;
world.setBlockWithNotify(x, y, z, Block.stone.blockID);
world.editBlocks = false;

I've even seen some vanilla code that doesn't do the whole

world.editBlocks

thing -- in fact, most of it doesn't! But in any case, I just can't get this to work... Please help! :)

I like to make mods, just like you. Here's one worth checking out

Link to comment
Share on other sites

No, just make sure your doing it client side. That's what the

if (!world.isRemote)

is for. If isRemote returns true, it's running the code from the server (it runs from both client and server though). So the code only runs when the client runs the code.

 

And I have no idea about GUIs. There's bound to be a method for when you close them though.

The enders are everywhere. You can't escape...

Link to comment
Share on other sites

wow ... StrangeOne101... im sorry but youre soooo wrong. every modification to the world MUST be done server side or else they will be erased.

@op: a general answer would be to tell you you must send a package to tell the server that a certain plaer has accomplished the action. if you explained in more details what you want to do i could give a better explanation. but youre going to need to send a packet.

also, you DONT need the editBlocks thing

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Link to comment
Share on other sites

Ok, I've been trying to do work on the packet for a few days now using the Forge packet handling page, but for some reason the packet handler always excecutes on the client side (I've confirmed this by getting the side in the debugger and also using

@SideOnly(Side.SERVER)

). And the code for the packet calls are written exactly following the tutorial... here are the files in question: BlockStargateController.java, line 127, PacketHandler.java, line 18

 

Does this have something to do with me only testing this on SP? I though Minecraft ran a server even for that gamemode anyway...

 

PS: I also did use

[url=https://github.com/jwosty/Minecraft-SpaceDistortionMod/blob/develop/common/SpaceDistortion.java#L15]serverSide=true[/url]

in the mod class

@NetworkMod

annotation

 

EDIT: I'm using this for a similar effect to the Nether portal stuff, but to called from a GUI instead of a block tick or whatever.

I like to make mods, just like you. Here's one worth checking out

Link to comment
Share on other sites

This code

Minecraft.getMinecraft()

is client side only.

You will crash on server if you use it in a class which isn't client side only.

 

Use player.openGui(args) to open a GUI, and handle it with a IGuiHandler.

PS: I also did use serverSide=true in the mod class @NetworkMod annotation

You can leave it to false, it probably isn't necessary. On the contrary, clientSide=true is necessary.

Link to comment
Share on other sites

I'm not trying to write the open GUI code: I already have that. Essentially I'm trying to place some blocks from the GUI, usin a packet. The recieving end of the packet handler is only executing on the client server instead of the server side when I send the packet to the server...

 

And thanks for pointing out that

Minecraft.getMinecraft()

doesn't work on server side, which means that that part, ironically, should cause a crash when the packet sends correctly and the server receives it instead of the client... I guess that's how I'll know when it works!

I like to make mods, just like you. Here's one worth checking out

Link to comment
Share on other sites

If you don't crash, that means your PacketHandler class doesn't even initialize.

Which means you don't have packethandler=PacketHandler.class in your @NetworkMod annotation.

By the way, correctly opening the GUI is essential, and might well be the source of your problem.

It is impossible to send a packet from client to client without going through a server.

Link to comment
Share on other sites

And thanks for pointing out that

Minecraft.getMinecraft()

doesn't work on server side, which means that that part, ironically, should cause a crash when the packet sends correctly and the server receives it instead of the client... I guess that's how I'll know when it works!

Be careful -- if you're testing in single player mode, all the client side methods are accessible, even from server-only parts of the code, which means it's possible to write code that works fine in single player, but crashes when run on a real server.

 

Concerning the packet handler, if you use packethandler = ... in @NetworkMod, it uses the same packet handler class for both client and server, so it's possible that your packet *is* being received on the server side but you're not noticing.

 

Also, the earlier reply concerning isRemote got it backwards -- isRemote == true on the client side and false on the server side. You might be getting confused by that.

Link to comment
Share on other sites

for some reason the packet handler always excecutes on the client side (I've confirmed this by getting the side in the debugger and also using

@SideOnly(Side.SERVER)

).

I think the side is always reported as client side in single player. It's probably more reliable to check world.isRemote.

 

Also, I don't think the @SideOnly annotations do anything in mod code. All methods are compiled in, so that the same jar can be used on client and server.

Link to comment
Share on other sites

  • 4 weeks later...

After a long break from this project then finally another debugging session, I discovered a few days ago that the problem was in the code that opens the GUI... I guess it was a simple as changing this:

 

 

if (world.isRemote) {
Minecraft.getMinecraft().displayGuiScreen(new GuiDHD(x, y, z));
}

 

 

to:

 

 

if ([color=red][b]![/b][/color]world.isRemote) {
Minecraft.getMinecraft().displayGuiScreen(new GuiDHD(x, y, z));
}

 

I like to make mods, just like you. Here's one worth checking out

Link to comment
Share on other sites

No, just make sure your doing it client side. That's what the

if (!world.isRemote)

is for. If isRemote returns true, it's running the code from the server (it runs from both client and server though). So the code only runs when the client runs the code.

 

And I have no idea about GUIs. There's bound to be a method for when you close them though.

 

Wow, this is hilariously bad.

 

/** This is set to true for client worlds, and false for server worlds. */
    public boolean isRemote;

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

The way that you're opening the GUI is really not optimal. I tried doing that when I first started doing GUIs, and it always ended in horrible server/client desyncing. The way you have it set now, like Draco said, shouldn't even be working. You're telling the server to open a GUI, and I bet that would crash instantly on a real server.

 

Look up stuff concerning IGuiHandler. That is the way that you are "supposed" to do it in Forge. It takes care of making sure that both the server and the client know what the player is doing, and that you can get the relevant code running for both sides.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

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