godot-extended-libraries / godot-next Goto Github PK

func _parse_property(inspector:EditorInspectorPlugin, prop_info:PropertyInfo):
	match prop_info.name:
		'health': inspector.add_custom_control(InspectorControls.new_button('Take Damage', false, self, 'take_damage'))

If you change the function above in a built-in script, the changes only apply when the project is restarted.

(Also how to add a button under a property instead of above?)

For this project and godot-journey, there are C++ scripts that need to exist. I would prefer to make compiling these scripts follow the same workflow that Godot Engine uses, with several sub-libraries compiled in a single execution, and built on the same infrastructure as it and the C++ GDNative bindings use for consistencies' sake: scons. This means writing an SConstruct file that can accommodate all of the projects' needs.

What I think would really be useful here is a script that will meet the requirements of any arbitrary combination of NativeScript C++ projects. I believe such a script would have the following requirements:

• Allow multiple GDNative bindings versions to be supported so that users can store multiple bindings in a single directory and then select which bindings they want to use on command.
  • Perhaps also enable the script to download and store the GDNative bindings files in a centralized location, and manage the files for the user? That way the user just has to install git, but doesn't necessarily need to know how to use it. They can just install scons, run it, and it will do a git clone of the depended-on GDNative bindings for each project automatically.
• Allow multiple GDNative projects to exist within the compilation framework such that a single scons command can build several dynamic libraries all at once.
  • Users should be able to configure which version of NativeScript each project will compile with.
• Allow the compilation of these projects to automatically generate updated GDNativeLibrary and NativeScript resources (.gdnlib, .gdns) in configurable directories.
• Allow the GDNative projects to specify other projects to include as dependencies within the compilation framework's script.
  • Dependencies would be compiled first as libraries and then the library would be included in the dependent library.
  • Dependencies would need to keep header files in a dedicated directory so that other projects can more easily access and include those header files in their compilation workflows.

Based on my limited knowledge of scons and Godot's module system, I think the per-project-customization features would involve each project having an SCSub file which could then be used by the top-level SConstruct script to plug into the compilation framework. Bonus points if we can program the scons script to generate a template SCSub file for an arbitrary project. Bonus-Bonus points if we work out a way to integrate all of this with a custom Godot resource that can replace the ongoing/unfinished work in the godot-builder repository.

I'm using the Bitflag class, the following function (when you place the Bitflag.gd into project folder) pushes the following error:

Workaround
the only workaround I've found was commenting the mentioned function, but the class itself still works

Godot info
Using Godot 3.2.3 RC2

can we have utility scripts for the following?

• 2d drawing
• 3d drawing
• 2d physics movement and collision
• 3d physics movement and collision
• pathfinding
• generation
• input and input binding
• gui

the idea of this suggestion is that we can use a ecs workflow and implement our own nodes

It would be nice to have a DateTime class. It will be particularly useful when working with arrays of dates or other data structures that have a date as an attribute.
Expected features: Support for Gregorian calendar operations. Eg: date_time_obj_1 . days_to ( date_time_obj_2 ) returns the difference between the two DateTime objects in days.

Users may need Behaviors associated with a CallbackDelegator to initialize in a particular order. Right now, it is initialized based on whatever order the internal Dictionary provides them. Since that may be different depending on how they've been inserted and isn't easily controlled by the user, we need to come up with a method of assigning a priority order to the behaviors.

We should probably expose a priority API for a CBD's behaviors. One option would be to store them in an Array as well as the Dictionary. Its simpler, and guarantees that the priority range is composed of exclusively the allowable order. Alternatively, we could use a priority map Dictionary to assign priorities to them. This makes the process of initialization more complicated though as there isn't a specific ordered list of behaviors to initialize.

• markdown 1

• 2

    code sample
  

hello

willnationsdev/log#35

Similar to the Unreal Engine 4 Widget Switcher, this would just make it easier to "toggle" nodes associated with a Set rather than just an On/Off for the group.

The Switcher itself shouldn't have any visual aspects to it. As such, it should likely extend Control.

The Switcher should be able to switch based on an index (the index of the child) or by the name (searching for that child), making the given node visible and all others hidden.

The "keys" used to do this should be exported, and there should be a setter for each of them that also sets the other key accordingly.

This would be to allow people to have more direct drag-and-drop functionality available to them.

Hey, I've made this with someone : https://github.com/MatejSloboda/Dijkstra_map_for_Godot
Its in rust and it allows for things astar does'nt provide, we're currently searching for a way to ship the binary directly (it doesnt work off the bat right now) but once that comes (or before?), Does it belong here? :)

As it is, a ResourceCollection can only "decide if it should store a thing" based on a "property name" that one passes into can_contain. There are several issues with this:

1. It is only as relevant as it is contingent upon the ResourceCollection being used with an EditorInspectorPlugin as demonstrated in the Behaviors class. If one does not use it for this purpose, then the parameters of can_contain do not enable users to adequately determine whether storing the value is suitable.

2. It does not allow one to check other qualities of the evaluated property such as its type, value, sub-properties, methods, etc.

We should probably devise an alternative evaluation method that avoids these problems.

can we get the following nodes?
GameObject2D
GameObject3D

these nodes would simply only be a 2d/3d transform, a enabled property and components

the main reason for this suggestions is so that we can use a ecs workflow and static utility functions to implement our own behaviours and logic.

Is there any plan to port this to godot 4? Or does this already exist somewhere that I missed?

These look really helpful :) would love to use them

I am currently using this plugin to load in custom classes by class name and it does work but whenever i try to export my game, it does not work and errors. I tried asking on the godot discord and they said that

You (or the plugin developer) are trying to use EditorPlugin class, a class that belong to the editor only and doesn't works in game

SCRIPT ERROR: Parse Error: The identifier "EditorPlugin" isn't a valid type (not a script or class), or couldn't be found on base "self".
          at: GDScript::load_byte_code (res://addons/godot-next/references/class_type.gdc:726)

When using the libraries, all exports to the Android platform fail with the error:
SCRIPT ERROR: Parse Error: The identifier "EditorInspectorPlugin" isn't a valid type (not a script or class), or couldn't be found on base "self".

I know that there's android plugin from dis/doh -> https://github.com/DisDoh/GodotBluetooth

it's a fork and its ok but i tried so hard and cant get running it will be awesome to manage bluetooth or other sensors from android.

i'm really interested in bluetooth because am i building an app that sends to arduino via hc 05

Without godot-next in a project, one can double click on a node to change it's name.

For some reason having godot-next in a project disables this.

A workaround is to right click the node on the scene tree and click rename.

I can't find anything like this, but it would be very nice to be able to do long trails that have less points in them, by being able to change something like "update frequency" ..you might get slightly less smooth trails but when spawning massive amount of missiles performance would drop less.

Hi Guys I love your godot-next project I just wanted to propose that a gradient coloring scheme should be added to the trail 3D so as to allow something like this:

But in a 3d space but I really don't know if that's possible so am hoping for a feedback

I just found this repo. My personal vector helper class has the following functions that could be useful to others.

The controllers in Godot give you a value from -1 to 1 for both the x and y. Some math operations require a more normalized version of the input, but just doing vector.normalized() chops the vector short instead of properly scaling it. In other words, you get this:

The more proper way to do it and eliminate these "dead zones" in the corners, is to map the square space to a circle space.

Inversely, mapping the circle-based normals to a square would look like this:

For a bit more info on the math, this blog post does an ok job explaining: http://squircular.blogspot.com/2015/09/mapping-circle-to-square.html

Below is my implementation. Feel free to tweak it to make it faster.

const __2root2 := 2.0 * sqrt(2.0)

# Map a circle grid to a square grid
# input: vector from a circular domain with radius of 1
# output: vector in a square domain from (-1,-1) to (1,1)
static func map_circle_to_square( xy :Vector2 ) -> Vector2:
	var x2 := xy[0]*xy[0]
	var y2 := xy[1]*xy[1]
	return Vector2(
		0.5 * (sqrt(2.0 + x2 - y2 + xy[0] * __2root2) - sqrt(2.0 + x2 - y2 - xy[0] * __2root2)),
		0.5 * (sqrt(2.0 - x2 + y2 + xy[1] * __2root2) - sqrt(2.0 - x2 + y2 - xy[1] * __2root2))
	)

# Map a square grid to a circular grid
# input: vector from a square domain from (-1,-1) to (1,1)
# output: vector in a circle domain with radius of 1
static func map_square_to_circle( xy :Vector2 ) -> Vector2:
	return Vector2(
		xy.x * sqrt(1.0 - xy.y*xy.y/2.0),
		xy.y * sqrt(1.0 - xy.x*xy.x/2.0)
	)

Also, if this doesn't seem useful to anyone else, feel free to scrap this issue. I just know these took me a long time to find and figure out.

Can someone point me to the section which allows attaching multiple cSharp scripts per node?

noticed that assert false is throwing errors. in Godot 3.2 beta x

Changed to assert(false) then it allows me to run the project

hi, i would like to propose the addition of 2D Array as an Object just like Array is
he is a post ive created in reddit that demonstrates sort function in a 2D array

https://www.reddit.com/r/godot/comments/78kp8x/bubble_sort_for_2d_array/

the 2D array in the post is sorted according to their rows.

if it will be an Object in Godot, here are some of its functions that i would like to propose

• Array2D.sort_column(int,bool) #int = number of column, 0 is the start. bool = true if ascending order
  sort the Array 2D accorring to the column selected
• Array2D.sort_row(int,bool) #int = number of row, 0 is the start. bool = true if ascending order
  sort Array 2D accourding to the row selected

here are just some. really love Godot and this is what i think it lacks (as well as Batching)

You can save the data into the scene, and the data shows up inside the scene file, but the node doesn't correctly reload the data if you close and re-open the scene.

cc @xDGameStudios

When testing or simply reviewing some of the new features to be added, there's no project.godot with the demos. I think it would be worth to provide a place to experiment with all the neat features. A single project would be enough imo.

The root project.godot could act like any other real-life project, as if you already installed the plugin.

Trying to learn how to use this. I'm using 3.1.1 Official.
So I got this script:

tool
class_name Walk
extends Behavior

export var speed = 10

When I press on that + button, I get this message:

 res://addons/godot-next/resources/resource_collections/resource_set.gd:58 - Invalid call. Nonexistent function 'new' in base 'GDScript'

From the README file:

All C# scripts must be submitted to a *-cs branch, e.g. master-cs, 3.1-cs, etc. This is to ensure that users who aren't using the Mono-enabled version of Godot do not have C# scripts present.

The master-cs branch is unmaintained and does not actually contain any C# scripts anyway. Therefore I propose deleting it and removing all references to it.

If in the future people do wish to add node extensions with C# scripts, I think that having a separate folder would be better, either /addons/godot-next-cs or /cs/addons/godot-next-cs. The current approach of having different branches is a bad idea. It leads to increased difficulty to maintain everything and/or the branches going unmaintained.

Additionally, perhaps some of the other branches should be looked at too.

Right now ResourceCollection requires you to set a script for the base type. This makes for some UI that is sort of clunky and hard to figure out. (at least for me) But I discovered something recently with EditorResourcePicker. Basically, it has a base_type property which takes a name string of the base type and filters the list down to that class and its inheritors. You might assume this doesn't include custom resources (as is the case for nearly everything else in the engine that uses class names as strings), but it does!

This would allow us to include engine classes as well as an overall more intuitive UI. It would, of course, require the user to register their class, but I think that's a reasonable ask.

Attaching the Trail2D to a item such as a bullet in a asteroid like game where the bullets wrap around the screen (exiting right, entering left) makes the trail streat over the screen.
Would be brilliant if this was solved internally in the Trail2D node.

Thanks for an awesome addition to Godot !

Making a check call from a BitFlag using BitFlag.<name> results in the script check failing because the value is an integer which can't carry scripts.

enum InputPanDirection { Left, Up, Right, Down }
var _direction = BitFlag.new(InputPanDirection)
_direction.check(_direction.Right)

Hi! I've had this idea sitting in my Notepad for a while, and I'm not sure what to do with it.

This idea is the ValueRecorder, which will record the values of all its sources every time a update() method is called on it. I've also included a AutoValueRecorder node as part of this suggestion, which would handle a common (and easy to implement) use case of recording sources every frame.

Below is a sort of summary of what I wrote down in my notes -- what I would consider my ideal ValueRecorder to be. There's no obligation to implement it exactly as I describe it, though.

Apologies for the long post, by the way -- I had a lot on my Notepad, and thought I might as well share what ideas I have for it already.

ValueRecorder

Every time a update() method is called on ValueRecorder, this takes in a number of sources (whether properties or methods) and keeps a record of the last so many values. A program can then access this record later and perform various actions based upon them.

Potential use cases

• Recording a drawing being drawn -- record what new and changed pixels exist every time we paint onto a canvas -- then be able to play it back without any pauses between actions.

• Making trails behind a character -- this could easily be implemented by other means, but if you have a ValueRecorder, it will handle tracking of the positions for you.

Potential API for ValueRecorder

• Multiple sources -- add_source(target: Object, property: NodePath) for recording properties, and add_source_method(target: Object, method: String) for recording the result of a method (or for when a property just wouldn't make sense) -- and the relevant methods for removing sources.

  • Potentially, if the method specified by add_source_method returns nil, we could avoid recording that source for that update (though all other sources would still record as normal).
  • I don't know how we should handle the possibility of sources being inaccessible. In my own notes, I wrote down that it could stop recording values altogether -- but perhaps there's a better way of handling that?
  • Also, we should definitely make sure that the values it records are copies of the data.

• recorder_length -- how many of the last n records that will be kept... perhaps nil will infinitely record the sources?

• Potentially, a signal for whenever we hit recorder_length number of records -- this might allow us to... say, dump to disk the inputs we currently have recorded, such that we aren't doing IO every frame.

• Potentially, a means to save and load the recorded data -- or perhaps serialize it into an Animation for use in an AnimationPlayer?

AutoValueRecorder (Node)

This would be a utility node that automatically calls update() on an internal ValueRecorder every frame. I'm suggesting this simply because I think the use case of recording data on every frame would be a common use case for ValueRecorder, and so it'd just be easier to include a Node that does this for you.

Potentially, instead of always recording every frame, a AutoValueRecorder could have some sort of interval property, where it will only record values every so often rather than every frame.

Potential use cases

• A input buffer -- Keep track of every input within the last 30 or so frames, and if a jump action occurs just before the player hits the ground, you can repeat the jump (even if the player was not pushing "jump" right as they hit the ground)

• Replay recording -- Keep track of the player's actions as they play through a level -- then allow them to save a replay at the end of the level, that can later be played back.

• Statistics over time -- for example, the ValueRecorder could be used to implement a graph that displays FPS over the last 15 seconds or so.

After godotengine/godot#60581 was merged, Godot's 3.x branch now officially includes the same Tween system as in Godot 4.0 (as a separate class, SceneTreeTween), which is based on TweenSequence, but superior in many ways. Thus TweenSequence class can now be removed. Also it became incompatible with the newest 3.5, as Tweener class shadows the Tweener in core.

For anyone who wants to continue using TweenSequence in the newest Godot 3.5, they need to rename all Tweener classes to e.g. Tweener2, PropertyTweener2 etc. They are used only internally, so it will be fine.

But I'd suggest everyone to just switch to the new SceneTreeTween. Here's a quick migration guide:
var tween = TweenSequence.new(get_tree()) -> var tween = create_tween()
tween.append(...) -> tween.tween_property()
tween.append_advance(...) -> tween.tween_property(...).as_relative()
tween.append_interval(...) -> tween.tween_interval(...)
tween.append_callback(...) -> tween.tween_callback(...)
tween.append_method(...) -> tween.tween_method(...)
tween.set_loops(x) -> tween.set_loops(x + 1)
tween.set_speed(...) -> tween.set_speed_scale(...)

Aside from these renames, the new SceneTreeTween (and Tween in 4.0) API is compatible with the TweenSequence code. SceneTreeTween will also work much more reliably.

I came here from this video

however there is no initialize button like in the video and I get a error when I click on the base type box

I am using godot 3.2.1 btw

I came across this repo some months ago, and there's a lot that is very useful. Is there someone actively maintaining this? And if not, is there any fork that is being maintained?

I think a bunch of what's here could be ported to Godot 4, this is great engineering that could be useful for so many projects. I hope this doesn't get forgotten

We should add clang-format to the codebase so that any added C++ code will have consistent styling. We should probably use the exact same clang-format as Godot's source code for consistency.

touch support, momentum and spring effect.

Just imported the library within Godot 3.1.1.
Have the following error in line 30: Assertion failed.

In Godot, I sometimes find that I would like the ability to draw lines in 3D. I think that such a thing might be a useful node to have in this node extensions repo.

Possible functionality:

• Pass two points and have it draw a line between them

• Pass an origin point and an offset, or a direction+magnitude

• Pass an array of points and draw lines between all of them (index 0 to 1, then 1 to 2, etc)

• Ability to set the thickness of the line

• Ability to set color of the line, perhaps each end having a different color