Impressions of 0.18

[pvdk]

- It's looking better and better for each new version. I like that you've added widescreen and standard next to a resolution. It would be nice having all those in-game options in the launcher too tho.

Thanks!

- The scrollbar of the resolutions have a weird box in it

This could be this Qt bug. Could you please run the launcher from a cmd window with the following argument:

Code: Select all

omwlauncher.exe -style plastique

And see if the problem persists?

- I know this isn't the standard Morrowind behaviour, but do mushrooms and flowers really need containers instead of just being picked automatically?

There are several mods for Morrowind which do this, so there is no reason why we should implement this in our engine.

Also, is it known why this error occurs around the Vivec cantons? Seems to hurt performance for me for printing out endless error messages.

I remember seeing this error message before, it seems related to this bug.
Also, thanks for the heads up on the duplicate resolutions.

[Lazaroth]

And see if the problem persists?

This is how it looks with that option enabled:

scrollbar2.jpg (39.67 KiB) Viewed 5490 times

I can not reproduce this crash.

I have always had this crash in every version of OpenMW. However, I just tried it again and for the first time ever it worked. I'm going to reinstall and do some other stuff later and see if I can reproduce the crash.

[Zini]

Alright, I added the duplicate resolutions thing and birthsigns sorting to the tracker. Any word on being able to create a character with no class or birthsign?

Not really a bug, as far as I can tell. You haven't selected one, so you don't get one. This problem will go away on its own (together with the preview problem and the not updating the character after character creation) as soon we have the ESM storage sorted out.

[Zini]

Zini, you know that if you choose the default Morrowind key as the console key it will add it to the console's input box when you close the window. Why don't you just make the key that the console window is set to not work as an input key when it is mapped that way?

I would like to avoid this kind of special case implementation. Not to mention that disabling a key will make you end up with one key less and therefore a not fully functional keyboard. Sorry, but the original choice of key for opening the console in the context of multiple international keyboard layouts was just poor.

Why? This is a very frustrating issue for the users. Project Aedra is completely smooth in exteriors, it seems like everything loads instantly (even faster than the original game I think).

We would have to profile down the cell change scenario to see if there are any improvements we can make. That is a lot of work for code that probably will not persist beyond OpenMW 1.2 or 1.3. We still have plans to implement smooth cell transitions (on a sufficient powerful box), which most likely means that we will have to re-do most of the cell loading code anyway (or at least re-arrange it). That however is even more work and can't definitely not be done before 1.0. And I don't feel like to fix something up that works okay-ish now, when it will be replaced later.

'd also like to vouch for the annoyingness of the exterior cell transitions. Moving to a new cell causes very violent shaking (as the loading bar works), going back and forth along your movement vector (like a foot or so, forward and backward very fast, it's giving me a headache).

This however sounds like more than the ordinary delay at cell load. Either you are exaggerating a bit or you have a problem, that does not show up here. Is there any chance you could record a small video of it or show us any other way what is happening for you?

[Greendogo]

Zini, you know that if you choose the default Morrowind key as the console key it will add it to the console's input box when you close the window. Why don't you just make the key that the console window is set to not work as an input key when it is mapped that way?

I would like to avoid this kind of special case implementation. Not to mention that disabling a key will make you end up with one key less and therefore a not fully functional keyboard. Sorry, but the original choice of key for opening the console in the context of multiple international keyboard layouts was just poor.

Indeed, it may be a poor choice, but what I'm suggesting is a logical way of preventing useless keystrokes from getting into the console. I'm no longer suggesting that you make " ' " the default keystroke for opening the console, but there is still a legitimate bug here.

To test this, set the key for the console to a letter. Now, open the console window with that key. Notice that the command text box is empty. Now close the console window with the key. Now open it again. That character has now been entered into the console window. This is a bug; unintended and undesirable behavior, and I'm surprised you don't want it to be fixed because you consider correcting it to be a "special case implementation". Do you really want the console window to print out the key that it is bound to, upon closing and opening it? Anyway, it's not really important in the grand scheme of things, and I don't really want to waste any more of your time talking about it
It just seems buggy to me is all.

I'd also like to vouch for the annoyingness of the exterior cell transitions. Moving to a new cell causes very violent shaking (as the loading bar works), going back and forth along your movement vector (like a foot or so, forward and backward very fast, it's giving me a headache).

This however sounds like more than the ordinary delay at cell load. Either you are exaggerating a bit or you have a problem, that does not show up here. Is there any chance you could record a small video of it or show us any other way what is happening for you?

I've never done any screen recording, so I'll think about it. But no, I'm not exaggerating, it's pretty awful. I miss the days of screen transitions that didn't throw me into a seizure.

[Chris]

'd also like to vouch for the annoyingness of the exterior cell transitions. Moving to a new cell causes very violent shaking (as the loading bar works), going back and forth along your movement vector (like a foot or so, forward and backward very fast, it's giving me a headache).

This however sounds like more than the ordinary delay at cell load. Either you are exaggerating a bit or you have a problem, that does not show up here. Is there any chance you could record a small video of it or show us any other way what is happening for you?

Sounds like the same thing that happens in vanilla. What happens is the loading bar is simply drawn on top of the "dirty" back buffer contents (which is generally the last frame drawn on it). When the back buffer is blit to the front buffer for display, as is often the case in Linux, this works fine since it is the last frame rendered with the progress bar pasted on top. With page flipping, though, this means it cycles between the last two frames drawn every time the progress bar updates, creating the shaking.

Unless you can redrawn the scene, what you'd have to do is get a copy of the front buffer when a cell load starts. Then just make sure to clear the back buffer using that image before drawing the loading bar and presenting it to the screen.

[Zini]

To test this, set the key for the console to a letter. Now, open the console window with that key. Notice that the command text box is empty. Now close the console window with the key. Now open it again. That character has now been entered into the console window. This is a bug; unintended and undesirable behavior, and I'm surprised you don't want it to be fixed because you consider correcting it to be a "special case implementation". Do you really want the console window to print out the key that it is bound to, upon closing and opening it

Now I get what you mean. Sorry, misunderstood you earlier.

I still don't consider that to be a bug. If you press a key that is bound to a printable character, you will get output for that character. If you bound that key to console open/close you still get that key. Formally correct behavior, though indeed a bit surprising. Personally I am okay with that, but if enough confused user show up, we can try to disallow keys with printable characters for the purpose of the console (and any other function that results in a UI with text input). Someone proposed that on the tracker a while back. Simply disabling the text input of the bound key is not an option IMHO, because that a key suddenly stops to work is no less puzzling than it doing too much (open/closing the console and input text into it).

[Greendogo]

Simply disabling the text input of the bound key is not an option IMHO, because that a key suddenly stops to work is no less puzzling than it doing too much (open/closing the console and input text into it).

Well, if you kept the default of F2, then the person would have chosen to assign the key to a printable character. Knowing that the character was bound to the console window open/close function, they wouldn't expect it to work in the window- thus no puzzlement. Most people wouldn't change that binding, but those that did, I bet, would understand what they were doing with it.

[Chris]

I still don't consider that to be a bug. If you press a key that is bound to a printable character, you will get output for that character. If you bound that key to console open/close you still get that key.

What about if the input line is cleared when the console is closed?

[Zini]

Knowing that the character was bound to the console window open/close function, they wouldn't expect it to work in the window- thus no puzzlement

I think you underestimate how easily people can become puzzled.

What about if the input line is cleared when the console is closed?

Losing the input, if you decide halfway to take a break from inputting it, sounds seriously annoying. And it doesn't help with other yet to be implemented UI scenarios, e.g. an editable journal (possible post 1.0 feature).