OpenMW 0.44.0

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OpenMW 0.44.0

Post by raevol »

psi29a wrote: 08 Apr 2018, 19:12 Hmmmmm I'm going to see if I can beat the debian maintainers to it and gain the reigns of that project.
Hostile packaging takeover :D
User avatar
halbe
Posts: 65
Joined: 14 Feb 2017, 03:55

Re: OpenMW 0.44.0

Post by halbe »

drakovyrn wrote: 08 Apr 2018, 17:42 That looks fantastic!
As it is now, agility, acrobatics, and speed are factors in how quickly you can climb, willpower solely governs fatigue which means it determines how far you can go, and if you run out of fatigue you fall off. This is a video I took after implementing the fatigue costs (the video is showing a "paraglider" staff).
https://streamable.com/ry55w

Another thing changed was instead of attacking to grab on, you put your weapon/fists away to grab on and if you take them out you fall off. You don't regenerate fatigue while climbing so the distance you can go is dependent on your stats unless you can find resting places, I stole that system and the paraglider from Breath of the Wild. Anyone who wants to test the alpha version of the mod can PM me, especially if you're also interested in testing the parts that don't change gameplay (bugfixes and graphics mods), since all the gameplay stuff is super pre-alpha.
User avatar
Greendogo
Posts: 1467
Joined: 26 Aug 2011, 02:04

Re: OpenMW 0.44.0

Post by Greendogo »

When did the climbing initiative start? Cool beans, reminds me of Daggerfall.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OpenMW 0.44.0

Post by scrawl »

akortunov wrote: 08 Apr 2018, 14:21
Br0ken wrote: 08 Apr 2018, 14:15 By the way, OSG 3.6 stable is released.
Can we update OSG-on-steroids fork?
Sure. Just test OSG 3.6 to make sure nothing in OpenMW is broken or runs significantly slower than it used to. Then rebase our fork to 3.6, resolving the (probably few) conflicts. Save the old one to a branch as a backup.

I probably won't get around to doing this for a while, so please feel free to beat me to it. IIRC there isn't much that's interesting for OpenMW in 3.6, anyway. (Still we should upgrade of course)
User avatar
Greendogo
Posts: 1467
Joined: 26 Aug 2011, 02:04

Re: OpenMW 0.44.0

Post by Greendogo »

scrawl wrote: 09 Apr 2018, 16:08IIRC there isn't much that's interesting for OpenMW in 3.6, anyway. (Still we should upgrade of course)
Are these issues still getting fixed?
viewtopic.php?p=53273#p53273
viewtopic.php?f=10&t=4841&p=52029#p52029
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OpenMW 0.44.0

Post by scrawl »

Okay, sure, the S3TC decompression feature is one bonus that should be in 3.6. Once our fork is updated, we can remove the environment variable and instead enable decompression if building with 3.6+.
JDGBOLT
Posts: 21
Joined: 05 Apr 2018, 19:52

Re: OpenMW 0.44.0

Post by JDGBOLT »

Just thought I would mention that OSG 3.6 for whatever reason refuses to work on my system with OpenMW. With the OSG fork everything runs fine, but the minute I switch over to OSG 3.6 and recompile OpenMW, it causes a segfault going all the way down into my Mesa driver, which is a Fury running on Mesa 18.0.0 . Not entirely too sure what is the cause of it, as I noticed in the back trace it was something going into the OSG engine itself and down into the Mesa driver, which I had no debugging symbols for. It also seems to be affecting only my modded install, a plain install with no mods seems to work fine. Unfortunately don't have the backtrace anymore as I quickly downgraded so as to continue being able to use OpenMW, but might try using 3.6 again to try to track part of the problem down.
User avatar
Br0ken
Posts: 243
Joined: 02 Apr 2012, 05:54
Location: Siberia

Re: OpenMW 0.44.0

Post by Br0ken »

JDGBOLT wrote: 09 Apr 2018, 20:42 Just thought I would mention that OSG 3.6 for whatever reason refuses to work on my system with OpenMW.
Aww, i was hoping for smooth transition to 3.6...
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: OpenMW 0.44.0

Post by akortunov »

JDGBOLT wrote: 09 Apr 2018, 20:42 With the OSG fork everything runs fine, but the minute I switch over to OSG 3.6 and recompile OpenMW, it causes a segfault going all the way down into my Mesa driver
How did you try to rebuild it? I got a similar segfault when I tried to do a partial rebuild (run "make" on existing build), but 3.6 works fine with full rebuild ("make clean", "cmake ../", "make").
JDGBOLT
Posts: 21
Joined: 05 Apr 2018, 19:52

Re: OpenMW 0.44.0

Post by JDGBOLT »

akortunov wrote: 12 Apr 2018, 11:26
JDGBOLT wrote: 09 Apr 2018, 20:42 With the OSG fork everything runs fine, but the minute I switch over to OSG 3.6 and recompile OpenMW, it causes a segfault going all the way down into my Mesa driver
How did you try to rebuild it? I got a similar segfault when I tried to do a partial rebuild (run "make" on existing build), but 3.6 works fine with full rebuild ("make clean", "cmake ../", "make").
I always do full rebuilds with removing the source directory completely and running makepkg each time, so I doubt it is that. I just went and tried again and again had it crash right after loading the game in an exterior cell, something that OpenSceneGraph is doing is causing Mesa to choke, as this back trace shows:

openmw: ../mesa-18.0.0/src/mesa/state_tracker/st_cb_bufferobjects.c:461: st_bufferobj_map_range: Assertion `offset < obj->Size' failed.

Thread 13 "openmw" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffb7fff700 (LWP 9874)]
0x00007ffff1abf860 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff1abf860 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff1ac0ec9 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff1ab80bc in __assert_fail_base () from /usr/lib/libc.so.6
#3 0x00007ffff1ab8133 in __assert_fail () from /usr/lib/libc.so.6
#4 0x00007fffe2268366 in ?? () from /usr/lib/dri/radeonsi_dri.so
#5 0x00007fffe20ec924 in ?? () from /usr/lib/dri/radeonsi_dri.so
#6 0x00007fffe21bb71a in ?? () from /usr/lib/dri/radeonsi_dri.so
#7 0x00007ffff7a1beda in osg::Geometry::drawPrimitivesImplementation (this=this@entry=0x7ffeead87fe0, renderInfo=...) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osg/Geometry.cpp:996
#8 0x00007ffff7a1cd93 in osg::Geometry::drawImplementation (this=0x7ffeead87fe0, renderInfo=...) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osg/Geometry.cpp:893
#9 0x00007ffff7a0c507 in osg::Drawable::drawInner (renderInfo=..., this=0x7ffeead87fe0) at /tmp/openscenegraph-git/src/OpenSceneGraph/include/osg/Drawable:276
#10 osg::Drawable::compileGLObjects (this=this@entry=0x7ffeead87fe0, renderInfo=...) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osg/Drawable.cpp:611
#11 0x00007ffff7a22364 in osg::Geometry::compileGLObjects (this=0x7ffeead87fe0, renderInfo=...) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osg/Geometry.cpp:864
#12 0x00007ffff71026b1 in osgUtil::IncrementalCompileOperation::CompileDrawableOp::compile (this=<optimized out>, compileInfo=...) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osgUtil/IncrementalCompileOperation.cpp:244
#13 0x00007ffff7102fdc in osgUtil::IncrementalCompileOperation::CompileList::compile (this=this@entry=0x7ffeead323a8, compileInfo=...) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osgUtil/IncrementalCompileOperation.cpp:363
#14 0x00007ffff7104402 in osgUtil::IncrementalCompileOperation::CompileSet::compile (this=0x7ffeeac0b4f0, compileInfo=...) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osgUtil/IncrementalCompileOperation.cpp:435
#15 0x00007ffff710609c in osgUtil::IncrementalCompileOperation::compileSets (this=this@entry=0x55555980f040, toCompile=std::__cxx11::list = {...}, compileInfo=...) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osgUtil/IncrementalCompileOperation.cpp:741
#16 0x00007ffff7106746 in osgUtil::IncrementalCompileOperation::operator() (this=0x55555980f040, context=0x55555659b9b0) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osgUtil/IncrementalCompileOperation.cpp:724
#17 0x00007ffff7a367d6 in osg::GraphicsContext::runOperations (this=0x55555659b9b0) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osg/GraphicsContext.cpp:727
#18 0x00007ffff7a8d122 in osg::OperationThread::run (this=this@entry=0x555556fd6c60) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osg/OperationThread.cpp:438
#19 0x00007ffff7a3840c in osg::GraphicsThread::run (this=0x555556fd6c60) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/osg/GraphicsThread.cpp:38
#20 0x00007ffff769cfb9 in OpenThreads::ThreadPrivateActions::StartThread (data=0x555556fd6c78) at /tmp/openscenegraph-git/src/OpenSceneGraph/src/OpenThreads/pthreads/PThread.cpp:213
#21 0x00007ffff33df08c in start_thread () from /usr/lib/libpthread.so.0
#22 0x00007ffff1b80e7f in clone () from /usr/lib/libc.so.6

Doing it a second time also gets a similar error, also in drawPrimitivesImplementation.

Edit: Okay, managed to find out what mod was causing my OpenMW with OSG 3.6 to crash badly, which is "new beast bodies clean" which can be found at http://mw.modhistory.com/download-10-10928 . Not sure what it is about those models, but as soon as I enable that mod in an otherwise vanilla installation the game, as soon as it tries to load the model used in that mod, it just completely borks and errors out with a similar backtrace to the above. Hopefully this helps to track down some of what is going on with those models that the game doesn't like, before moving on to osg 3.6, though other mods could be affected, this is just one that as soon as I removed it, it went away from what I could tell, and adding it and loading it caused immediate ctd.
Post Reply