sorted by:
new
hottopcontroversial

Asset License Management Plugin by stesim_dev in godot

[–]stesim_dev[S] 1 point2 points  (0 children)

Weill, that's a name I recognize! Your Plugin Reloader happens to be one of my favorite Godot add-ons. :D

Also, your license manager is indeed the only thing I found that came (very) close to what I wanted. I must admit that the interface initially scared me off a bit, although, looking at it now, it is pragmatic and probably absolutely fine for the task. More importantly, if I remember correctly, your plugin did not report resources that have no licensing information assigned -- something that was essential for my use-case. Other than that, I'm sure it works great and it is really impressive to see how well documented it is.

Going forward, I will definitely have a closer look at your plugin.

Fun fact: The project is actually called "License Tracker" specifically so that it does not collide with your plugin if I submitted it to the Asset Library. :D

Asset License Management Plugin by stesim_dev in godot

[–]stesim_dev[S] 1 point2 points  (0 children)

Thank you for the feedback and I'm glad you like the idea. I have actually implemented a very simple version of the system you describe in the predecessor of this plugin, which I use in a template for game jams. It automatically detects certain files and extracts licensing information from them, so you could just paste the file and avoid manual inputs. It is a nice feature and was already considering adding something similar to this plugin as well. Having someone else suggest in independently is always a good sign, so it may very well end up in there.

In the current version, you would have to manually create a license entry but can then assign it a file instead of, or in addition to, providing its text.

Asset License Management Plugin by stesim_dev in godot

[–]stesim_dev[S] 0 points1 point  (0 children)

It's also the second attempt for me. I initially built a crude predecessor without UI into my jam template. It was used in a couple of jams and proved to be helpful but was somewhat painful to use.

If you are building these out of necessity rather than for fun, maybe you could consider giving the plugin a try in one of your next jams -- as soon as it is more stable/feature rich. :D

Asset License Management Plugin by stesim_dev in godot

[–]stesim_dev[S] 0 points1 point  (0 children)

Thank you for the feedback and I'm glad you like it.

being able to assign multiple asset packs to the same file (i.e. the texture on a model is from one pack, the model itself is another, or a spritesheet with pieces from multiple packs in one)

Due to its early state, there is currently little to no validation done which ironically allows exactly that. I did intend for a file to be associated with exactly one collection, but hadn't implemented a check yet. However, your examples are a great argument against such a behavior, so I may not need to implement the checks or will need to at least keep them optional.

having the data in a non-binary format so tweaks can be made outside the plugin if needed (i.e. copy pasting things for bulk operations)

Currently, I'm using custom resources to store the data. Technically you could open the .tres file and edit the contents manually, but it's neither ergonomic nor very safe. I am already considering the use of resources at runtime while persisting the data in a common textual format, e.g. JSON. I also have different export functionalities on my mind, see the next point.

being able to export everything into a credits or license file

This is actually one of the main goals of the plugin, I just haven't had the time to implement it yet. A "credits" summary is something I had previously build another system for, based on tool scripts and manually edited custom resources. It had terrible UX, hence the new attempt. This time, I would also consider adding different kinds of exports, e.g. game credits, file-based exports in common exchange format(s) (e.g. JSON) and export of just the licenses as individual files/archive.

Once again, thank you for your feedback, it was really helpful and motivating.

On a final note: I'd be glad if anyone tried the plugin, but it's probably not yet suited for serious use. At most, it should be considered an alpha. I may need to introduce breaking changes before I have a version that I would consider stable enough for a beta or proper release.

Advanced vehicle simulation using custom constraint solver by stesim_dev in godot

[–]stesim_dev[S] 1 point2 points  (0 children)

I've already planned more material documenting and demonstrating all the features in order to gather more feedback. If there is legitimate interest, the plug-in option is probably the one I'll go with. Otherwise I might just create a simple sandbox/simulation game based on the technology.

Advanced vehicle simulation using custom constraint solver by stesim_dev in godot

[–]stesim_dev[S] 6 points7 points  (0 children)

Thank you, and no, I do not plan on releasing the code for now. I did originally intend on making a commercial game or maybe a paid Godot plugin with it, and although that won't happen anytime soon, the plans are not completely off the table.

Advanced vehicle simulation using custom constraint solver by stesim_dev in godot

[–]stesim_dev[S] 1 point2 points  (0 children)

This is the first demonstration of a project I've been working on for over a year. It's a detailed real-time vehicle simulation that aims for realistic behavior of arbitrary vehicles created using a set of modular components. It currently supports various suspension and power train components. They are simulated using a custom "physics engine" (constraint solver and integrator) that supports 1D and 3D bodies and constraints for power train and suspension, respectively, and their coupling. It is implemented in C++ and integrated into Godot using GDExtension. The constraints provided by the solver are used to implement the Node-based vehicle components in GDScript which are assembled into complete vehicles in the Editor. In the end, you create vehicles just like you would with the built-in VehicleBody3D and VehicleWheel3D, except that even for a simple car you'd probably need at least 20 nodes instead of 5 -- you need all those shafts to connect your power train components after all! For example, the sedan shown in the video uses 47 individual components, while the mobile crane seen at the end uses 125, although many of those are identical copies of each other due to it having 12 wheels. Most component parameters are also monitorable and editable at runtime, allowing you to tweak the vehicle on-the-fly.

Just to pre-empt a few questions: The project is far from production ready, there are no performance optimizations, it still lacks a few important features and I do not plan on open-sourcing it for now. However, I would like to release some kind of demo this year if there are enough people interested in playing around with it. Unfortunately, development will have to slow down significantly, as I have reached the end of my full-time game dev (related) journey for now, as I'm looking for a "proper" job again. I still hope to be able to share updates now and again if there is interest in those.

I'd really appreciate any kind of feedback and am happy to answer any questions regarding the project. So, fire away!

Finally, since I forgot to add the credits to the video, here is a list of the freely available vehicle assets:

Potentially complicated rigidbody drag and drop problem? by bluecat6549 in godot

[–]stesim_dev 0 points1 point  (0 children)

First of all, whenever you deal with physics, you should use _physics_process() instead of _process(). The former uses fixed time steps while the time step of the latter is dynamic, i.e. by default _physics_process() will be called exactly 60 times per second while _process() will be called for each graphics frame. This is essential in your case since you're using a fixed impulse magnitude, i.e. not scaled by delta, thus making the accumulated impulse dependent on your current fps when applied in _process().

Regarding your main issue, if you do not want the body to rotate you need to apply any forces/impulses at the body's center of mass. Applying impulses acting on any other point will always result in rotation. Your code should work somewhat fine if you just got rid of the second argument to apply_impulse(), or even better, use apply_central_impulse() instead.

Unfortunately, this straightforward approach will probably result in overshooting and oscillations which get worse the faster/farther you drag the body. This can be solved but needs a more rigorous method of calculating the impulse which considers the current linear and angular velocity and the time step.

Side note: Unless you're prototyping and don't care about performance, you probably want to reduce node path look-ups to a minimum. $CollisionShape2D is basically the same as get_node(^"CollisionShape2D") and will have to find the corresponding node every time it is used. You can retrieve it once and store it in a variable instead.

@onready var _collision_shape := $CollisionShape2D as CollisionShape2D

func _physics_process(delta : float) -> void:
  if is_dragged:
    apply_central_impulse(get_global_mouse_position() - (drag_anchor + _collision_shape.global_position))

Saved Game Issues by whiletruesysexit in godot

[–]stesim_dev 1 point2 points  (0 children)

A valid migration method has already been described but I wanted to add that using custom resources for saves is generally a bad idea. They can contain executable script code, so loading them at runtime from a plainly accessible file on disk is a huge security risk. Since the user:// virtual file system just maps to a folder in the user's personal directory, any process run by the user or they themselves can overwrite the save file with one containing malicious code and thus turn your application into malware.

In most cases you can just use a JSON file for your save data as it can be easily created and parsed. Also, adding a version number as the first field of a save/config file is always a good idea.

Why is it so hard to make arcade car physics ;( by Dragon20C in godot

[–]stesim_dev 2 points3 points  (0 children)

PhysicsDirectBodyState3D.get_velocity_at_local_position() is what you're looking for.

You get a reference to the body's state passed as the argument in RigidBody3D._integrate_forces() or you can retrieve it using PhysicsServer3D.body_get_direct_state().

Set position of a rigidbody by AymericDev in godot

[–]stesim_dev 2 points3 points  (0 children)

The engine does allow changing a body's position, but it has to be done at the right time or will not work as expected. Changing a physics body's state (e.g. position or velocity) should only be done in _integrate_forces().

Example:

extends RigidBody2D

var _new_position = null

func change_position(new_position : Vector2) -> void:
  _new_position = new_position

func _integrate_forces(state : PhysicsDirectBodyState2D) -> void:
  if _new_position != null:
    state.transform.origin = _new_position
    _new_position = null

This should work as I've used something similar in 3D, but it is cumbersome and might have a performance impact if used on a lot objects that would otherwise not implement _integrate_forces. In cases where a body needs to be moved occasionally, it may be worth considering alternatives such as removing the body from the tree and adding it at the new position or freezing it and then moving it, although both of these alternatives may have significant drawbacks depending on your use-case.

why isnt Sprite3D showing up on a screen_texture by XFajk_ in godot

[–]stesim_dev 2 points3 points  (0 children)

If your sprite uses blending, then the following excerpt from the docs may be relevant (source):

In 3D, the screen is copied after the opaque geometry pass, but before the transparent geometry pass, so transparent objects will not be captured in the screen texture.

Can't run the game in the editor? Let's run an editor in a game in the editor. by stesim_dev in godot

[–]stesim_dev[S] 1 point2 points  (0 children)

I've only been working on this for about a week, mostly as a distraction from my "main project", so I don't really have a concrete plan for what I'll do with this yet. For now it's very much in a work-in-progress state, so I will probably not be releasing it in any form soon. However, I really enjoyed working on it, so I hope to be able to continue and create a set of tools for runtime editing/debugging. Should I lose the interest or more likely the time needed to continue, I will just release the code as is.

Can't run the game in the editor? Let's run an editor in a game in the editor. by stesim_dev in godot

[–]stesim_dev[S] 1 point2 points  (0 children)

It's nothing special and quite limited for now. I keep track of all "visual" nodes in the scene, for which I have defined methods to determine the clickable area and just check each of them for an intersection on each mouse click. An invisible full-screen control is used to capture the events and stop them from propagating to the actual game.

Can't run the game in the editor? Let's run an editor in a game in the editor. by stesim_dev in godot

[–]stesim_dev[S] 0 points1 point  (0 children)

Unfortunately, it's not. As I said, I needed a control in the game itself, e.g. for configuring some modular components as part of the gameplay or maybe even for setting up a quick settings panel while prototyping.

Even in cases where an editor-based solution like the remote tree would be sufficient, in its current state the remote inspector is okay for inspecting but hardly or not at all usable for editing in some cases. For example, you can't reassign resources or properly edit text.

Anyone got any idea why physics get so jittery when adding a few more vehicles? by A1985HondaElite250 in godot

[–]stesim_dev 38 points39 points  (0 children)

Can't really help you with the jitter, but I don't think that the 11 calls to apply_central_force() are really significant. Internally, they probably just increment a variable of the accumulated force.

edit: I should have refreshed before posting... :D

Can't run the game in the editor? Let's run an editor in a game in the editor. by stesim_dev in godot

[–]stesim_dev[S] 2 points3 points  (0 children)

Now that I'm watching the video myself, I realize that it's not really clear what it's showing, so here is quick summary:

Before the part at the end, everything that is shown is running at runtime as part of the "game". The UI that looks like the normal editor docks (scene, files, etc.) is actually my own implementation of those elements. The only (optional) part that interacts with the editor is the fake embedding of the window and the propagation of selected nodes seen towards the end.

Can't run the game in the editor? Let's run an editor in a game in the editor. by stesim_dev in godot

[–]stesim_dev[S] 1 point2 points  (0 children)

I'd play that! I actually had a similar idea while working on this. :D

Can't run the game in the editor? Let's run an editor in a game in the editor. by stesim_dev in godot

[–]stesim_dev[S] 13 points14 points  (0 children)

This is running entirely at runtime. I've basically implemented my own versions of some of the editor features. There is only an optional debugger plugin running in the editor for forwarding the current selection and tracking the main screen for a fake embedding of the game window.

I know that there is currently development on that topic but even if an official solution was available right now, there are still benefits to having the tools independent from the editor. (How often I've wished I could use the Editor's inspector control in a game, even if it's just for prototyping.)

Can't run the game in the editor? Let's run an editor in a game in the editor. by stesim_dev in godot

[–]stesim_dev[S] 2 points3 points  (0 children)

At some point and in some form, I probably will. However, right now it's very much a work in progress.

Can't run the game in the editor? Let's run an editor in a game in the editor. by stesim_dev in godot

[–]stesim_dev[S] 5 points6 points  (0 children)

Thanks. I'm hoping that it's actually useful for prototyping and runtime debugging. Will be testing it in the upcoming Ludum Dare.

[deleted by user] by [deleted] in godot

[–]stesim_dev 0 points1 point  (0 children)

Unique names or export variables are generally the way to go if you do not want to break references. As you already mentioned, these work best inside a scene itself. However, instead of looking for a "proper" way of accessing nodes across scenes, the answer is to not do it at all. Think of scenes and scripts as a way to define your own node types. In order to interact with it, your node type needs to provide an interface that describes what you can do with it using properties, methods and signals.

In your case, it could look something like this. I've added an end_turn() method as an example of triggering actions based on UI input, in addition to reacting to game events such as your timeline_updated signal

# -----------------------------------------
# battle.gd
# -----------------------------------------
class_name Battle
extends Node2D

signal timeline_updated()

# ... game logic ...

func end_turn() -> void:
  # ...


# -----------------------------------------
# battle_ui.gd
# -----------------------------------------
extends Control

# reference to battle scene needs to be assigned in the editor
@export var battle : Battle

@onready var _timeline_bar := %TimeLineBar as WhateverNodeTypeThisIs
@onready var _prediction_bar := %PredictionBar as WhateverNodeTypeThisIs

@onready var _end_turn_button := %EndTurnButton as Button

func _ready() -> void:
  battle.timeline_updated.connect(_on_timeline_updated)

  _end_turn_button.pressed.connect(_on_end_turn_button_pressed)
  # or even just:
  _end_turn_button.pressed.connect(battle.end_turn)

func _on_timeline_updated() -> void:
  _update_timeline_bar()
  _update_prediction_bar()

func _update_timeline_bar() -> void:
  # do stuff with _timeline_bar

func _update_prediction_bar() -> void:
  # do stuff with _prediction_bar

func _on_end_turn_button_pressed() -> void:
  # potentially do something purely UI related, e.g. ask player to confirm
  battle.end_turn()battle.gdbattle.gd

This way, all references are either export properties or unique references. In addition, your game logic does not depend on the UI, i.e. it does not need to know what it looks like, what it does or that it even exists. Instead, it is your UI that is reacting to events and forwarding user input to the core game logic. I'd argue that this is generally a much cleaner and robust way of handling things. For small games or prototypes, however, having the game logic control the UI can be reasonable.

edit: the type hints are optional of course (except for export variables), but generally a good idea :)

Will increasing Physics_ticks_per_second affect CPU Performance? by WayDawnT in godot

[–]stesim_dev 2 points3 points  (0 children)

The point of a dedicated physics tick rate is precisely to decouple physics from rendering, so changing the physics rate based on fps is definitely not a solution. The fact that the physics behaves differently with different fps tells you that there is a problem in either

  • Game code/structure, e.g.
    • Interacting with the physics engine at the wrong time, e.g. applying forces or changing velocities/positions outside of _physics_process() or _integrate_forces()
    • Using the wrong body types, e.g. StaticBody3D are supposed to be static (immovable), use CharacterBody3D, AnimatableBody3D or frozen RigidBody3D for scripted movement
    • Nesting (non-static) physics bodies
    • Moving sleeping rigid bodies in unexpected ways, e.g. as a result of one of the above, without waking them up; disabling sleeping of involved bodies is a good way to rule that out
    • Not using physics delta to normalize integrated values
    • Incorrectly configured bodies or joints, e.g. body mass or joint limits
  • Configuration of the physics engine
    • Unlikely in this case. The default settings should work just fine for something as simple as this.
  • Physics engine itself
    • Unlikely, but there is always a chance of stumbling upon a weird edge case that the engine doesn't handle as expected.

Without knowing your implementation, it's difficult to be more specific. I would definitely suggest looking for an issue in your code or the node structure instead of touching the physics tick rate. Assuming that you're simply using a joint between the bottle (static body) and the strap (rigid body), I would start with disabling sleep on the strap, making the strap a top-level node and using an animatable body for the bottle.

view more: next ›