Morrowind Code Patch

[Kiteflyer61]

Thanks Hrnchamd! This should add quite a few more years to Morrowind's life span!    Great work!  

[Hrnchamd]

MCP opens new doors of texturing and animation. A thread for modellers, explaining the patch features. In there is an lovely example video from AOF that demonstrates what is possible.

[morovir]

I really wonder how much of this work would be applicable to OpenMW. I know that most of this code is intended to patch Morrowind specific bugs, but I can't help but think that the knowledge required would be helpful for getting the open-source version of the engine going.

[Hrnchamd]

OpenMW still seems to be on the graphics-led learning project stage. Gameplay is a single bullet point on the features list at the moment.

[Sandman101]

This may be a dumb question but would it be possible to add a feature to allow equipping more rings and multiple amulets?  Most races have 10 fingers.  I've never understood that.  Most rings are cast on use anyway and enchanting multiple constant effects is very expensive.
And why can't I wear enough amulets to look like MR. T?
COBL for OB has just such a feature.

[Hrnchamd]

All slots are hardcoded, as is the savegame format for item equipping. The internal structure cannot be compared to Oblivion, and I can't add 'just like Oblivion' features. Constant effect items are easily found in the world, equipping 10 would be excessive. It doesn't seem to feature in the COBL readme at all.

It may be possible to just not equip cast on use rings when you select and use their spell.

[Sandman101]

That an excellent idea Hrnchamd!  Not equipping the cast on use rings and amulets would eliminate the constant re-equipping of the items you actually want to wear.
I wasn't sure up to what point you're able to manipulate the data.  Didn't even think about the ess file.

I don't have OB installed on this computer(it's one the one at home) but I remember being able to check off either multiple or unlimited amulets and rings.

[Jac]

I do like the not equipping cast on use rings (or other items). One thing I don't like having to do is take them off to put my other rings back on.

[masternetra]

Nice Patching, I was wondering if can set weapon strikes to automatically hit and let the skills effect the damage you inflict? I mean it never made sense that you could shove a sword through a char and it not actually hit... And while at it, could you add  option to change the recovering chance for arrows.bolts, etc to around 90%? I understand that SOMETIMES projectiles are gonna break impacting into a opponent but the rate of loss in vanilla Morrowind is way too high. You should be losing them occasionally not frequently. Thanks if you can/do.

[Jac]

Already done:

Marksman recovery
Always hit Morrowind

Basically what you're asking for has already been covered by mods and won't be covered by this patch. The arrows especially since the recover chance is determined by a game setting that can be changed via a mod.

[Maiqdabomb]

Wow, I didn't know work was still being done on this. I got an older version - it might have been 1.0 - and didn't think about updates. Glad I checked in.

[SCO]

I've been running morrowind in wine pretty flawlessly, except for one thing:
Morrowind Script Extender loads up the dll at the wrong adress apparently, provoking nasty errors, like duplicated keys on save-load in Keyring mod, hang when using a fire on touch spell with fleeing fletchers, hang/blackscreen on "New Game" with Protective Guards  and many other problems i don't remember. The problem appears to be caused by this:
http://bugs.winehq.org/show_bug.cgi?id=13915
(This is for oblivious, but i think that the problem is similar since it is from the same authors).

So here is my request:
incorporate MWSE into the morrowind code patch as a static alteration to the exe file. This would make it compatible with wine (and mac os x through it i think) and be one less thing you have to install/run to run a updated morrowind install.

[peachykeen]

I've been running morrowind in wine pretty flawlessly, except for one thing:
Morrowind Script Extender loads up the dll at the wrong adress apparently, provoking nasty errors, like duplicated keys on save-load in Keyring mod, hang when using a fire on touch spell with fleeing fletchers, hang/blackscreen on "New Game" with Protective Guards  and many other problems i don't remember. The problem appears to be caused by this:
http://bugs.winehq.org/show_bug.cgi?id=13915
(This is for oblivious, but i think that the problem is similar since it is from the same authors).

So here is my request:
incorporate MWSE into the morrowind code patch as a static alteration to the exe file. This would make it compatible with wine (and mac os x through it i think) and be one less thing you have to install/run to run a updated morrowind install.

Well, couple things with that:

First, it's difficult at best to push MWSE into the main engine. It takes injecting a bit of code into the virtual machine. Hrnchamd would have to weigh in on feasibility, but I know there's not a huge amount of space available in MW.exe. Even if you added an additional segment, there's the matter of linking it into the execution properly. Research would have to be done into how MWSE does that now and if it's possible to do statically. There is a huge conceptual difference between dynamic and static linkage, hence the relative similarity between Windows and POSIX executable code (all in a row, more or less) and shared libraries (PE vs ELF, virtual memory space, addressing differences, etc).
Second, if the comments here:

This appears to be a discrepancy between the Windows implementation of the DLL
dependency handler/loader and the Wine implementation. Unfortunately I don't
have a linux install to test this on, but my first guess would be that calling
CreateProcess with the CREATE_SUSPENDED flag set leaves the new process' loader
critical section locked until the main thread is resumed.

If that assumption is correct for MWSE as well (I'm not entirely sure if it is), it offers a very simple solution without any messy static binary mushing. Using loaders and suspended threads is a messy, at best, method of injecting custom code. It's also known to have problems with anti-virus programs, security checks, and all sorts of other things. A method I've used before (the one MGE uses, in fact) is far more reliable and far more stable.

Using the MGE method, there is a bit of code that is run whenever a shared object (DLL) is loaded. Both POSIX SOs and Windows DLLs have them, although only the latter matter here. The function is called from the main thread of the program during launch, so long as the shared library is included in the PE's import table. It is easily and simply possible to inject any number of arbitrary DLLs into a process, especially if one were to use a basic loader to provide a single point of interface to the original engine (for example, replace binkw32.dll with a file that will load every DLL in a given directory). An even simpler solution would be to simply replace a select DLL with a specially-compiled one (a Wine version of MWSE/OBSE, for instance) that would load itself and dynamically link to the original. Doing so would effectively statically link the DLL in question, neatly sidestepping many of the issues.

[SCO]

Here is the bug i created on wine (i am striking from both ends). At least it is probable the wine devs guidance will make sure what is the problem (if not solve it, as the oblivion bug indicates).

http://bugs.winehq.org/show_bug.cgi?id=24212

Btw there is something suspicious in the log file of MWSE. There are lots of "Initializing Lists" after a while playing. This seems not unrelated to duplicated keyring etc.

I've been trying to get MGE to work, but i've not been able to get the "MGE" to appear on the morrowind game load, so it is not working either. I have the correct "Installed Path" registry key and the others, otherwise it wouldn't even work (btw i don't like requiring "Installed Path". I know it is difficult to know from where a exe is running, but even in java i've been able to do it, should be possible in c\+\+)

[SCO]

By Far the most obvious problem with the mods i didn't mention:
There is a constant spam of ingame debug messages to the screen if you install one of the mods that needs keypresses like inventory search

[SCO]

The order of application of MGE and MCP is indifferent right?

[peachykeen]

Here is the bug i created on wine (i am striking from both ends). At least it is probable the wine devs guidance will make sure what is the problem (if not solve it, as the oblivion bug indicates).

http://bugs.winehq.org/show_bug.cgi?id=24212

Btw there is something suspicious in the log file of MWSE. There are lots of "Initializing Lists" after a while playing. This seems not unrelated to duplicated keyring etc.

I've been trying to get MGE to work, but i've not been able to get the "MGE" to appear on the morrowind game load, so it is not working either. I have the correct "Installed Path" registry key and the others, otherwise it wouldn't even work (btw i don't like requiring "Installed Path". I know it is difficult to know from where a exe is running, but even in java i've been able to do it, should be possible in c\ \ )

It's actually a bit harder to find out where the program is running from in C   compared to a toy language like Java. You have to select the module and then retrieve the location for that from the Windows API (it takes 2 or 3 WinAPI calls, but funnily still runs hundreds of times faster than the Java version).

Anyway, it's possible, but MGE doesn't depend on it. MGE not attaching is purely a matter of Wine's DLL selection mechanism, I think. It must first check the working directory and load any dependencies from there (and you must start the program with the working directory as the Morrowind folder, hence the shortcuts issue). If that behavior doesn't match the Windows-standard behavior, then MGE will fail to start. There must also not be any hacks bypassing dependency on the D3D DLLs and valid D3D assemblies must exist in the system directory for MGE to function. MGE works using a semi-documented feature of Windows, if Wine hasn't replicated that properly, then MGE will fail on that platform. You may try a debug build and attach a debugger while starting it, to make sure the DLL is caught and started.

The order of application of MGE and MCP is indifferent right?

[/quote]
Correct, they're entirely different mechanisms.

[SCO]

It's actually a bit harder to find out where the program is running from in C   compared to a toy language like Java. You have to select the module and then retrieve the location for that from the Windows API (it takes 2 or 3 WinAPI calls, but funnily still runs hundreds of times faster than the Java version).

You'd think it was obvious, but it is not so. The standard way most use to find out where the program dir doesn't work - it only finds out where the program was loaded from ie: the current directory.

Code: Select all

   /**
     * Finds the parent directory of the class given
     *  @throws IllegalArgumentException if the class given is not loaded by a local file classloader
     */
    public static File getApplicationDirectory(Class applicationClass)  {
        if (applicationClass == null) {
            throw new NullPointerException();
        }

        String className = applicationClass.getName();
        String resourceName = className.replace('.', '/')   ".class";
        ClassLoader classLoader = applicationClass.getClassLoader();
        if (classLoader == null) {
            classLoader = ClassLoader.getSystemClassLoader();
        }
        URL url = classLoader.getResource(resourceName);

        String szUrl = url.toString();
        if (szUrl.startsWith("jar:file:")) {
            try {
                szUrl = szUrl.substring("jar:".length(), szUrl.lastIndexOf("!"));
                URI uri = new URI(szUrl);
                return new File(uri).getParentFile();
            } catch (URISyntaxException e) {
                throw new AssertionError(e);
            }
        } else if (szUrl.startsWith("file:")) {
            try {
                szUrl = szUrl.substring(0, szUrl.length() - resourceName.length());
                URI uri = new URI(szUrl);
                return new File(uri);
            } catch (URISyntaxException e) {
                throw new AssertionError(e);
            }
        }
        throw new IllegalArgumentException("Not a local application classloader, can't get the local application directory.");
    }


Besides that i really think "toy" languages are the future. The more specified the language is the better and more powerful compilers will be. Gc and autodeleting aliasing types when gc is not needed? Yes please. Impossible to have null pointers? Oh god *orgasm*.
Contracts in the standard library?
(HEAVAN).

[SCO]

I think it strange that wine falls down on the dll. I remember copying dlls to the app dir many times before to make a game work on wine. Can't it be something else?

Have you used MGE on linux/wine?

[peachykeen]

You'd think it was obvious, but it is not so. The standard way most use to find out where the program dir doesn't work - it only finds out where the program was loaded from ie: the current directory.

Same as C   then, more or less.

Besides that i really think "toy" languages are the future. The more specified the language is the better and more powerful compilers will be. Gc and autodeleting aliasing types when gc is not needed? Yes please. Impossible to have null pointers? Oh god *orgasm*.
Contracts in the standard library?
(HEAVAN).

The biggest problem with Java is that it's slow, it can't be compiled to real code (ie, it always needs some kind of virtual machine to run). C# and other .Net/Mono languages, with a good JIT compiler, can compile to native machine code and so is a lot faster than Java ever could be (plus having most of the safety, the GC, as well as the option to drop to unsafe code or use C  /CLR interop on any platform). Minor technicality. VMs are good to script, JITted languages are the future.

I think it strange that wine falls down on the dll. I remember copying dlls to the app dir many times before to make a game work on wine. Can't it be something else?

Have you used MGE on linux/wine?

No, I don't have Wine, although I run Ubuntu on 2 of my machines. It may be how MGE/MWSE functions, Wine may not expose some Windows API calls that are required to attach. I've heard of MGE running on Wine, but a stripped-down older version.

[Fliggerty]

I would hesitate to make the assumption that the bug is the same as that in OBSE.  They were not developed by the same people, and to the best of my knowledge OBSE was built from the ground up (I could be wrong on that, but I recall being told at one point they didn't share any code.)

[SCO]

Well, putting aside the issue for the moment, another enhancement i'd like in morrowind is the ability to use a larger font in dialog. I think this is the best place for a fix, since if what i saw in the net is true, morrowind can only use 3 fonts and they all have the same size. As the main dialog box seems to be it's own (auto wrap) component, it would be probably best only to change it. I know the pain of finding the largest width of a component list very well from swing.

[SCO]

Besides that i really think "toy" languages are the future. The more specified the language is the better and more powerful compilers will be. Gc and autodeleting aliasing types when gc is not needed? Yes please. Impossible to have null pointers? Oh god *orgasm*.
Contracts in the standard library?
(HEAVAN).

The biggest problem with Java is that it's slow, it can't be compiled to real code (ie, it always needs some kind of virtual machine to run). C# and other .Net/Mono languages, with a good JIT compiler, can compile to native machine code and so is a lot faster than Java ever could be (plus having most of the safety, the GC, as well as the option to drop to unsafe code or use C  /CLR interop on any platform). Minor technicality. VMs are good to script, JITted languages are the future.

The CLR is almost the same as the JVM. The fundamental difference for performance is that compiled code is saved so it can be reused. Both have JIT compilers/mixed interperter.
The CLRC makes it easy to use native code from c libraries true. That is to do with the respective companies strategies. Microsoft wanted to encourage lockin, Sun wanted people to use their hardware/solaris instead of x86/windows.

I do like their code generation once strategy, but it's probably patented out of its nose.

[peachykeen]

The CLR is almost the same as the JVM. The fundamental difference for performance is that compiled code is saved so it can be reused. Both have JIT compilers/mixed interperter.
The CLRC makes it easy to use native code from c libraries true. That is to do with the respective companies strategies. Microsoft wanted to encourage lockin, Sun wanted people to use their hardware/solaris instead of x86/windows.

I do like their code generation once strategy, but it's probably patented out of its nose.

No and no. The JIT compiler and CLI VM used by Mono/.Net is hugely different than the JVM, which is the main source of the speed differences. Java can be slow, CLI is usually native-speed. It's totally off-topic here though, but there's a load of docs around you can check out to get a better idea of how they differ technically.

As far as font size, you can use different fonts (including created ones), but it is true they don't resize. They're in some poorly-documented binary (possibly image) format, and only a few tools can convert to/from.

And Fligg, as far as OBSE/MWSE/MGE, there are some similarities in the systems and I think the OBSE and MWSE launchers are probably pretty close (started a suspended thread is standard practice for a loader). MGE does use a totally different way, though.

[SCO]

http://shootout.alioth.debian.org/u32/b ... ng2=csharp

neither compares to well coded c of course. and it isn't comparing the "real" c# since it is the debian site, but i don't expect massive differences.

I was just thinking that the morrowind dialog system seems component based, what with the reflowing windows and "virtual" window manager like inventory. Component systems normally allow one to set the font size individually. If it could be found what object the main dialog component is (assumpation it is a component, and there is a function to change the font, and it is a singleton etc), so a larger font could be created.