Thursday, October 21, 2010

Oblivion on Wine 1.2.1 & 1.3.5

Well, it has been a VERY long time since my last post for Oblivion on Wine. Close to a year, in fact. I've just recently started playing Oblivion again, and I think I've finally got the problem with frequent hard drive failure under control. Word to the Wise: Do not rely on SATA, if you value your data.

Now, to get things started. Here's the current environment of my machine:

Processor: 2.6ghz AMD Athlon X2 5000+ Brisbane
Memory: 4gb of DDR2-800 SDRAM
Video Card: BFG Tech GeForce 9800 GT, 1gb of video RAM, overclocked out of the box
Operating System: Arch Linux 2010.05, i686 architecture
Linux Kernel:
Video Driver: 260.19.12-1

Now then, this report is covering two different versions of WINE: version 1.2.1 and 1.3.5. Version 1.2 is the stable branch of WINE, while version 1.3 is the unstable branch. I initially was using WINE 1.3.4, and then 1.3.5. The game's performance seems unchanged from version 1.1.32, the last version I had tested with.

In terms of stability, it appears to be suffering from some reproducible crashes related to memory read (or is write?) errors, which briefly made it impossible to complete the Kvatch questline. This, however, may be in part due to the amount of mods I've installed, in particular Martigen's Monster Mod. Though, I am pleased to say that I no longer crash when activating the Aurum Assimilator from the Midas Magic mod.

I was also having a number of rendering errors. Stalagmites and stalactites in caves would suddenly vanish or appear elsewhere, people's hair would vanish. Perhaps the worst was monsters with hair would occasionally cause the entire screen to be filled with solid colors, the only thing visible being myself, spells, and the monster's head. This was worse with scamps while in the towers on the plane of oblivion, where the whole screen would go black while trying to cross a narrow bridge.

While trying to get Command & Conquer 3: Tiberium Wars to install, I accidentally broke my wine installation. After a couple of full reinstall attempts (read: delete the .wine directory and start from scratch), I got it working again. This time, the rendering glitches vanished and I was crashing somewhat less frequently.

Eventually though, I decided to downgrade to WINE 1.2.1, the stable version of WINE. If you're on Arch Linux, you can find it as the wine-stable package on AUR. I found no changes in performance or stability between the two versions. HOWEVER, I did fine one thing that pleases me very much about version 1.2.1: OBSE works! It may be too soon for me to say that, but I have tested it with the keychain mod, and found that it worked without a hitch!

I'll report any apparent OBSE problems below, should I encounter them.

OBSE Issues
* OBSE appears to cause a crash/freeze when shutting down Oblivion.
* One hotkey mod I tested did not work completely (wouldn't detect 0 and 9 keypresses)
* The MiniMap HUD has rendering issues, when it displays at all.
* Not OBSE-related, but the numpad keys are not detected by Oblivion.

In addition, I found one report that OBSE works under WINE 1.3.4 if you use the wineconsole utility. I've contacted the reporter for further details.

More on OBSE
After upgrading to version 1.3.5 for a quick test, I've found that OBSE works without the use of wineconsole. However, in my case there is something special I must do in order for it to work. It must be launched while emulating a virtual desktop, like so:

wine explorer /desktop=Oblivion,800x600 ./obse_loader.exe

Launching it any other way causes it to crash on startup with 100% consistency (for me, at least). If I launch it by command line (with or without wineconsole), or launch it from its folder in a file manager, it always crashes. Even if I turn the "Emulate a virtual desktop" option on in winecfg, it still crashes. It seems using wine explorer to launch it is the only way I can make it work.

HDR Lighting
One more quick thing to report: under my current setup, HDR works! However, this is while using the Shader Model 3.0-capable shaders package. Scroll down to "bAllow30Shaders" under the graphics variables section, and you can find instructions on how to enable it here:

Sunday, May 23, 2010

KDEmod's Build System: What The Hell!?

One thing I've done a lot is compiled optimized builds of the software packages on my system, to improve their performance and memory usage.  However, this doesn't make as much of a difference as it used to.  I originally started using Linux on a dated 450mhz pentium3 system, and I'm now using a homemade system with a 2.6ghz AMD Athlon X2 5000+ Brisbane processor.  That, and I'm using Arch Linux, which already has its packages built with some optimization.

So, the performance gains of an optimized build aren't as great as they used to be.  But I still do it from time to time with frequently-used programs, as I am usually a heavy multitasker.  KDEmod is a branch of KDE that I've been using since I started Arch Linux.  It is more modular than Arch Linux's official packages, and is optimized for Arch Linux as well.  It also has its own build system, separate from Arch Linux's build system.

However, I was only able to get it working with the 3.x branch of KDEmod.  With the new 4.x branch, I was never able to.  And today, I decided I wanted to compile an optimized build of Okular.  So, I go over to the KDEmod wiki to check their build system's instructions.  It has changed, a lot.

It requires you to install a chroot environment, which is essentially a miniature linux installation that runs within the main installation, but without any virtualization.  For the few gigabytes of extra hard drive space that this takes up, KDEmod's build system is simply not worth it.  Especially if you're limited on hard drive space like I am.  I only have a 40gb PATA drive that is at least 90% full, so a chroot environment isn't an option for me.

And, at this point, I'm wondering if it's even worth it to use KDEmod anymore.  I don't see any real advantages in it for me anymore.  I don't even use KDE as a desktop environment: I use LXDE.  I just have KDEmod installed for a few of the applications.

Friday, February 26, 2010

Pyramid Script

The pyramids of ancient Egypt have fascinated mankind for millenia, and quite often find themselves replicated in some manner in Second Life.  However, most people who create them don't give their pyramid geometrically accurate dimensions.  An Egyptian pyramid's slopes run at a 52 degree angle, whereas most would make it at a 45 degree angle.  However, using this small script, you can turn any prim into a geometrically-accurate pyramid:

//Converts any prim into a geometrically-correct pyramid with slopes at a 52 degree angle, the same as the pyramids of egypt.
//Written by Zauber Exonar
//Special thanks to Aamira Aeon for helping with the geometry

default {
    state_entry() {
        vector scale = llGetScale();
        //Making sure the base is square
        if(scale.x != scale.y) {
            if(scale.x > scale.y) scale.y = scale.x;
            if(scale.x < scale.y) scale.x = scale.y;
        //calculating the height of the pyramid
        scale.z = llTan(DEG_TO_RAD * 52) * (scale.x / 2);
        //calculating the position so that the pyramid's bottom stays at the same elevation
        vector pos = llGetPos();
        pos.z = pos.z + (scale.z / 2.0);
        //setting primitive parameters for turning the prim into a tapered cube
        list params = [PRIM_TYPE, PRIM_TYPE_BOX, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <0.0, 0.0, 0.0>, <0.0, 0.0, 0.0>];
        //Applying changes to the prim
        llSetPrimitiveParams(params + [PRIM_SIZE, scale, PRIM_POSITION, pos]);
        //Removing the script from inventory

You can view the script better here:

Thursday, January 21, 2010

Naturalistic Fallacy: Natural Doesn't Mean Safe!

Every once in a while, you hear some health nut or organic produce advocate say "If it's natural, it's safe!"  They repeat this without questioning it.  But when you seriously think about it, you realize just how false that line of thinking.  Scholars of logic have a few names for this line of thinking: "Naturalistic Fallacy" or "Appeal to Nature".  It is defined as the mistaken assumption that because something is natural, it is safe or morally acceptable.

There are numerous arguments to disprove that line of thinking.  Nobody in their right mind would believe that rape, incest, murder, or cannibalism are morally acceptable or safe.  And those all occur in nature.  But what about natural being safe?  As I said before, health nuts and advocates of organic products claim that natural means safe.

So, what in nature is unsafe?  A lot of stuff:  Poison Ivy, Poison Oak, and Poison Sumac, for starters.  Then we have Tobacco and Eggplant, which contain nicotine.  Solanine, the alkaloid toxin behind Deadly Nightshade, which is also found in the leaves and stems of Tomatoes and Peppers.  Any plant with the name "Bane" in it is generally going to be poisonous.  The Castor Oil Plant, which contains the notorious poison Ricin.  Then there's Hemlock, which causes stomach pain, vomiting, and paralysis.  Hemlock is best known as the poison used to execute Socrates when he was sentenced to death.  Another one is the Strychnine Tree, from which the pesticide Strychnine originates.

And then, there's mushrooms.  There are hundreds of poisonous species of mushroom, many of which are deadly.  Death Caps earned their name for good reason!  And many of the deadly mushrooms look almost exactly like the ones that are safe to eat!

Poisons aren't just limited to plants and fungus, either.  Many members of the animal kindom are poisonous too.  Snakes are well known for their venom.  The skin secretions of frogs are often poisonous or act as a painful irritant.  Toads produce a milky cocktail of toxins and irritants when aggravated.  Many insects have poisonous bites or stings.  All spiders have poisonous bites, though very few species are able to cause more than mild irritation, but the more poisonous species (like the black widow and brown recluse) are very notorious.  Scorpions are well known for their poisonous stings, too.  Then, there are bacteria.  Many species of bacteria make you sick because of the toxins they produce, such as the infamous E-Coli bacterium.  And (unless you're a conspiracy theorist), viruses are natural too, and they are almost universally harmful.

If you thought that natural meant safe, are you still convinced?

    Monday, January 18, 2010

    Unlock the Limit on Object Movement Distance

    You ever notice how after you move an object 30 or so meters at once, you can't move it any further and need to release it and then start moving it again? Well, I've found out how to disable that behavior! Here's how to do it:

    1) Go to the Advanced menu. If you don't have it, press CTRL-ALT-D (CMD-ALT-D on Mac, CTRL-ALT-SHIFT-D on Linux) and it should pop up to the right of the Help menu.
    2) Select the Debug Settings option from the advanced menu
    3) type "LimitDragDistance" into the Debug Settings window
    4) Set it to FALSE, and close the window

    Now, you should be able to move objects without having to start and stop frequently.

    Monday, January 4, 2010

    OpenSimulator's Fail: Admin Powers for Sim Owners

    For anyone who has run opensimulator at one point or another, you are probably already familiar with the "god powers", or the Admin menu. Like its name implies, it gives you some elevated powers that let you do things not normally possible. While very useful, they have a darker side to their utility.

    By default, sim owners on OpenSimulator are able to obtain admin powers without restriction. There are three main admin powers that are of particular concern under the Admin->Object menu: Take Copy, Force Owner To Me, and Force Owner Permissive. The first two allow the sim owner to force ownership of a rezzed object to themselves, or to take a copy of it into their inventory. The last one, Force Owner Permissive, allows them to obtain creator permissions on a rezzed object: it effectively becomes full permission to them.

    The implications of these abilities are obvious: a dishonest sim owner can become a content thief easily. All he needs to do is rez an object on his sim, or trick someone into rezzing the object, and can immediately take ownership and gain full permissions. But it doesn't just stop there. At least two online marketplaces for Second Life are branching out into OpenSimulator, allowing merchants to sell on opensim grids.

    What does that mean? A dishonest sim owner can gain creator permissions on the ATM's and Vendors used by the marketplace, and gain full view of their networking protocols. Using this, they can steal funds from other marketplace users by spoofing their UUID's, or try and trick the system into delivering free merchandise to them.

    Copybot can't do this: it can only "steal" the content it can see, and it is unable to grab the object contents because it can't see them. And even if it could see them, the permissions would prevent theft to a degree. But what can be done with admin powers is worse: copybot just rips what it can see. The admin powers let you directly grab the ownership of an object and change its permissions.

    With these capabilities at the fingertips of sim owners, commercial activity within opensimulator grids simply is nowhere near viable. Virtual commerce can only be viable on grids that do not allow sim owners access to admin powers. To my knowledge, there aren't any grids which block access to admin powers. Not even professional grids like ReactionGrid block it. So, until we get grids that block access to admin powers, you can just forget trying to sell content on opensimulator.