Ok, I've been using Godot for a while now, and haven't really had any issues. But, after I added an area2D to detect the player and teleport them as shown below that I run into issues. Every time I start the game, the console shows that both of the functions have already been run, even though the starting location is nowhere near the area2Ds. In addition, because they run in enter -> exit order, it spawns me at the exit of the tunnel, instead of the start of the map.
func _on_Tunnel_body_entered(_body):
print("entered_tunnel")
global_position.x = 952.5
global_position.y = 487
func _on_TunnelBack_body_entered(_body):
print("exited_tunnel")
global_position.x = 920
global_position.y = 635
Any help would be appreciated!
Are you, by chance, instancing the player character, adding it to the scene, and then setting its position (in that order)?
That is a common reason for this problem. What happens is that it collides with the areas once you add it to the scene but before you set its position.
To solve it set the global position before adding it to the scene.
You could temporarily disable the behavior by any of these means:
Temporarily changing the layers and mask to avoid the collision (you can do it with set_collision_layer_bit and set_collision_mask_bit).
Temporarily disabling collision shapes (by setting disabled to true. However, use set_deferred to avoid disabling it while Godot is still doing physics computations)
Temporarily adding collision exceptions (by calling add_collision_exception_with and remove_collision_exception_with).
Having a flag that you can check in the function that takes the signal to decide if it should take effect or not.
Connecting the signals from code once, so they are not connected beforehand.
Related
Whenever I run an Open Spiel environment with Ray, I always get tons of errors about the moves not being legal. I was wondering if there was anyway to apply action masking with an Open Spiel environment.
I ran the example included with ray: https://github.com/ray-project/ray/blob/master/rllib/examples/self_play_with_open_spiel.py
I kept getting this error:
(RolloutWorker pid=27106) OpenSpiel exception: /project/open_spiel/games/connect_four.cc:94 CellAt(kRows - 1, move) == CellState::kEmpty (RolloutWorker pid=27106) CellAt(kRows - 1, move) = X, CellState::kEmpty = Empty
The ActionMasking example does just that. You can use ActionMaskModel to avoid illegal actions. Be aware that such a model always needs access to the actual illegal actions. RLlib itself has no knowledge of the specifics of Open Spiel environments. So in order to successfully mask them, you'll have to wrap the environment.
This example should include all you need.
There is also a user implementation out there.
I use this code to wait for an object in SikulixIDE 1.1.4-SNAPSHOT: wait(Pattern("1548143854795.png").similar(0.7),35).
After 15-20 seconds object is present on screen, but it doesn't wait for it. Next type() methods are executed without waiting for object.
This usually happens if something else is visible on the screen that matches also with a similarity >0.7.
You can check this in the IDE with the Preview feature (click the image).
Programmatically you can highlight the found match:
wait(Pattern("1548143854795.png").similar(0.7),35).highlight(3)
If something else is found you might try with a higher similarity like 0.95 or even 0.99 (exact match).
read how SikuliX works
I'm using the web speech API but once a bit of time passes by (a minute or 2) without any vocal input, it stops listening entirely. I know this because I have it log its parsed text to the console, however, it stops doing this when I do not talk for a minute or two.
Is there any way to fix this?
You can listen to the end event and then restart the recognition on the SpeechRecognition object.
You should use a boolean flag for deciding (in the onend event handler), when to restart the recognition (and when not to restart).
You could use the other recognition-related events for this.
E.g. Chrome triggers the following event handlers when recognition is started:
1. onstart
2. onaudiostart
(only if sound / speech is detected)
3. onsoundstart
4. onspeechstart
If no sound speech is detected, only the first 2 will be triggered, and then, after some timeout, the corresponding end events (in reverse order).
A simple solution for this could probably be to listen for the end event and restart the recognition
recognition.addEventListener('end', recognition.start);
recognition.addEventListener('end', () => recognition.start()) works but Chrome browser seems to obstrruct the continuity by generating a pop-up to Allow or Block the microphone every 5-7 seconds.
OK, so I've been at this for a good couple of hours now and I'm starting to rage.
I am making a kiosk-app in flash (air) which should not allow users to exit fullscreen mode by any other means than typing in a password. This has proved somewhat impossible, as it appears you just can't prevent users from using ctrl+alt+delete or command+alt+esc or for that matter alt+tab. But at the very least I want to prevent them from using escape, alt+f4, command+q and command+w.
After a fair bit of googling I've got escape, alt+f4 and command+q down. Basically I'm just setting listeners for the CLOSE, CLOSING and EXITING event on stage.nativeWindow and preventingDefault(). The CLOSE and EXITING events never fire in this case, they're just there for good measure. I'm handling ESC simply by listening for KEY_UP and preventing it. However:
Command+w is refusing to cooperate. It appears to be doing something which minimizes the fullscreen before dispatching the CLOSING event. So, the question is:
What is it, and how do I prevent it?
You could set up a listener for command+w, and, brutally:
if (this.stage.displayState == StageDisplayState.NORMAL)
{
this.stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
//you'd need to play with this and see if it suits your needs or not, if not, don't use it.
this.stage.scaleMode = StageScaleMode.EXACT_FIT;
}
It's kind of a pain in the keister if the app loses focus, it can't listen for keystrokes. My solution for this has been to set up a loop that frequently steals focus - but this is not good for an app that could ride in the background. For a kiosk-type app, and a system that's intended to only run one app, this is an acceptable compromise.
So at the same time, you can also set, in this loop, a command like the one above, that restores the app to full-screen. You'll have to mess around with the timer frequency that dictates how often this loop runs and steals focus - more than 5 or so times per second (depending on what else is in your app) can really be a cpu and memory suck.
The main problem is: I don't think there's a way for AIR to totally kill these escape keystrokes in kiosk mode. It's kind of a security "risk". (by the way, I think that the ESC key also invokes windowed-mode from full-screen; Don't quote me on that-).
I guess, another workaround would be to periodically kick the app into the BACKGROUND. This would prevent the control+w kestrokes from ever being caught by the app. But I think that the behavior of the program would be pretty annoying if there was any other interactivity required.
This is what worked for me (although, in this example, I am calling a function that explicitly captures ctrl+w to go to windowed-mode, the opposite of what you're asking for; I used this code this way, because I have some logging operations built in to what I'm doing, so I needed to intercept and control the keystroke activity):
if (event.ctrlKey)
{
//ctrl+F & ctrl+K -> go full screen;
if(event.charCode == 102 || event.charCode == 107)
{
makeFullScreen();
}
//ctrl+S & ctrl+Q -> write to logfile, exit program;
if(event.charCode == 115 || event.charCode == 113)
{
instrumentedExit();
}
//ctrl+W -> exit kiosk;
if(event.charCode == 119)
{
windowedMode();
}
}
An AIR application simply cannot interfere with system/task keys, however a native application can which means a native extension.
e.g in windows you could call SystemParametersInfo(SPI_SETSCREENSAVERRUNNING, ...)
I promise this isn't as simple as it sounds. I'm wondering why the the first ever call to HttpSendRequest takes much longer than subsequent calls, even when the later requests are for a different URL. For example:
InternetConnect(... "foo.com" ...) // returns immediately
HttpOpenRequest(...) // returns immediately
HttpSendRequest(...) // takes ~3 sec
HttpSendRequest(...) // takes ~200 ms
InternetConnect(... "bar.com" ...) // returns immediately
HttpOpenRequest(...) // returns immediately
HttpSendRequest(...) // takes ~200 ms
Why does the first HttpSendRequest(...) take so much longer? This is very consistent, regardless of the URLs.
Thanks,
Greg
There are several things that may need to happen on the first request that don't need to happen on the second. DNS lookup and proxy detection immediately come to mind.
It could also be config file loading. Some of the .Net framework classes will attempt to read settings from the application config file, revertign to defaults if no file or setting is found. E.g. WebRequest/WebClient which I think are Http classes use under the hood will check for explicit web proxy settings, if those don't exist then then proxy setting from the OS (as set within IE) are picked up. Allof this contributes to an initial startup lag usually when the class is first used, that is, the work is often done in within a static contructor.
The config settings are defined here:
Configuration File Schema for the .NET Framework