openmw.org

Hey all,

my name is Raul Ramirez and I have been developing C++ code for about 5 years now and I am looking to get my hands dirty on a huge project of one of my favorite games! I have read through the how to get started, I have forked the repository, however. I want to get registered on the bug tracker however I accidentally typed my email incorrectly and attributed that with my username (Sailanarmo). I am quite attached to my username and I am wondering if anyone can delete the accidentally typed email and username so I can go ahead and get registered on there?

Also, where wouldn't someone like me fit in best?

Thanks all!

Raul Ramirez

I deleted the pending account. You should be able to re-register now.

Any experience with Qt? We still need more help with the editor than with the engine itself.

Thank you for doing that,

I do not have experience with QT, but I am more than willing to get my hands dirty in it. Where should I start looking for information about it?

And thank you for doing that!

Sail

Google is your friend. Lots of documentation and tutorials available. We are using Qt4 btw.

I looked though the available editor tasks and found a few:

* Editor: Search function does not consider GMSTs
* OpenMW-CS: Column filtering
* OpenMW-CS: Palette subview

The first one doesn't actually require doing any work with Qt yourself. It is also the smallest one of the three. Might be a good starting point.

I and others would really really like to ditch Qt4 for Qt5, I still don't understand what is holding us back.

I can't find any killer features of Qt 5 that Qt 4 doesn't have that we'd actually make use of. Can you give me some examples?

I remember pvdk, sirherrbatka and others working on the launcher and editor saying that would love to use Qt5 features that would simplify the code. I wish they would chime in. There might be talk about it in the forums, but I think there was also talk about it on github issues.

I would love to focus on just Qt5 over Qt4 just for the sake of maintenance costs and packaging. Qt4 will stop being supported downstream anyway.

I see no compelling reason to keep Qt4 support other than, until now, it hasn't been much of an issue.

Primary reason that there seems to be a regression in the interaction between Qt5 and OSG. I am not tracking this issue but I also haven't heard anything about it being resoled. Therefore I assume it is still in place. This is kinda a show stopper.

Secondary reason (not as significant and not a show stopper, but still noticeable) is that (at least in my perception) Qt5 reached a suitable level of maturity only recently. That means that all distributions that carry older versions of Qt5 are more likely to have problems. It certainly affects me (since I am extremely conservative with updating) but there are probably quite a few other distros that are affected. IMO distros that are throwing out Qt4 now are jumping the gun. This is at least two years to early.

And finally IMO we have little to gain from Qt5. There is the QML stuff that will get into OpenMW-CS only over my dead body. There is some reorganisation that is an improvement, but leaves Qt still in a very un-indiomatic state in regards to C++ (wish we had a word like pythonic for C++). There seems to be some good stuff in regards to OpenGL, but that won't affect us because we are using OSG instead of the build-in rendering capacities. Mobile stuff, again irrelevant for us (seems to be the majority of Qt5 is aimed at that). Not porting OpenMW-CS to android.

QString has become a tiny bit less annoying (a very tiny bit) and the signal/slot system is more robust. Okay, the last one is actually pretty nice. But still, as the only real payout for a major framework change it isn't very enticing.

Zini wrote: ↑24 May 2018, 10:29 Primary reason that there seems to be a regression in the interaction between Qt5 and OSG. I am not tracking this issue but I also haven't heard anything about it being resoled. Therefore I assume it is still in place. This is kinda a show stopper.

According to Scrawl, this is not a blocker but on Oct 24, 2017 he said:

Qt5: unfortunately, our current OSG+Qt integration does not support threaded rendering with Qt5. Therefore it might be preferable to default to Qt4 until this is resolved?

https://github.com/OpenMW/openmw/pull/1 ... -339118933

However osgQt was removed from OSG-3.6 and replaced with osgQtQuick which only supports Qt5

Project osgQtQuick now based on Qt5. The Qt4 not supported.
Threaded rendering now supported. You can set environment variable QSG_RENDER_LOOP to the value of "basic", "windows" or "threaded" also.
For asynchronous loading, you can use type osgDB.Loader.

This does support threaded rendering.

We can also look into QSG_RENDER_LOOP for osgQt as well which might resolve the issue for us.

We are not officially on OSG 3.6 either though that is probably going to happen in the not too far future. I am not outright against migrating to Qt5, but I also don't want to rush it. Let's take a fresh look at the situation once scrawl is finished with whatever he is doing right now (really curious) and stops being incommunicado. At least the next release will still be Qt4 based.