I am planning to replace Urho3D::Vector and Urho3D::PODVector with std::vector. Yet another vector benchmark
Is there a person who wants to change the bindings to LUA? If such a person is not found, then the bindings will be removed.
I’ll give a look at automating their generation like the Angel Script ones. But I don’t use Lua myself, so if I think it will be too difficult and/or tedious I make no promises that I’ll actually do it. So if someone else wants to claim the job feel free. Otherwise I’ll probably report back in a week or so what my thoughts are.
To be honest, it’s weird attitude for PR.
It should be “This PR will not be merged unless you help me” and not “I will hurt you unless you help me”.
If there are no Lua users, it’s fine to drop Lua tho. But I am not sure about that. I think at least @JTippetts1 used it recently?
PS: I obviously don’t care about this topic personally, since I don’t use Lua. Treat this post as off-hand comment, not a strong opinion.
<sarcasm>If I knew I could just replace Urho containers with (EA)STL in PR, nuking all the bindings unless someone fixes them, I would have already done it 2 years ago</sarcasm>
1 Like
There are two variants: do not develop the engine or drop out what no one is going to maint. Those who need LUA and do not need engine development can use the old version with LUA. Nothing will change for them.
Two years ago there were contributors here
Do you have a roadmap of functional changes?
Neither removing Lua nor using STL will help users make games on their own – they are useful only as prerequisite for other (real) changes.
It looks like an attempt to hook me up. I have already explained the reason for change. If there are attempts to make changes, then any changes will be stopped by LUA bindings, which are not automatically generated and there is no person who deals with them. If there are no radical changes, then what’s the difference? You can still use the old version of the engine with LUA bindings.
p.s. Have you roadmap for rbfx?
Nah, I’m too old for this -_-
My philosophy is that the engine should help users make games, first and foremost.
So I look at all changes from this point of view: “how would it help someone to make a game?”
And I personally don’t make non-functional changes unless I plan to use them for something functional later – that’s why I was curious if you have any plans for future functional updates.
Surprisingly, yes! It’s offtopic so I’ll hide it.
Nothing to see here
- Move to EASTL
- Prototype C++ Editor
- Prototype C# bindings
- (I have joined rbfx here)
- Unified object serialization
- Baked lighting
- New renderer with PBR support and unified shaders
- Unified animation system
- Native import of glTF
- (
masteris here) - New networking
- New particles
- (
devbranch is here) - Animation refactoring
- Compute shaders
- (things below I am not 100% sure about and they don’t have an order)
- Render graph?
- Basic scripting, maybe Luau with SOL?
- VR?
- Vulkan+Metal?
- Editor refactoring?
- PhysX integration?
How does blocking engine changes help to create games?
Please don’t break/remove LUA support.
Although I don’t use LUA myself, I think there’s people actively using it (I think @evolgames is using LUA, and he’s making some really cool games [1] [2] [3] [4]).
Or at least add std::vector as a compiling option/flag so it won’t break the current engine features for everybody.
1 Like
Are you planning to maintain LUA bindings?
As I said, I don’t use LUA. But I feel for those that use it and now, out of nowhere, could lose it. That’s not cool.
Again, if the std::vector performance gain is suddenly so important now, just add it as an compiling option/flag so it won’t break everything for everybody.
Have you read my posts above?
Yes, have you read mine?
Yes, you write nonsense.
1 Like
How do you imagine that?
ifdef for each vector use?
I can teach you how to use git (not free) to keep track of changes
Won’t you change them all anyway?
If it’s already there, then what’s the issue on supporting LUA?