Skip to content
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

Revamp the scripting API #2736

Closed
MatusGuy opened this issue Jan 15, 2024 · 4 comments · Fixed by #2792
Closed

Revamp the scripting API #2736

MatusGuy opened this issue Jan 15, 2024 · 4 comments · Fixed by #2792

Comments

@MatusGuy
Copy link
Member

MatusGuy commented Jan 15, 2024

I've had an idea for a while now. Let's revamp the scripting api by using a library called simplesquirrel. With this we could practically replace miniswig, which just adds another thing to setup. Also it's a code generator. Code generator bad.

We could replace the functionality of ExposedObject by making the expose function explicitly expose the selected functions:

static void expose(ssq::VM& vm) {
  ssq::Class cls = vm.addClass("BadGuy", ssq::Class::Ctor<Foo(<arguments for badguy constructor>)>());

  // You can also use lambdas (or std::function) to define constructor
  // The function has to return pointer to the new instance
  //
  // vm.addClass("BadGuy", [](<arguments for badguy constructor>) -> BadGuy* {
  //     return new BadGuy(msg);
  // });

  cls.addFunc("kill_fall", &BadGuy::kill_fall);
  cls.addFunc("set_action", &BadGuy::set_action);

  cls.addVar("dir", &BadGuy::m_dir);
}

This is ripped from simplesquirrel's readme. The readme has really interesting stuff. I recommend you check it out. I also have an idea of being able to override the BadGuy class like if you were programming a badguy in C++ (but it's in squirrel).

Hopefully this will make it less tedious to add scripting features.

If no one wants to tackle this, I can do it after #2621 and #2485

@tobbi
Copy link
Member

tobbi commented Jan 15, 2024

#650 #732

@MatusGuy
Copy link
Member Author

Ye but sqrat sux

@tulpenkiste
Copy link
Contributor

SimpleSquirrel is abandoned, might not be a good idea unless it gets forked and maintained by the SuperTux team (probably not ideal?)

@MatusGuy
Copy link
Member Author

I was thinking about forking, actually. At least it's more recent than sqrat

@Vankata453 Vankata453 modified the milestones: Future, 0.7.0 Feb 12, 2024
@Vankata453 Vankata453 self-assigned this Feb 12, 2024
Vankata453 added a commit to Vankata453/supertux that referenced this issue Feb 20, 2024
Incorporates a SuperTux fork of the `simplesquirrel` library. Most important feature of this library in the context of SuperTux is the ability to easily expose functions, classes (which can include properties) and other entries to Squirrel in one or a few lines.

Every exposed class, variable and function has been migrated to incorporate this change. As a result, the `scripting/` directory, which included all scripting functions, classes and variables, as well as the API wrapper, has been removed, since it is no longer needed for the new binds.

Some scripting functions have been deprecated (currently only via a tag in comment, later to be migrated to docmentation) for several reasons:
* Some `get_` and `set_` functions have been deprecated, since a class property has been added and should replace their usage.
* Functions with the names `get_pos_x` or `get_pos_y` have been replaced with `get_x` and `get_y` for consistency, thus are now deprecated.

This way of creating Squirrel binds would allow for way more flexibility in exposing functions, classes and properties.

**TODO:**

* Expand usage of simplesquirrel functions, instead of ones in `SquirrelVM`, to reduce code duplication.
* Update the scripting API documentation/reference generator to incorporate all changes.

Closes SuperTux#2736.
MatusGuy added a commit that referenced this issue Jul 6, 2024
Incorporates a SuperTux fork of the `simplesquirrel` library. Most important feature of this library in the context of SuperTux is the ability to easily expose functions, classes (which can include properties) and other entries to Squirrel in one or a few lines.

Every exposed class, variable and function has been migrated to incorporate this change. As a result, the `scripting/` directory, which included all scripting functions, classes and variables, as well as the API wrapper, has been removed, since it is no longer needed for the new binds.

Some scripting functions have been deprecated (currently only via a tag in comment, later to be migrated to docmentation) for several reasons:
* Some `get_` and `set_` functions have been deprecated, since a class property has been added and should replace their usage.
* Functions with the names `get_pos_x` or `get_pos_y` have been replaced with `get_x` and `get_y` for consistency, thus are now deprecated.

This way of creating Squirrel binds would allow for way more flexibility in exposing functions, classes and properties.

**Additionally:**

* Removed the `camera()` function, as it only printed the camera position, which is already accessible through methods from the `Camera` itself.
* `Granito` and `GranitoBig` are now scriptable.

## Documentation

Doxygen scripting documentation is now generated for the entire codebase as well, since scripting classes might be found anywhere.

The `@scripting` tag for classes, functions, constants and variables indicates the item should be added to the scripting documentation. Otherwise, it should be ignored.

Added support for the following:

* Enumerators
* Member variables
* Listing of base and derived classes

# TODO

- [x] Expand usage of simplesquirrel functions, instead of ones in `SquirrelVM`, to reduce code duplication.
- [x] Update the scripting API documentation/reference generator to incorporate all changes.

Closes #2736.

Co-authored-by: Tobias Markus <[email protected]>
Co-authored-by: MatusGuy <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants