Changes in Urho3D Contribution Checklist

I propose to remove the following items from Contribution Checklist

For all code (classes, functions) for which it makes sense, both AngelScript and Lua bindings should exist. Refer to the existing bindings and the scripting documentation for specific conventions, for example the use of properties in AngelScript instead of setters / getters where possible, or Lua bindings providing both functions and properties.

Unless impossible due to missing bindings (see above) new examples should be implemented in all of C++, AngelScript and Lua.

I know that these rules are (were) important to keep Urho3D API consistent among C++, AS and Lua.


Let’s be honest with ourselves. Everybody hates writing bindings.

For Lua you should locate some files outside the project and add things, for AngelScript you should write binding string properly, and if you are not careful enough, everything will explode. You should either be very attentive or test all bindings manually. Perfectly both.

To make these samples you should recall “foreign” script language and spend x2-x3-x5 time to port your C++ code.

This actually draws Urho into stagnation. It’s much easier for many people to maintain their own diverging forks than to follow these rules and make PRs.

I think that engine developement is more important than script API completeness.

So I suggest to drop these requrements and let code flow.

Of course, existing bindings shall be maintainted.

Of course, it is appreciated to implement script bindings or even port samples.

Script bindings could be implemented in separate PR or requested in issue and implemented on demand, like any other suggestion.

If there is a volunteer who is ready to write bindings, that’s perfect.

In summary…


  • More PRs from people who don’t need bindings and don’t like writing bindings
  • Stimulate people who actually need bindings to make PRs and develop the project.
  • No time wasted for bindings that nobody actually use.


  • Script bindings become a kind of downstream projects behind the head.

Personally, I would throw out LUA from engine (but keep Angel Script), but for sure there are people who like LUA. It may be necessary to conduct a survey to find out how many people use LUA in their practice (personally I often use AngelScript for small test programs).


Our community is already small as it is. I think we should keep those LUA users by outside. Thank you. In fact so far we don’t treat them as second class citizen. The way we have setup currently has made the script binding to require a small amount of work. Adding a few line in the pkg for LUA or the *API.cpp for AS is hardly time-consuming. We should also value maintainers more than contributors. A contributor would just drop the code here and expect the maintainer to keep them from rotting. Now if the would be contributor is already too lazy to maintain the would be contributed code to be compatible with all our supported APIs then there is little hope to think or ask the same person would still be here to maintain or fix the contributed code in the future.

So, I would vote against this move.


When you tried to do it last time on your own? For some reason I think that if you were writing script binding regularly, you would have other opinion.

If contributor add two simple functions, it’s quite easy to keep binding up-to-date.

If contributor add two new classes with hundreds of functions it may take whole day or two to make bindings and port samples. Especially if functions are not easily bound to scripts via standard binders.

Every time when contributor change any header, he has to go to both bindings and fix them. Then he has to fix both samples and ensure that they are running.

Such rules doesn’t filter away lazy people who will not maintain their own code in the future.
Such rules filter away people who don’t need Lua & AS bindings and don’t want to spend time to maintain it.

I understand that personaly I will not push into Urho some code just because personally I don’t need bindings for it. And I’m not the only person who avoids contributing because of this reason.

Our current rules literally push people away from contributing anything big.
At the same time, our current rules forcibly increase scope of maintenance even if nobody really need it.

PS. Any updates on Community Modules?

This is absurd. I don’t believe I have to show you what I have done or have not done to proof my point. I also don’t believe doing the after the fact binding would make the contribution rate any faster. On the contrary I believe it will make developer to take shortcut and may allow them to make a bad design decision and only to find out later when the actual binding is made. Those rules are made by Lasse then when he did most the things and I have never heard him whining.

I don’t ask you to show anything to proof.
I just wonder if you tried to maintain bindings and especially script samples on your own. To be sure that you understand the amount of work. Especially for a contributor who don’t know Lua and AS.

So I pin my hopes on community repos. It may become nice sandbox to try less strict contribution rules and analyze results.

Huh… Didn’t think about this point.
What about bad binding design (or even buggy binding) by people who are C++ developers and never used neither Lua nor AS?

You forget about there is still reviewer who approve or reject the PR and that our CI is non-forgiving. A bad AS binding would crash the Urho3DPlayer more often than not. And yes, I have done some bindings works in the past, so I know exactly what it entails.

Just want to chime in that by me (although I don’t have official say as such anymore) it’s fine that you change the contribution rules. It’d be good if you then communicate clearly that the script subsystems have been made, to a degree, second class citizens, because that is the inevitable end result.

I certainly noticed Urho is to a degree a “matrix of death” ie. platforms, subsystems, script APIs.

Typically script API binding troubles are related to containers, and you can note it in the C++ API sometimes, e.g. the pattern of providing indexed setter and getter functions. You would probably be able to make a smarter C++ API overall if you didn’t need to think of bindings at all.

1 Like

Bindings are a big point of pain. When i make a change and think should i submit a PR first thing i consider is if i will have to write bindings. More often than not answer is “yes”, and it simply is easier to keep changes to myself instead of trying to upstream them. Imagine commercial user which would be willing to contribute their changes upstream. They already donate their work even if they are not required to. It is not exactly fair to ask them to maintain bindings as well, if they do not use them (and most likely they do not).

Bindings themselves are more of a toy thing rather than serious tool. Lua may be fine for scripting some scene logic, but noone in their sane mind will try to implement advanced features in scripting languages in actual product that ships. With that said - limited set of bindings make more sense as that would be enough for scripting scene logic alone and reduce maintenance burden.

We also had a lengthy discussion what to do with Atomic after Josh left the project. One very appealing option was to turn Atomic into into Urho3D+Addons, where addons part would be tools and c# bindings. Ultimately we deemed it not really possible because of maintenance burden Urho3D is carrying. We concluded that going this way would only be possible if we forked Urho3D and simply dropped all the excess stuff so we do not need to maintain it. That means fragmentation and it never is good, but sometimes inevitable.

If we want project to thrive then clear priorities should be set. There isnt exactly that many contributors to spare. Ask yourselves what is more important: handful of amateur users who can not write c++ code and thus depend on scripting languages, or handful of contributors?

My bottom line - bindings are good when they are auto-generated, and contributors are way more valuable than users.

Actually making bindings for C# can be fully automated (I reason with the example of UrhoSharp) so may be move to C# in official repo instead support As/LUA ?

Would it be possible to automate AS and Lua binding? If so, could this process be made part of building the engine, and - as such - be controlled by cmake flags and outside commit-space?

I’d think any language binding that can (already) be automated could be optionally supported… and left out by those who want to stick to the native language.

Bindings can definitely be automated, except noone wants to write code doing that.

I think I mentioned it clearly in the end of topic head.

I don’t think that it’s really bad.
I suppose that script bindings shall be treated like any other Engine feature.
If one need it, he implement and PR it. And it is counter-productive to enforce contributors to implement and maintain features that they are not interested in.

I think that PR reviewers could also check that new functionality has interface that is consistent with other parts of the engine, so it wouldn’t make any sudden obstacle for binding maintainers.

To be honest, I highly desire that Atomic will re-union with Urho and bring its C# things, because I don’t see any future behind AS and Lua. I doubt that AS will ever stay workable with new compilers because it isn’t even true C++ library.

For my own project, I tried to automate AS bindings this summer. As I result I made this Lua script, which can be easily integrated to build process:
But it has one big disadvntage: it requires doxygen-like comments for each item you want to bind, for example:

//@ASBindGen Class ObjectType=Ref
class SampleContainer : public Urho3D::Object

Also this tool isn’t well-structured and may require some changes to be used in projects such as Urho3D. In future, I can try to integrate it to Urho3D (if Urho needs it), but not earlier than in middle-January.


I use Lua pretty heavily, but I’m willing to concede that having to provide AngelScript bindings has held me back from contribution in the past, so I can see the point of this suggestion. I’d most likely be willing to go along with the proposed change if that is the way you go (though I would naturally prefer otherwise, as I can see this leaving the Lua bindings pretty far behind.)

I highly desire that Atomic will re-union with Urho and bring its C# things

I think this would be a mistake, personally. Urho3D right now appeals to those of us who have no use for C# and no desire to spend the time learning to be comfortable with C#. I feel like C# users have their options (UrhoSharp among them). If C# is the way this project decides to go, I would certainly just fork before the change and never come back.


Though I use the SDK in pure c++, but if it can do automate binding, the argument will terminate.

1 Like

I’m urged to feel the same way. On the other hand this might make Urho the ideal gateway to open-source for those who started out with Unity (freshmen’s default).
Admittedly, my guts raise most concerns when talking C#. :nauseated_face:


Whats wrong with C# though? I do not like it and i do not use it, but if some people find it useful why would any of you care? Bindings are optional. Just like you do not use AngelScript you can proceed not using C#. No need for dramtic forks over nothing.

With that said - i think ideally bindings should live in their own repositories possibly with their own maintainers, but most ideally they should be (like we already said) autogenerated. Everyone would be happy then.

1 Like

It is a hastily devolved member of the C family that should be ignored for the sake of sanity.

That sounds much like a personal opinion. I do not think anyone should dictate what others are supposed to do or not to do based on their personal opinion. I myself think that C# does not have much place if any in game development. There are people who think otherwise and as far as i am concerned they can shoot themselves in the foot as much as they want, provided it does not impact me. UrhoSharp exists for quite some time now. Notice how it changed nothing? I suggest we should be less dramatic and more pragmatic about technical decisions. Emotion has no place in technology.