Well done on getting the CEGUI project to compile!

You mentioned a compatibility layer for certain properties (before: "Carat", after: "Caret"). What are your thoughts and plans on that?

I had a think - our Lua API pretty much acts as that compatibility layer, any "breaking" changes can be rectified there (or in the GUI project) and the end-user won't know any different.

Regarding properties, if there's simply been a name change, we could just manually track these from 0.4.0 to 0.8.7 and have a "lookup table" for guiSet/GetProperty (so when you're setting/getting "CaratIndex", you're actually setting/getting "CaretIndex"). It may be worth displaying a warning to let them know about this though.

If the property now requires a different value, we may be able to do a conversion on the value. For example, if it used to require 0 or 1, and now requires true or false, we can handle that in the Lua function definition. Otherwise, there's not much we can do.

I'm hoping (not just limited to properties) that most of the changes in CEGUI from 0.4.0 to 0.8.7 had backwards compatibility in mind, so we can match everything exactly how it was before.

I'm thinking it would be nice to have an API version in meta.xml or something. So that resources without an API version can use that, and resources with an API version can just use the latest and most correct attributes.

This 'api version' thing (c/sh)ould be submitted as a separate issue

The API version thing seems like a good idea, but implementing it would be a mess.

I agree, it would be a clusterfuck of overloads and wrapping code in if statements to check for CEGUI API version - can't think of a "clean" way of implementing it.

CEGUI API version

FWIW I was suggesting a version for MTA's Lua API overall, not CEGUI specific version

Modifications we made to CEGUI that I'm aware of:

• Allow images to be placed in a gridlist and combobox elements (for the server browser locked icon, and for the search players and search servers)
• Numerous speed and refresh optimizations, which probably are deprecated with a new CEGUI
• Added Unicode support, which again should be deprecated
• Unicode Glyph Caching (again should be deprecated in newer CEGUI)
• Unicode Glyph substitution using unifont. Hopefully new CEGUI has some functionality for glyph substitution?

By the way, if this PR gets merged, I think this issue would be resolved too: #283

Just as a note (after some discussion about how to approach this monstrosity of a PR) - this draft pull request is basically just my training ground now for figuring out every part of CEGUI and seeing if I can get a 1:1 match with the current version of CEGUI (looks and functionality wise).

Once that's done I'll be recreating pretty much all the code and submitting smaller pull requests (for example, a PR just for updating the binaries/CEGUI source), then a pull request containing commits re-factoring each type of CGUI*_Impl.

something along those lines, anyway, otherwise this is just gonna be a complete mess to review.

Thanks to @qaisjp for letting me know how to "merge" the new branch with this one. Everything seems good.

Note: follow commits starting from 3dd292a (Add CEGUI-0.8.7 vendor) - everything before that is the "old" branch and isn't relevant now.

So basically, all we need now is a ton of unit tests?
Or should we just test it briefly (crashes, etc), and let it out?

There's still some things left to fix. Gridlists don't work fully, sliders are broken, there's minor issues with relative positioning and sizing (after testing a few default resources, and some from the community), and probably a lot more undiscovered.

Everyone seems happy to drop support for the current themes, as long as a suitable alternative is provided, which makes it much easier. I've decided to go with "GWEN" as a base, it needs some tweaking but it's already much better than some of the default themes shipped with CEGUI. (https://github.com/benelot/CEGUI-GWEN-Skin)

You can see a few examples of the skin by clicking the spoiler below:

(don't worry, I was also working on a dark theme)

Once I'm happy that the last few remaining "big" issues are fixed, we should just test. Anyone can help out, just clone the branch, compile it and load all your GUI scripts. We should have a dedicated place to track issues for this.

We can also slowly start refactoring the classes as we go along fixing issues - I've tried to keep everything as close to the original code as possible, however there's a lot I couldn't avoid at least partly re-writing.

Honestly, the code is shit. It was shit then, it's still shit now, and whoever reviews this needs to accept that it's shit. The best we can do is slowly test and refactor as we go, and at some point once we're happy the main issues have been addressed we'll release it into nightly for wider scale testing. Rinse and repeat.

If you don't already know, we already have the option to choose the CEGUI version, with the use_new_cegui cvar (0 or 1). This requires a restart of the client once set, and switches out the GUI module - so as for stability in nightly we should be fine. We can continue to fix issues and refactor the code.

I have some time off this week, maybe I'll get back on it ;)

Note for vendor crash fix cegui/cegui@263e53d

What's left exactly?
Would be nice to finish this

I have some time off this week, maybe I'll get back on it ;)

never happened, so still pretty much the same as last comment

#2136

This should be checked.

This draft pull request is stale because it has been open for at least 90 days with no activity. Please continue on your draft pull request or it will be closed in 30 days automatically.

This draft pull request was closed because it has been marked stale for 30 days with no activity.