Jump to content

Recommended Posts

Posted

Hi All,

 

Firstly, huge thanks to this forum, my few questions have found a way forward quickly with the support from the community.

 

So now my next one...

 

What I actually want it to build a view manager that moves the rendered view to preprogrammed positions, fixed and also related to entities, so could be looking from a tower to the ground, could be tracking an entity, or could be attached to an entity and tracking another.

 

It is not clear to me if view ports independent of the player can actually be achieved, so I attempted to manage the player data to get my end effect. If there is a methodology for player independent views, then PLEASE point me in the general direction and all the following becomes mute.

 

I have all my vector math in place, and can calculate yaw and pitch between two arbitrary BlockPos values, one the player, the other something to track.

 

However, my mod effectively runs on the server, so when I call inside my tick handler

 

    event.player.rotationYaw = (float)yaw;

    event.player.rotationPitch = (float)pitch;

 

Nothing happens.

 

I suspect this could be for two reasons.

 

1) the tick event is only being cast to a PlayerTickEvent and doesn't actually know who the payer is ( I will continue to scratch at this )

or

2) changing these values on the server for a player has no impact on the client.

 

As always any help greatly appreciated...

 

 

Posted

I just thought, I know there must be real player data in the event, as when I move the player, I can see the yaw and pitch calculations changing correctly, however, setting the yaw and pitch makes no difference, that remains my issue.

 

Assuming now it is because I am on server side, so looking to understand how I can force the update across to the client, or better yet, have an independent view port.

Posted

I appreciate the response, but that thread isn't particularly definitive.

 

Now I have gone through the pain of upgrading to the latest forge, I had to tear everything down and back up, to be on the updated gradlew, along with a change in behaviour for the way shading was behaving, I feel I should try and work out what has actually been added for camera control.

 

Something I have never really understood is where is the definitive reference for what is in forge.

 

We have the change notes referencing the improved camera control, but I have no idea where to go, to start reading about the details.

 

I also have to get into the server / client packet mechanism.

 

Any recommendation on where to start reading for that?

Posted

another oddity of note. If I do the following where all details are in my LookVec class then the update is forced to the client side from the server, and everything is looking in the right direction.

 

The problem is this forces me to update the player position as well, and locks the player view in place, which is not my intent, I want to be forcing the look, but still allowing movement.

 

So something in the function setPositionAndUpdate causes an update of the player data to the client, but I can't see any such code, when I chain through the call tree, and of course I want to trigger this without the Position bit...

 

    event.player.rotationYaw = lookVec.yaw;
    event.player.rotationPitch = lookVec.pitch;
    
    event.player.setPositionAndUpdate( lookVec.fromPos.getX(), lookVec.fromPos.getY(), lookVec.fromPos.getZ());

Posted

So I have this working by doing some ugly things.

 

I am using the OnServerTick to ensure I get a decent 20 per second tick rate.

I pull the first player out of the server player list for my purposes.

Then I am still using the following call to force an update of the player back to the client when I have otherwise set the rotationPitch and rotationYaw

 

player.setPositionAndUpdate(...)

 

Its ugly and makes no sense, but proves it is possible to get player pitch/yaw updated from the server to client without implementing my own packets ( which I have yet to learn )

 

I still for the life of me cannot see how the setPositionAndUpdate(...) function call achieves it...

Posted

Well, you are literally teleporting player every tick. That it at least "not very good".

Also: You want PlayerTickEvent (PTA), not server one. It fires for every player. Note that Tick events have event.phase - pick one, otherwise code is ran twice. PTA also fires for client side - simple !world.isRemote will suffice.

 

 

Learn da packets:

http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-2-customizing-packet-handling-with

or

http://www.minecraftforge.net/forum/index.php/topic,20135.0.html

1.7.10 is no longer supported by forge, you are on your own.

Posted

You shouldn't have to move the player. There is a separate camera view based on the Minecraft#getRenderViewEntity(). You can move that around to get different camera views. For example, this is how they do 3rd person view.

 

I think what you'd need to do is have the server send a packet to the client to tell it it is in forced view mode and the position and rotation of that view. Then you'd have to update the renderViewEntity with that information, and prevent other modification of the renderViewEntity. Then later you'd send a packet that releases the forced view and allows it to go back to the player following mode.

 

To change these, I think you would handle the new RenderViewEntity event.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Posted

I have now implemented based around CameraSetup event, which does the job very nicely, far smoother, and no ugly side effects.

 

MinecraftForge.EVENT_BUS.register( new HandleCameraSetupEvent());

 

	public class HandleCameraSetupEvent {

@SubscribeEvent
public void OnCameraSetupEvent( CameraSetup event) 
{ 
...
	event.pitch = lookVec.pitch;
	event.yaw = lookVec.yaw;
}

 

I have no idea how I have avoided having to make this work between server and client though, I haven't implemented any packet code, but everything is interlocked nicely !?!

 

Will continue to dig around and understand more along the way.

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.