Engine contributors general

Zeftax

This thread is for general discussion around engine development. If you have any questions or want to make a proposal, you can discuss it here.
For serious proposals, you can create github issue tagged feature_proposal here.
If you have an issue that does not pertain to engine dev, ask a new question instead.

decryptedchaos

I might make a new tag (category) for this soon, give me some time to think it over.

Also, i might have an idea for out of band code contributions, but the problem with it is hosting it cost money. and i haven't really come up with a solution to that for the few people that would use it its hard to justify but we are thinking about it none the less.

Zeftax

Tbh. if it is still hosted on github, it probably doesn't matter, the best would be to accept e-mailed patches or something imo. Separate tag for engine could be good.

Please, could you tell me which of the solutions I described in the discord should I choose? I will re-post the question here for posperity:

I found another bug with the BoneAttachment3D, it is described here: Redot-Engine/redot-engine975 so I won't repeat myself with description.

In set_bone_idx, no change to transformation is made, however it is made in on_skeleton_update, it is all that is done in that function.

When I call on_skeleton_update from set_bone_idx, the behaviour is correct, but the semantics are obviously dumb as I am not updating the skeleton.

Is it preferred to copy the set_transform code from on_skeleton_update to set_bone_idx (around 21 loc) or to create a new private function that handles the transform (all the guts from on_skeleton_update) and call it from both places?
Or I could make it a macro (available only in BoneAttachment3D.cpp), I guess that could work as well. I'm just really not sure what the "project culture" around this kind of thing is.

For reference, this is the on_skeleton_update function, I think all of this code would need to get called from set_bone_idx as well

void BoneAttachment3D::on_skeleton_update() {
    if (updating) {
        return;
    }
    updating = true;
    if (bone_idx >= 0) {
        Skeleton3D *sk = get_skeleton();
        if (sk) {
            if (!override_pose) {
                if (use_external_skeleton) {
                    set_global_transform(sk->get_global_transform() * sk->get_bone_global_pose(bone_idx));
                } else {
                    set_transform(sk->get_bone_global_pose(bone_idx));
                }
            } else {
                if (!_override_dirty) {
                    _transform_changed();
                    _override_dirty = true;
                }
            }
        }
    }
    updating = false;
}

decryptedchaos

Zeftax Tbh. if it is still hosted on GitHub, it probably doesn't matter, the best would be to accept e-mailed patches or something imo. Separate tag for engine could be good.

The idea i had in mind involved, a out of band self hosted git instance (Forgejo) that mirrored my fork on GitHub, PRs could be accepted to the self hosted instance on feature branches and get synced to my fork on GitHub, from there i could send the PRs to the main repo like normal. Although, this would probably only work for my department ReX (feature branch). The main (compatibility) Redot branch maintainer probably wouldn't bother doing the extra work without substantial users wanting it

I think that's the best we could ever do, for the foreseeable future the main Redot repo will almost surly remain on GitHub, and ultimately all the code is going to end up there, so the solution wouldn't prevent the use of GitHub it would just prevent users that didn't want to interact with it from having to do so.

Its the only thing we could really do, emailed patches are almost out of the question as a maintainer, it's just asking for trouble with no paper trail.. the above solution is the only compromise we could come up with..

The root problem here is git at its core was never designed to be decentralized, when it was designed everything was still largely text based, centered around email. Had Linus implemented a protocol standard for pull requests, beyond the request-pull generator we wouldn't have the problems we have today.. if he had this foresight or even the desire to go back and add features like this to git we wouldn't have these problems today

We could simply use git pr <REPOURL> branch and bang suddenly git is decentralized but he didn't. and now that opened the market for places like GitHub to exist, had there been a pre-existing better thought out protocol for this that wasn't based on emails we'd have a much better user experience today where it didn't' matter who hosted the repo.

Zeftax I found another bug with the BoneAttachment3D, it is described here: Redot-Engine/redot-engine975 so I won't repeat myself with description.

As for this, i'll try to direct someone here that can give a better answer, Skeleton/Bone animations are not my area of expertise, but the downside here is going to be loosely related to the above discussion, there are very few active developers on the forum currently as compared to GitHub. so getting answer to stuff like this here will take additional time.

Zeftax

Forgejo is really good, I self-host an instance for all my stuff and I'm happy with it.
Maybe codeberg would host redot on their instance directly without you needing to self host?
I don't think someone that specializes on bones is needed for this, it's just a question of style preference for the engine as a whole.
If I had to guess, I'd say it would be a new private function, but I really don't wanna do something I'm not supposed to, although I guess that's what the review process is for.

mcdubh

I might be able to front some cost soon(tm) after we have a few things squared away IRL.

Zeftax

Due to a lack of clear answer I chose to make it a new private function and opened a PR, please do tell me if I was wrong to do that.

But now I am interested in another question, should we document the code we write? And code we did not write but had to (try to) understand while working on a change? I haven't seen any documentation comments so far, nor have I seen the internal workings documented anywhere else (except the high level overview in the docs, of course).

So, I assume documentation comments are not to be used? Or have they just not been used historically, but actually adding them with time would be a good thing?

decryptedchaos

Zeftax Due to a lack of clear answer I chose to make it a new private function and opened a PR, please do tell me if I was wrong to do that.

The issue your having is one of maintainer style, the maintainer for the main Redot-Engine repo that is primary focused on core compatibility @Spartan322 will have a different opinion of what is good practice than what i would. This is the reason me or anyone else answering this would have almost been pointless. you are sending your PRs to the Redot-Engine repo and i don't manage that repo.

Zeftax But now I am interested in another question, should we document the code we write? And code we did not write but had to (try to) understand while working on a change? I haven't seen any documentation comments so far, nor have I seen the internal workings documented anywhere else (except the high level overview in the docs, of course).

I can't fathom why documenting existing code would be a bad thing but again, that would be up to the maintainer of that branch. For example for my branch ReX we have discussed this and we have taken the position that we can add documentation to code we interact with where needed as to better understand the way it works both for ourselves and anyone else who joins the project in the future.. Its not been made a mandate or requirement as of yet but something we have said we would wouldn't be opposed to for future-proofing