New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This adds limiting the ghost data to a specific area around the client. #908

Closed
wants to merge 2 commits into
base: development
from

Conversation

Projects
None yet
3 participants
@Winterleaf
Contributor

Winterleaf commented Nov 6, 2014

By default it is not included in the build, you must #define GHOSTSCOPING in the torqueConfig.h to enable it.
The distance can be set via the mission file by adding

visibleGhostDistance = "1000";

Or if it is not set in the mission file it will default to what is defined in torqueConfig.h #defined as GHOSTSCOPING_DEFAULT_DISTANCE_IF_NOT_IN_MISSION

The mission default distance can be overridden on a per connection basis by using gameconnection:setVisibleGhostDistance and gameconnection:getVisibleGhostDistance

The logic for setting the scoping distance was moved from shapebase in the original design to SceneObject so that it will affect cameras, players, etc.

This adds limiting the ghost data to a specific area around the client.
By default it is not included in the build, you must #define GHOSTSCOPING in the torqueConfig.h to enable it.
The distance can be set via the mission file by adding

visibleGhostDistance = "1000";

Or if it is not set in the mission file it will default to what is defined in torqueConfig.h #defined as GHOSTSCOPING_DEFAULT_DISTANCE_IF_NOT_IN_MISSION

The mission default distance can be overridden on a per connection basis by using gameconnection:setVisibleGhostDistance and gameconnection:getVisibleGhostDistance

The logic for setting the scoping distance was moved from shapebase in the original design to SceneObject so that it will affect cameras, players, etc.
@dottools

This comment has been minimized.

Show comment
Hide comment
@dottools

dottools Nov 6, 2014

Looks good I see no problems.

dottools commented Nov 6, 2014

Looks good I see no problems.

@Winterleaf

This comment has been minimized.

Show comment
Hide comment
@Winterleaf

Winterleaf Nov 6, 2014

Contributor

Of course! I wrote it :P

Contributor

Winterleaf commented Nov 6, 2014

Of course! I wrote it :P

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket Nov 6, 2014

Contributor

Thanks for revising it to be a property of the GameConnection :).

I'd much prefer to lose both the #defines and the additional imports of torqueConfig.h. If the ghost visible distance is set to 0 then the current behaviour (visible distance scoping) should be used.

Ooh, I see, this may interfere with the current behaviour with defaults of 0. But I'd really prefer to not have features barred out using #defines without good reason (i.e. inability to compile on multiple platforms).

EDIT: So currently, you can set the visible ghost distance in the connection, and if that's zero, it can be overridden by the distance in the level info. Maybe we need one additional step - if that's also zero, use the visible distance.

Contributor

crabmusket commented Nov 6, 2014

Thanks for revising it to be a property of the GameConnection :).

I'd much prefer to lose both the #defines and the additional imports of torqueConfig.h. If the ghost visible distance is set to 0 then the current behaviour (visible distance scoping) should be used.

Ooh, I see, this may interfere with the current behaviour with defaults of 0. But I'd really prefer to not have features barred out using #defines without good reason (i.e. inability to compile on multiple platforms).

EDIT: So currently, you can set the visible ghost distance in the connection, and if that's zero, it can be overridden by the distance in the level info. Maybe we need one additional step - if that's also zero, use the visible distance.

@Winterleaf

This comment has been minimized.

Show comment
Hide comment
@Winterleaf

Winterleaf Nov 6, 2014

Contributor

I’ve received word from a user that it causes issues with sidescrollers. Thus the reason I #defined it.

Contributor

Winterleaf commented Nov 6, 2014

I’ve received word from a user that it causes issues with sidescrollers. Thus the reason I #defined it.

Show outdated Hide outdated Engine/source/T3D/levelInfo.cpp Outdated
Show outdated Hide outdated Engine/source/T3D/levelInfo.h Outdated
@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket Nov 6, 2014

Contributor

Interesting. Any chance you could point them to this discussion? I'd love to know what these issues were and how we could reproduce them. There is probably some underlying problem that also needs to be solved.

Contributor

crabmusket commented Nov 6, 2014

Interesting. Any chance you could point them to this discussion? I'd love to know what these issues were and how we could reproduce them. There is probably some underlying problem that also needs to be solved.

@Winterleaf

This comment has been minimized.

Show comment
Hide comment
@Winterleaf

Winterleaf Nov 6, 2014

Contributor

If I remember right it had to do w the distance to the camera and angle.

Contributor

Winterleaf commented Nov 6, 2014

If I remember right it had to do w the distance to the camera and angle.

@crabmusket crabmusket added this to the 3.7 milestone Nov 7, 2014

@@ -388,7 +388,14 @@ F32 GameBase::getUpdatePriority(CameraScopeQuery *camInfo, U32 updateMask, S32 u
// Weight by field of view, objects directly in front
// will be weighted 1, objects behind will be 0
F32 dot = mDot(pos,camInfo->orientation);
#ifdef GHOSTSCOPING
bool inFov = dot > camInfo->cosFov*1.5f;

This comment has been minimized.

@crabmusket

crabmusket Dec 7, 2014

Contributor

Reason behind change?

@crabmusket

crabmusket Dec 7, 2014

Contributor

Reason behind change?

This comment has been minimized.

@Winterleaf

Winterleaf Dec 7, 2014

Contributor

Yes it gets ride of the jitters on the edge of the camera view when objects are on the edges

@Winterleaf

Winterleaf Dec 7, 2014

Contributor

Yes it gets ride of the jitters on the edge of the camera view when objects are on the edges

This comment has been minimized.

@crabmusket

crabmusket Dec 7, 2014

Contributor

Got it. I'm modifying this PR to get rid of the #defines and fall back to visibleDistance if no ghost distance is defined. Acceptable?

@crabmusket

crabmusket Dec 7, 2014

Contributor

Got it. I'm modifying this PR to get rid of the #defines and fall back to visibleDistance if no ghost distance is defined. Acceptable?

This comment has been minimized.

@Winterleaf

Winterleaf Dec 7, 2014

Contributor

Sounds fine

@Winterleaf

Winterleaf Dec 7, 2014

Contributor

Sounds fine

This comment has been minimized.

@crabmusket

crabmusket Dec 7, 2014

Contributor

See #1018, and in particular this commit for what I changed in your code.

@crabmusket

crabmusket Dec 7, 2014

Contributor

See #1018, and in particular this commit for what I changed in your code.

@crabmusket crabmusket referenced this pull request Dec 7, 2014

Merged

Ghost scoping #1018

@crabmusket crabmusket closed this Dec 7, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment