Offline KI

[diafero]

Offline KI version 2.5.3 brings the following changes:
- If you use Drizzle 14 to convert the MOUL files, you can use MOUL avatar emotes in TPTOS (the male animations all look a bit... wired But you can quickly try out the famale ones by typing "/avatar female" and then get your original avatar back with "/avatar male")
- The MOUL additions to the easer egg commands /look and /get are now also included
- Ages which you have installed but which are not know by the KI automatically get added to the bottom of the Nexus list so that you can easily access them
- Added /set command to easily change some age's options - currently supported:
> in Delin: /set winter 0|1
> in the hood: /set delinglass|tsogalglass|gzglass 0|1|2
> in the city: /set bahro 0|1
If you have suggestions for further settings, please let me know
- Changed /bahro command, it is now used only to trigger certain Bahro (/bahro [0-6]), not to control the arch Bahro - that is done by /set bahro
- The Bahro in the city are controlled randomly
- The list of supported ages has been updated, too, and now also includes "Sprite Gallery" and "Writers' Niche"

To download the latest Offline KI or get a full list of features, see http://diafero.bplaced.net/

EDIT: Something I forgot: The MOUL emotes and easter egg stuff was done by Dustin (with some small changes of mine), and the idea of adding unknown ages to the Nexus was also by him (the implementation was then done by me).

[Christian Walther]

I installed this the manual way, leaving out all changed ages except GUI, GlobalMarkers, Nexus as described here, and found that I was unable to bring up the Relto book. I don't know if this is a situation you want to handle, and I don't know if it's the proper way of handling it, but how I fixed it is

Code: Select all

--- xKI.py   2009-01-04 17:34:03.000000000 +0100
+++ xKI.py   2009-01-04 19:03:32.000000000 +0100
@@ -4618,9 +4618,9 @@
             if psnlSDL:
                 for (sdlvar, page,) in xLinkingBookDefs.xYeeshaPages:
                     FoundValue = psnlSDL.findVar(sdlvar)
-                    PtDebugPrint(('xKI: The previous value of the SDL variable %s is %d' % (sdlvar,
-                     FoundValue.getInt())), level=kDebugDumpLevel)
                     if (type(FoundValue) != type(None)):
+                        PtDebugPrint(('xKI: The previous value of the SDL variable %s is %d' % (sdlvar,
+                         FoundValue.getInt())), level=kDebugDumpLevel)
                         state = (FoundValue.getInt() % 10)
                         if (state != 0):
                             active = 1

(The problem is that xLinkingBookDefs.xYeeshaPages has variables that the old SDL doesn't know about, so FoundValue comes out as None and FoundValue.getInt() raises an exception.)

The other solution, I guess, would have been to install the modified Personal.sdl - or would having newer SDL than PRPs cause problems? Or is that what the different version sections in the SDL are for?

Two other observations:

• I didn't find any documentation about how to enable the fly mode. I only found out by accident that it's the ESC key. Did I not look hard enough or is there none?
• Apparently it's not possible to configure a "start chat" key in the GUI, is there a preconfigured one, or is the standard way of entering chat mode "hit a non-assigned letter key and delete the letter if necessary"? (Not really an issue since all I do in chat mode is type commands, and / is not on an assigned key for me so I can just start typing.)

[diafero]

The other solution, I guess, would have been to install the modified Personal.sdl - or would having newer SDL than PRPs cause problems? Or is that what the different version sections in the SDL are for?

Yes, installing the SDL should be the best, I don't know what negative side-effects your patch will have (because the game assumes all the SDL vars to be present). The SDL should not cause any problems, not because of different SDL versions but because the new SDL vars can simply be ignored - so that is the cleanest solution.

I didn't find any documentation about how to enable the fly mode. I only found out by accident that it's the ESC key. Did I not look hard enough or is there none?

Oh, that's true, I'll add it to the command page - thanks for the hint

Apparently it's not possible to configure a "start chat" key in the GUI, is there a preconfigured one, or is the standard way of entering chat mode "hit a non-assigned letter key and delete the letter if necessary"? (Not really an issue since all I do in chat mode is type commands, and / is not on an assigned key for me so I can just start typing.)

I don't know of any key like that - just like in UU or MOUL, the chat line comes up when it thinks you want to type. To be honest I never thought about that, it was just the way it was

[Lontahv]

Have you tried femaleswimunderwater yet? I've been very curious about that one as soon as I saw the name a few months ago.

[diafero]

Indeed, that looks interesting, as does FemaleSwimSurfaceDive.
What is also strange is that BlowKiss doesn't have a prp file, even though it is referenced in the Python like all the other emotes are.

[Chacal]

The SDL should not cause any problems, not because of different SDL versions but because the new SDL vars can simply be ignored - so that is the cleanest solution.

FYI - I am working on a framework for easy distribution of all modifications to POTS. The work is well advanced and is working fine.
This framework allows for distributing changes only, as opposed to distributing entire (possibly copyrighted) files.

A distribution will include a script, data files and utilities such as libPlasma and urusum.
There will be NO manual actions from the user, other than saving the distro files in a folder and executing a script.
The script will modify the user's existing files.

Changes supported include:
- changes to SDL files (not conflicting with the user's current SDL changes. Supports correct SDL versioning procedure).
- changes to .age, and .fni files
- changes to prp files
- new prp, .sdl, .age, .fni files
- new python packs

Changes are described in a distro.xml file and the script applies them.

I've got this working now and I'm refining it.

[ddb174]

Lohtahv and Fero: I just tried those out now. femaleswimunderwater is a breaststroke. femalesurfacedive is as if you dived head first into the pool then straightened out.

Chacal: that would certainly be handy for passing around perturbations against a clean installation, though it isn't possible in general against an already modified copy, due to unresolvable conflicts. For prp files bsdiff is similarly very effective, though bsdiff doesn't typically work well against the whatdoyousee files.

[Chacal]

Can you provide examples of unresolvable conflicts?

I have no problems with encrypted files, using Plasmacrypt.exe from libPlasma.

For example, for changing values for SDL vars the script does this:
- read the changes from the xml file;
- copy the SDL file from the game dir;
- decrypt the SDL file;
- grab the last version of the STATEDESC block;
- increment version number;
- for each change, delete any existing entry for the var and append the new var;
- append the new STATEDESC block to the file;
- encrypt the file;
- copy the file back to the game dir

For changing prp files the script does this:
- read the changes from the xml file;
- extract the prp file from the game dir into individual object files;
- replace some object files by those from the distro;
- repack the prp file;
- copy the file back to the game dir
- re-sum the Age if needed

femaleswimunderwater is a breaststroke.

All kinds of pleasing images come to mind.

[ddb174]

Can you provide examples of unresolvable conflicts?

I'm talking about conflicts between patches, e.g. one patch removes the fence collider, while another patch attempts to modify it. It's not a problem with your idea, just a problem that comes up in these situations. So long as one is just patching a clean installation, there are no problems.

I have no problems with encrypted files, using Plasmacrypt.exe from libPlasma.

It's bsdiff that has that problem, which would be an advantage your system would have over bsdiff. I should have mentioned that bsdiff is a binary diff/patch utility.

[Chacal]

I'm talking about conflicts between patches, e.g. one patch removes the fence collider, while another patch attempts to modify it. It's not a problem with your idea, just a problem that comes up in these situations. So long as one is just patching a clean installation, there are no problems.

Yes, I thought about that. It becomes a decision for the user.
Technically it should still work, as "modifying an object" means "replacing with a new object".
The patcher can only add an object, replace an object or delete an object.
So this is always working whether or not the user had deleted or modified the object.
The user can then decide to apply the previous changes again. This would be easy if the previous changes were done with the patcher.