I'm running into an odd issue regarding the Online Subsystem NULL. I am able to create and join sessions just fine. Once I join the session all client's pawns are experiencing a rubber band effect upon movement. There is also other odd behavior such as clients returning null when getting the GameState class.
The odd thing is everything works fine and as expected using the Online Subsystem Steam. Testing on two separate computers logged into separate steam accounts the rubber band movement problem goes away and the odd behavior of clients getting null for the GameState class does not exist.
I release this would be a bigger issue if the cases were reversed. Development is just taking longer due to this issue.
When changing between the Steam and NULL Subsystems I change the following in the DefaultEngine.ini file
NULL
[/Script/Engine.GameEngine]
+NetDriverDefinitions=(DefName="GameNetDriver",DriverClassName="OnlineSubsystemSteam.SteamNetDriver",DriverClassNameFallback="OnlineSubsystemUtils.IpNetDriver")
[OnlineSubsystem]
DefaultPlatformService=NULL
[OnlineSubsystemSteam]
bEnabled=false
SteamDevAppId=480
[/Script/OnlineSubsystemSteam.SteamNetDriver]
NetConnectionClassName="OnlineSubsystemSteam.SteamNetConnection"
Steam
[/Script/Engine.GameEngine]
+NetDriverDefinitions=(DefName="GameNetDriver",DriverClassName="OnlineSubsystemSteam.SteamNetDriver",DriverClassNameFallback="OnlineSubsystemUtils.IpNetDriver")
[OnlineSubsystem]
DefaultPlatformService=Steam
[OnlineSubsystemSteam]
bEnabled=true
SteamDevAppId=480
[/Script/OnlineSubsystemSteam.SteamNetDriver]
NetConnectionClassName="OnlineSubsystemSteam.SteamNetConnection"
Are there any other settings in the DefaultEngine.ini file that need to be changed for the Null Subsystem for function correctly? Thanks!
Related
Calling ARCloudAnchor cloudAnchor = manager.HostCloudAnchor(anchor) gives null for cloudAnchor (where manager is of type ARAnchorManager and anchor is of type ARAnchor). I have the API key set up for ARCore Extensions with the GCP server. Help is much appreciated.
Maybe your feature map quality is not good. Try to call manager.EstimateFeatureMapQualityForHosting(GetPoseCamera()) to check the quality
INSUFFICIENT: it is not good enough to resolve cloud anchor later (host anchor can be failed with this quality and you may receive NULL for cloud anchor) -> try to move device around object.
SUFFICIENT: it is okay
GOOD: it is good
Note: You have to define GetPoseCamera() function. (it is easy, just includes position and rotation of camera)
Took me a while, but I fixed this.
Even though the ARCore Extensions sample gave cloudAnchor.cloudAnchorState == CloudAnchorState.Success immediately when calling manager.HostCloudAnchor, I got cloudAnchor.cloudAnchorState == CloudAnchorState.TaskInProgress which made cloudAnchor == null give true. I needed to loop until the state was Success (which took about 5 seconds each time). After the wait, the anchors are hosted without a hitch.
I am currently learning the UnrealEngine and made huge steps in less time.
I worked with version 4.25.1 for a while now and created a projekt in there without having any problems so far.
Yesterday I switched from version 4.25.1 to 4.26.0 (Prev2) and observed a strange behaviour.
In the older version I used "MultiSphereTraceByChannel" in one of my Actor-BluePrints and everything worked fine. Looping through the HitArrayResult gave me all hits of the tracer with specific objects.
Now in 4.26.0 it seems that it does not work properly anymore like before. Every hit returns an ImpactPoint of [0,0,0].
Here is a shortened example of my BluePrint:
So First I trace every hit with MultiSphereTraceByChannel with specific objects and then I try to render a sphere at each ImpactPoint of all found hits.
This worked in the older Version but does not now...
Does anyone have any Ideas/Suggestions/Questions?
To me it seems that something changed in the newer version which affects the MultiSphereTracer to work like it did before.
Sincerly
OlsonLong
Edit:
This problem also happens with regular SphereTraceByChannel-Function!
After some investigations i found the problem/solution to this and it still bothers me that this happens in 4.26... The problems are the Start- and End-Vectors of the SphereTracer (doesn't matter which tracer).
In my example i use ActorLocation as Start- and(!) End-Vector which leads to this struggle. Now if i shift the vector like 1 unit on Z, everything workes fine again.
This is the correct way of the example above:
Works with both MultiSphere- and SphereTraceByChannel.
But it still bothers me why this happenes because now i have to change ALL SphereTracer and shift them by only 1 unit.
To illustrate an example scenario that prompted this question, please consider the following:
A room, attic, that contains 3 devices: one light that supports both ColorSpectrum and ColorTemperature, one light that only supports ColorTemperature and one light that only supports ColorSpectrum (all 3 also support OnOff and Brightness, but this appears to be irrelevant).
"Set the attic to warm white" will result in two of the lights receiving a temperature value in Kelvin, whereas the third (which didn't support ColorTemperature) will receive an rgb/hsv color value approximating the correct hue of white.
Conversely: "Set the attic to red" will result in all 3 lights receiving an rgb/hsv color value (including the light that does not support the ColorSpectrum trait).
We are unsure how a light that supports only ColorTemperature is supposed to respond to an rgb/hsv value. This final scenario - after the light's failure to be able to execute the user's command - left us with 3 options to respond:
Lie and respond 'SUCCESS' for all 3 lights, "Ok, changing 3 lights to red."
Omit the third light from the response entirely, "Ok, changing 3 lights to red."
Respond with "notSupported" 'ERROR' for the third light, "Ok, changing 2 lights to red. That mode isn't available for the LIGHT_3."
Option 1 is clearly undesirable, incorrect feedback is worse than no feedback at all.
Option 2 is equivalent to 1, though it seems odd that Google Home should assume that a device omitted from a response was successfully processed.
Option 3 we deem unideal as well, as we expect the user may get bored of hearing that a certain light in their room is unable to change color when they might be perfectly aware of this fact. Our preference would go to a response of: "Ok, changing 2 lights to red." We feel that this communicates clearly that one light didn't change, without the potentially superfluous error message.
Our question, then, is how we might realize this?
Is the behavior listed above unintended (a bug)?
Is there some response that we are unaware of that can be used to communicate to Google Home that a device simply is not eligible for the provided execution?
Is the behavior listed above not experienced by others or the result of a mistake on our part?
Thank you for reading.
I'm going to check about this scenario as it might be a bug in which devices get commands when they shouldn't.
Canonically, option three may be undesirable but is the right implementation. Trying to ignore the command will also create a bad user experience as they receive an incorrect reply.
This is in relation to the checkbox that allows users to stay logged in when they close their browser. In an intermediate version, we remembered the user regardless, and now we're checking the params to see if the checkbox was set. This is the line of code that confuses me:
params[:session][:remember_me] == '1' ? remember(user) : forget(user)
Specifically, why are we forgetting the user if params[:session][:remember_me] is 0? Since we have never remembered the user (I think -- I'm a major newbie), wouldn't this work:
remember(user) if (params[:session][:remember_me] == '1')
and make more sense? I tried it and it passes the tests (which are very basic), but it also seems to behave appropriately. But maybe there's some stray variable that's staying set that I'm missing because I don't know what I'm doing.
I am at the exact same point and was wondering about the exact same thing.
And I came to the conclusion: it's only about security.
Because if an user never logs out of your app, an attacker who stole her user_id and remember_token cookies could use them all the time. However if the user eventually logs in on another computer either the remember_digest attribute gets a new value or is set to nil. Either way the attacker gets locked out.
By omitting forget(user) the only time the remember_digest is set to nil is when the user deliberately logs out.
However the version remember(user) if (params[:session][:remember_me] == '1') gives the user the ability to select one "remembered" computer.
This is a weird one. :)
I have a script running under Apache 1.3, with Apache::PerlRun option of mod_perl. It uses the standard CGI.pm module. It's a regularly accessed script on a busy server, accessed over https.
The URL is typically something like...
/script.pl?action=edit&id=47049
Which is then brought into Perl the usual way...
my $action = $cgi->param("action");
my $id = $cgi->param("id");
This has been working successfully for a couple of years. However we started getting support requests this week from our customers who were accessing this script and getting blank pages. We already had a line like the following that put the current URL into a form we use for customers to report an issue about a page...
$cgi->url(-query => 1);
And when we view source of the page, the result of that command is the same URL, but with an entirely different query string.
/script.pl?action=login&user=foo&password=bar
A query string that we recognise as being from a totally different script elsewhere on our system.
However crazy it sounds, it seems that when users are accessing a URL with a query string, the query string that the script is seeing is one from a previous request on another script. Of course the script can't handle that action and outputs nothing.
We have some automated test scripts running to see how often this happens, and it's not every time. To throw some extra confusion into the mix, after an Apache restart, the problem seems to initially disappear completely only to come back later. So whatever is causing it is somehow relieved by a restart, but we can't see how Apache can possibly take the request from one user and mix it up with another.
This, it appears, is an interesting combination of Apache 1.3, mod_perl 1.31, CGI.pm and Apache::GTopLimit.
A bug was logged against CGI.pm in May last year: RT #57184
Which also references CGI.pm params not being cleared?
CGI.pm registers a cleanup handler in order to cleanup all of it's cache.... (line 360)
$r->register_cleanup(\&CGI::_reset_globals);
Apache::GTopLimit (like Apache::SizeLimit mentioned in the bug report) also has a handler like this:
$r->post_connection(\&exit_if_too_big) if $r->is_main;
In pre mod_perl 1.31, post_connection and register_cleanup appears to push onto the stack, while in 1.31 it appears as if the GTopLimit one clobbers the CGI.pm entry. So if your GTopLimit function fires because the Apache process has got to large, then CGI.pm won't be cleaned up, leaving it open to returning the same parameters the next time you use it.
The solution seems to be to change line 360 of CGI.pm to;
$r->push_handlers( 'PerlCleanupHandler', \&CGI::_reset_globals);
Which explicitly pushes the handler onto the list.
Our restart of Apache temporarily resolved the problem because it reduced the size of all the processes and gave GTopLimit no reason to fire.
And we assume it has appeared over the past few weeks because we have increased the size of the Apache process either through new developments which included something that wasn't before.
All tests so far point to this being the issue, so fingers crossed it is!