Block set in code doesn't save

[Jwosty]

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!

[StrangeOne101]

Only modify blocks from the client.

if (!world.isRemote)
{
world.editBlocks = true;
world.setBlockWithNotify(x, y, z, Block.stone.blockID);
world.editBlocks = false;
}

[Jwosty]

Do you mean only modify them from the server (that's what your code indicates)? If so, how can I do this immediately after exiting a GUI?

[StrangeOne101]

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.

[Jwosty]

Hmm... Well when I add the if statement, it no longer runs at all and the method is being called from a custom GUI instance, so shouldn't it be excecuting client-side anyway?

[StrangeOne101]

Hmm, well I don't know, bud. Sorry.

[Jwosty]

Well thanks anyway! anyone else got any ideas?

[hydroflame]

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

[Jwosty]

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.

[GotoLink]

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.

  Quote

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.

[Jwosty]

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!

[Jwosty]

Oh and to put it another way, my current solution on the block placement is to send a custom packet client -> server but for some reason it's seems to be going client -> client

[GotoLink]

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.

[Jwosty]

I've got the packet initialization code; the packet info is actually even correct! And maybe the problem _is_ the GUI; I close it from within itself by using

player.displayGuiScreen((GuiScreen) null)

. Is this the correct way? I've seen it uses in the vanilla code

[gcewing]

  On 8/24/2013 at 6:42 PM, Jwosty said:

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.

[gcewing]

  On 8/24/2013 at 4:53 PM, Jwosty said:

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.

[Jwosty]

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:

 

 

  Reveal hidden contents

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

 

 

to:

 

 

  Reveal hidden contents

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

 

[Draco18s]

  On 8/18/2013 at 4:13 AM, StrangeOne101 said:

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;

[voidzm]

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.