I ran ftw class chars/Player KinematicBody but when I tried to run the whole game (ftw run), Rust gave an error that it couldn't find player in handle.add_class::<player::Player>();. This seemed to be because the generated code added mod chars; to the top, but not use chars::*; or at least use chars::player; and I had to add it myself.

I'm using the released ftw 0.6.0

I'm on Windows and godot is in my PATH; I'm able to run it from the command line.

I've created a new project: ftw new foo. Then I try to run it with cd foo; ftw run; and I get the following error after it successfully builds: "FsExtra error: The system cannot find the path specified. (os error 3)".

Currently, FTW supports creating regular classes and singletons using the class and singleton commands. I propose adding another command tool.

Currently, ftw overwrites the lib.rs file and the init function. This means that custom handle.add_class<> calls are removed from the file. In order to register a tool script with godot-rust, you have to do something like

fn init(handle: InitHandle) {
  handle.add_tool_class::<MyClass>();
}

but this will be overwritten if you ever run a command like ftw class again.

I tried implementing this command, but I got stuck because the current implementation reads the source-dir and looks for [NativeClass] using a regex. I couldn't think of a good approach for tool scripts so I decided to post an issue here and get some feedback from you before I proceed. For example, I thought of adding some custom attribute, but this would require users to import a crate into their project which feels messy and against the current approach. I also thought of making the user add a comment but this approach is not always popular.

Another option, instead of implementing this tool command, is some workaround that allows you to call some custom code from the lib.rs file.

The default lib.rs template has a compiler error with newer versions of the gdnative library. Importing the Variant type is now required to run the godot_init macro. I decided to include the prelude instead of just importing Variant to hopefully prevent these API changes from breaking things in future versions.

Test Plan:

ftw new test
cd test
ftw build

Error Output:

error[E0433]: failed to resolve: use of undeclared type `Variant`
  --> rust\src\lib.rs:13:1
   |
13 | godot_init!(init);
   | ^^^^^^^^^^^^^^^^^ not found in this scope
   |
   = note: this error originates in the macro `$crate::godot_nativescript_init` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this struct
   |
4  | use gdnative::core_types::Variant;
   |

For more information about this error, try `rustc --explain E0433`.
error: could not compile `example` due to 2 previous errors
 ERROR: The system cannot find the file specified. (os error 2)
Error: ()

lib.rs

mod game;
mod spinning_cube;

use gdnative::prelude::{godot_init, InitHandle};

// Function that registers all exposed classes to Godot
fn init(handle: InitHandle) {
    handle.add_class::<game::Game>();
    handle.add_class::<spinning_cube::SpinningCube>();
}

// macros that create the entry-points of the dynamic library.
godot_init!(init);

given that this is just a node in the game world, I'm not sure if this should be a hard requirement on building the game or not. after all, within gdnative, you can pick and choose which classes you want to expose.

provide a way to customize which godot binary to be used to invoke commands that use godot. For example, instead of having godot binary on $PATH, I want to have a custom batch or shell script file to invoke godot...

@Bromeon as per your suggestion, I have reduced the number of dependencies used by ftw.

This is the dependency tree from main branch of ftw ftw-main.txt and this is the dependency tree from this branch ftw-control-deps.txt

The dependency tree might be different on windows...

I have noticed that the compile time was a little faster than before...

Run the game in server mode, ftw run should have an option to run in server mode in addition to running via desktop. This feature is only available in Linux...