How to chip in?

[lgromanowski]

Hi all

Sad to see that Nico's disappeared, but good to know that there's enough of you involved to keep things going!

I was having a look at the roadmap and thought I'd start by fixing one of the small features (e.g. "path problems on linux"), but wasn't really sure what this meant or if anyone else was working on it (e.g. there are some patches on github relating to loading resource files from archives and the file system).

I guess forum boards are one way of fielding questions, but it seems to me that one of the fastest ways of getting help when getting started would be able to chat via IM (well, if that doesn't leave someone bogged down with too many interruptions). Are any of the coders using jabber/skype/etc.?

I've been following OpenMW for a while, and thought I should try getting a little involved (though probably not a lot). I know C++ fairly well and, yes, D), have been using boost a bit, don't want to do graphics programming, and probably don't want to start learning a big library like bullet either at this point. Are there any things in particular I could usefully lend a hand with?

Oh, btw, I successfully built openmw on debian testing (just had to build Ogre from sources). In my flat refusal to install non-debian packages where I can get away with it, I installed Ogre within my home dir and hacked the cmake config not to use PkgConfig; unfortunately it still tries to load shared libraries from /usr/local/lib. Maybe I'll try to fix this first...

I guess forum boards are one way of fielding questions, but it seems to me that one of the fastest ways of getting help when getting started would be able to chat via IM (well, if that doesn't leave someone bogged down with too many interruptions). Are any of the coders using jabber/skype/etc.?

With a small developer base spread out over all time zones IM doesn't work very well. Just use the forum.

I was having a look at the roadmap and thought I'd start by fixing one of the small features (e.g. "path problems on linux"), but wasn't really sure what this meant or if anyone else was working on it (e.g. there are some patches on github relating to loading resource files from archives and the file system).

Relative paths in the esm files are given in Windows-style, e.g. Meshes\SOMEmesh.niF, while the actual file (on a Linux box) would be meshes/someMesh.nif.

There is some work on github (Mach1723) related to it. This one addresses loading files from the file system versus bsa archives. It is implemented via the FileFinder component (see components directory).
Also, I think for sound files the Linux path problem has already been sorted out (also using FileFinder).

So the task would be to develop a fix for non-sound files based on Mach's work. Also, it will require some optimisation, because the performance of Mach's code is terrible. I suspect, that the actual problem is not Mach's code, but the FileFinder. This will need some investigation.

Oh, btw, I successfully built openmw on debian testing (just had to build Ogre from sources). In my flat refusal to install non-debian packages where I can get away with it, I installed Ogre within my home dir and hacked the cmake config not to use PkgConfig; unfortunately it still tries to load shared libraries from /usr/local/lib. Maybe I'll try to fix this first...

I think there also was a bit of progress regarding this problem (if by shared libraries you mean the Ogre plugins). Not sure, if it would help in your situation. See the jpn/paths branch.

I guess forum boards are one way of fielding questions, but it seems to me that one of the fastest ways of getting help when getting started would be able to chat via IM (well, if that doesn't leave someone bogged down with too many interruptions). Are any of the coders using jabber/skype/etc.?

I'm not using any of these. I can be found on IRC though (EFnet/GameSurge).

Oh, btw, I successfully built openmw on debian testing (just had to build Ogre from sources). In my flat refusal to install non-debian packages where I can get away with it, I installed Ogre within my home dir and hacked the cmake config not to use PkgConfig; unfortunately it still tries to load shared libraries from /usr/local/lib. Maybe I'll try to fix this first...

You can just use some -D on cmake to set the correct variables to tell it where you have ogre and by that bypass the detection, no need to edit the files for that.

As for finding the libraries at runtime, when building with make I get a binary with rpath set. If you don't I suppose manually adding the rpath or setting LD_LIBRARY_PATH would be a solution. I'm assuming that installing ogre to a system wide location where it can be found the normal way is not an option.

You can just use some -D on cmake to set the correct variables to tell it where you have ogre and by that bypass the detection, no need to edit the files for that.

Yes, but in this case PkgConfig is used before reading OGRE_* (FindOGRE.cmake:41), so it complains even if those variables are set by hand. I'm sending a pull-request for a patch which fixes this (and also checks uuid.h is present).

By the way, OpenMW also builds fine with clang (from trunk), though there are several warning messages (this one pops up a lot):

Code: Select all

[ 83%] Building CXX object apps/openmw/CMakeFiles/openmw.dir/mwworld/world.cpp.o
In file included from /home/dhardy/code/games/openmw/apps/openmw/mwworld/world.cpp:2:                                                                                                        
In file included from /home/dhardy/code/games/openmw/apps/openmw/mwworld/world.hpp:9:
In file included from /home/dhardy/code/games/openmw/./components/esm_store/cell_store.hpp:13:
In file included from /home/dhardy/code/games/openmw/./components/esm_store/store.hpp:16:
In file included from /home/dhardy/code/games/openmw/./components/esm/records.hpp:4:
In file included from /home/dhardy/code/games/openmw/./components/esm/loadacti.hpp:4:
/home/dhardy/code/games/openmw/./components/esm/esm_reader.hpp:495:20: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
      if(c.leftRec < 0)
         ~~~~~~~~~ ^ ~
1 warning generated.                                                                                                                                                                         

Oh, fixing the plugin search path is as simple as changing the path in plugins.cfg. And no, I don't need to install OGRE under a custom path...

What are standard error handling procedures? Throw a runtime_error or some derived class? I just noticed a piece of code with no error handling (FileFinderT::lookup()).

Throwing std::runtime_error is a good idea. No need to derive anything, unless you really expect this error needs a special treatment.

Throwing std::runtime_error is a good idea. No need to derive anything, unless you really expect this error needs a special treatment.

Good, that's what I implemented.

I pushed a new branch to my fork which contains Mach's changes plus some optimizations. I presume Mach did the hard work and worked out where exactly FileFinder needed to be used anyway? In any case, everything loads fine for me.

By the way, how does the BSA archive system work? Files within a BSA are replaced by those in the current directory with Mach's change (at least, I presume so; didn't actually check), but how does the engine know which BSA contains resources? Or (this is what I previously assumed morrowind did) are all the BSAs merged into one virtual file system from which resources are found? If so, I think a few more changes are needed.

Files within a BSA are replaced by those in the current directory with Mach's change

I think there was some talk about considering time stamps, but it is possible, that I am mixing something up here. But if the BSA format has timestamps they definitely should be considered.

Or (this is what I previously assumed morrowind did) are all the BSAs merged into one virtual file system from which resources are found

That's how it should work.

But if the BSA format has timestamps they definitely should be considered.

BSA doesn't store timestamps for the individual resources. You could take the timestamp of the BSA itself and apply that to all resources inside it, though.

Not sure, if that is a good idea. Someone updates a BSA and suddenly all mods, that replace BSA resources, fail. So lets forget about the timestamps. My fault. Quite possible, that I was mixing up MW with another game.

Well, Oblivion deals with .esps based on timestamps; not sure about .bsa files. There has to be some prioritization, though hopefully it's less of an issue with .bsa archives as it can be with .esp plugins. I guess for now it's not very important; don't mods which want to replace resource files install them as uncompressed files rather than in a bsa? I'm not entirely sure, though an alternative system allowing selection of bsa priority might be preferable in the end.

On my part, I'll try to unify the resource system a bit more, but I'm not sure if much more needs doing at this stage.

Well, the only part of the feature, that is still missing is the actual handling of file names outside of BSAs (on Linux). If you can cleanup the resources handling, that would be welcome though.

Everything else can wait after 1.0.

Well, what currently happens in OpenMW appears to be this (ignoring non-morrowind resources):

• Meshes dir added
• Textures dir added
• loadBSA() adds all .bsa files it finds in file-system order

The resources added first have highest priority in search order. Sound resources are handled independently by SoundManager::SoundImpl.

OK, so, in that case:

• the BSAFile class shouldn't worry about external files at all
• OGRE's file locater should somehow be botched to ignore case or replaced with something ignoring case. (This means it somehow has to handle cases where two files with different-case names exists.)

Right, makes more sense than what this FileFinder class currently does.

By the way, my MW directory also has these resource directories:

• BookArt (inside pages of books)
• Fonts
• Icons (for inventory; this isn't started yet?)
• Music
• Sound
• Splash
• Video

The sound system already manages its own resources, fonts and videos will obviously be used by separate systems, but book-art icons and splash-screens may want to be made available to OGRE in the future.