Is there a way to save the current chalkboard to allow you to reuse it later? I can perform a Save As, but that saves it as a waveform. If I don't save it, the chalkboard disappears when I close REDHAWK IDE.
Technically, the short answer is no. There is no way to save an instance of the Chalkboard and reload it into the Chalkboard.
What you may want to do, is save the Chalkboard as a waveform using File->Save As. Then, you may "Launch a Local Waveform" from the Overview tab of the Waveform Editor. This will launch the waveform within the Sandbox, essentially making a new Chalkboard instance that you may interact with in the same way as the Chalkboard, including the ability to modify and resave the the current Sandbox instance as a new waveform to repeat the process.
One final thing to keep in mind, the Chalkboard/Sandbox does not set an Assembly Controller so once you are done and want to run this waveform within the Domain, you'll need to designate an Assembly Controller or else you will get an error on launch.
Related
I come from Unity, and there you can use ContextMenu method attribute. It will add a button in the editor you can click and the method in your script will be invoked.
This is very helpful for testing/debugging purposes. When you are testing a functionality and you want an easy way to trigger it.
Is there something similar in Godot, or any workaround I can use?
(Godot 3.5 here)
There are multiple ways to run code in the editor.
In fact, Godot games and the Godot editor are built on the same core. One way to say is that Godot is build on Godot… But a more accurate way to say it is that your games are Godot without the editor, plus whatever you built on top.
As a consequence, you have a lot of freedom when extending the Godot editor.
For starters you will be making a tool script. To do that you the tool keyword on the top of the script file. This allows the script to run in the editor.
Warning: Remember that in Godot the Game is not running inside the Editor. Anything that your script moves while running in the Editor would be a modification to the project, for good or ill. And it does not come with build-in undo functionality. It is possible to add undo functionality (with the UndoRedo class), but that is also something you would have to program.
By the way, you might want to know if your code is running on the editor or not. For that, you can check Engine.editor_hint which will be true in the editor.
Read more on the article Running code in the editor.
Since the tool script modify the project. What I present below is more often used to setup parts of the scene or to automate parts of the development workflow. Not for testing features. However since the linked documentation about ContextMenu mentions that it is useful for…
automatically setting up Scene data from the script
I believe what present below is not out of place.
With that said, some modifications of the editor are harder than others. I believe you don't really want to go into the trouble of adding a button to the editor (which is perfectly possible) or an option to the menus (which is also possible, but not everywhere, at least not easily). Instead, I'll stay with the easy options for this answer:
You can make an EditorScript. That is a script that extends the EditorScript class and overrides the _run method. For example:
tool
extends EditorScript
func _run():
print("Hello from the Godot Editor!")
To execute it, have it open in the Script Editor, and to the File menu, and select Run. You can also use secondary click on the script on the "Scripts Panel (on the left of the Script Editor) and select Run in the contextual menu.
The drawback is that is script does not work in the game. It is only for the editor.
Although Godot 3.x does not have official (there is a plugin) support for inspector actions (it might land in Godot 4), we can workaround that. What we will do is export a bool property, and handle (with a setter, which we specify with setget) what happens when you set it. Like this:
tool
extends Node # or whatever
export var do_something:bool setget on_do_something
func on_do_something(_mod_value:bool) -> void:
# do whatever you want
pass
The property should show up as a checkbox in the Inspector panel when the node is selected. And clicking the checkbox will trigger the setter method on_do_something… Which will do whatever you want it to do. Notice also that I'm discarding the value that Godot is trying to set to the property (_mod_value) so it will remain false.
This pattern has got popularity among Godot developers.
If you want to add elements to the Godot UI you would have to make an EditorPlugin (see the Editor Plugins section in the documentation).
Alright but, since the tool script could cause modifications to the project, which might be a problem for testing… What do we do for testing?
Well, I will remind you that you can tell Godot to execute specific scenes (it does not have to run the main scene), and that can another way to test your code.
Furthermore, when your game is running you can go to the Scene panel and select the Remote tab to see the Nodes that exist in the game. Which will allow you to select them, which shows their properties in the Inspector, which would be able to modify (having an effect in real time on the executing game).
… And thus something similar to what I described above about using a setter would work. Except it does not need the tool keyword since it won't be running in the editor:
# No tool
extends Node # or whatever
export var do_something:bool setget on_do_something
func on_do_something(_mod_value:bool) -> void:
# do whatever you want
pass
By the way, in the inspector, when the game is executing and you have the relevant Node selected, you will see your property twice. The first one will trigger the setter, while the second one bypasses it. So pay attention which one you are using.
You might also be interested in the "Project Camera Override" feature, which allows you to freely move the game camera from the editor. You access the feature via the top bar in the editor.
You will also find that it is possible to modify Resources in the editor and see the effect in real time while the game is running. And a Script is a Resource… However pause the game from the Debugger panel (or use a breakpoint) and make sure the script you want to modify is not being executed before you modify it.
I know that for css, html, and gsp files you can just refresh the browser without having to rebuild the application in order to see your updated changes. If you're stepping through code in debug mode, and make a change for a groovy or class file, do you have to rebuild the application in order to see the change?
IntelliJ does not update the classes in your running application automatically. You need to compile them manually (this will not be a full project rebuild - IntelliJ will build the project incrementally and compile only the changed classes and the code that depends on them), and then IntelliJ will offer you to reload the changes (which may fail if the changes you made aren't supported by the Java hotswap).
Note that some Web frameworks may be able to reload the changed classes automatically, independently of whether you're running your code from IntelliJ or not.
Say you're stopped on a break point, and want to edit the source code of the method you're in. Make the edit, save it, then run > Reload Changed Classes. Then, in the debugger controls, Drop Frame. Without dropping the frame, you won't execute the your newly recompiled method body.
By default, there's no keybindings for these 2 commands, but you can create them via the KeyMap in the settings (ctrl + alt + s). Even better, you can make a macro that will execute both these commands for you.
I wish it was easier and automatic, like in eclipse, but oh well.
Let's say I make a custom file that actually corresponds to what my program can read called "Bacon.dek". I can access it, modify it, etc. normally from my program, with only a few problems staying alive (fixing them at a relatively correct speed, too).
Now, what I wanna do (and try to fix rather quickly once done), is actually choosing my file from Windows Explorer, right-clicking on it, and choose "Open with..." and choose my application.
Or simply set my application as the default application to simply double-click it and it would open in my app? Like, I double-click "Bacon.dek", and it opens "Eggs.exe", reading "Bacon.dek"?
Basically you have to do this -
In registry add these keys
[HKEY_CURRENT_USER\Software\Classes\dekEditor\shell\open\command]<br/>
#="c:\path\to\app.exe \"%1\""<br/>
[HKEY_CURRENT_USER\Software\Classes\.dek]<br/>
#="dekEditor"<br/>
This is a 2 step task.First you associate your extension .dek with dekEditor (2nd entry) and then specify it in Classes(1st entry).
Answer taken from: Create registry entry to associate file extension with application in C++
MSDN Article.
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
I am working on old Motif-based application for Linux. I want to be able to programmatically change the active window of our application. I can redirect the input by using XSetInputFocus() function and the keyboard input start to go there, but XReconfigureWMWindow() and XRaiseWindow() functions just don't work.
I've read that Window Managers try to stop this behaviour, so tried to disable configure redirection, but this doesn't work either. Any ideas how to make one of my own windows on top of the window stack?
There is a tiny program called wmctrl available (at least in Debian/Ubuntu it is in standard distribution) which is able to perform many operations on windows and desktops, and handles plenty of window managers. I'd suggest testing whether it works in your environment, and if so, peeking at its sources.
You may find the answer to this is dependent on the Window Manager the user is using, or even what settings they've given to the Window Manager. I like to set my Window Managers to do "focus follows mouse", which means you can't send the focus to a window that I haven't put my mouse on, unless you also warp the mouse there (is that function called XWarpMouse?).