Guild of Writers

I'm still a bit confused here about the Python files.

For certain things (GUI Pop ups, etc), we need to use a Python File Mod for our responder.

When I was first working with GUI Pop ups, I knew I needed to get the Plugin to find the xDialogToggle python file. There was (and still is) no info on the GoW Wiki about this, and I was not surprised since it had only been a few weeks since we had gotten the Plugin.

I went over to the MOUL forums and found someone asking about the Python files as well. Mookow said over there:

We need Cyan to release their MOULagain python files, but for those who just like to 'fiddle' -

Grab glue.py and the Plasma*.py scripts from an earlier version of Uru and copy them to C:\PlasmaTest\python\plasma\

Any scripts you throw in the top level python folder which contain a class that derives from ptModifier will now appear in the python component drop-down. Selecting a script from this list will bring up more options to set attributes specific to that file.

If your scripts don't show up in the list, check your import dependencies. You will likely also require modules from the python standard library. (string.py, re.py etc.) I assume these can go in the python\system folder to keep everything organized.

Now I was unsure of how this was worded, and in my own bumbling way, I did get it to where the drop down box would display xDialogToggle, xStarTrekDoor, and xStandardDoor, but that was it.

So this morning, I grit my teeth and did this:

I decompiled ALL of the python files in Uru's Python.pak file. I copied them over to C:\PlasmaTest\python\plasma......and also C:\PlasmaTest\python too (I'm not sure if they need to be in both or not).

Once I restarted Max, check it out! LOTS of python files to choose from the drop down box now:



Hehehehehe......MWAHAHAHAHAHAHAH! Take a look at the options for xLinkingBookGUIPopUp:



:busy doing little Python Happy Dance: Yippy!!!!!!

kk, word of warning:

For linking books (and journals for that mater), you can get them to link you anywhere you want. However, if you use the game's "xLinkingBookGUIPopup" you will be stuck using the games image panels for linking books.
This is fine if you are just planning on linking to somewhere that already exisits in the game. But if you are going to link to another fan Age or another part of your Age, you'll have a problem here.

OH, and of course right now, without the MOUL python files, you won't have the image panel for places like Delin, Tsogal, Minkata, etc, etc. Once you have the MOUL python files, you can use it, but then again, you'll run into a problem in game.

You'll have to make your own xLinkingBookGUI python file, so it works with Cyan's plugin, and you'll also have to make your own XLinkingPageDefs too.

You might be able to modify the games python files, but I was always taught that's a no-no, and then again, if you're sharing you Age with people, you'd have to replace their Python.pak file too, so I see a problem with that, heh.

andylegate wrote:kk, word of warning:

For linking books (and journals for that mater), you can get them to link you anywhere you want. However, if you use the game's "xLinkingBookGUIPopup" you will be stuck using the games image panels for linking books.
This is fine if you are just planning on linking to somewhere that already exisits in the game. But if you are going to link to another fan Age or another part of your Age, you'll have a problem here.

OH, and of course right now, without the MOUL python files, you won't have the image panel for places like Delin, Tsogal, Minkata, etc, etc. Once you have the MOUL python files, you can use it, but then again, you'll run into a problem in game.

You'll have to make your own xLinkingBookGUI python file, so it works with Cyan's plugin, and you'll also have to make your own XLinkingPageDefs too.

You might be able to modify the games python files, but I was always taught that's a no-no, and then again, if you're sharing you Age with people, you'd have to replace their Python.pak file too, so I see a problem with that, heh.

IF you really want to use linking panels for the ages, besides your own xLinkingBookGUI python file and xLinkingPageDefs, you can also attach a Image Library component to a dummy object in 3ds max. This component allows you to attach images to it, it creates a library of your images and you just reference your image name in your xLinkingPageDefs.

Fan-ages should never ever ship a modified version of an original Cyan file though. Everything should be in the age namespace (starting with the age's 4-digit abbreviation, or the full age name). Everything else will quickly lead to brokenness and incompatibilities.

diafero wrote:Fan-ages should never ever ship a modified version of an original Cyan file though. Everything should be in the age namespace (starting with the age's 4-digit abbreviation, or the full age name). Everything else will quickly lead to brokenness and incompatibilities.

That'd be my philosophy as well. It just sound safer there's a way to circumvent the need of an actual global python file. If worst comes to worst you can probably use a Age-local GUI that will look just like a linking panel. And as an added bonus it would also allow you to use Bink videos for the panels, which the regular GUI panels don't allow.

Giving the Age it's own pak file is what I was trying to do yesterday.......before I got interupted to go repair my sister's HVAC unit.......and then got distracted by "Something, Something, Something, Dark Side......." heheheheheheh (I'm still rolling with laughter from watching that last night).

What I found yesterday while talking with D'Lanor, is that you can take the xLinkingBookGUIPopup file and open it up in PlamsaShop, edit it (I think we can make a template for others to use) for your Age, the important part being the filemods at the begining as the Plugin needs these when you set it up in max. Make a copy and place it in the C:\PlasmaTest\Python directory (also the C:\PlasmaTest\Python\Plasma dir), then you can assign it to your linking panel in Max.

This means when you edit it, you need to change the references in it that refer to the xLinkingBookPageDefs to your own PageDefs, but your PageDefs file will need to look like Cyan's format. Again I think we can make a template for people).

Then after export and conversion, you'd already have xYourAgeBookGUIPopup and xYourAgePageDefs in pak file for itself.

I got this far yesterday, but had a python error when I tested it in game due to some typos, and then got called away from the computer. I'm going to try again today.

There is another issue with this method, another reason why using D'Lanors book template should be preferred: If you use Cyan's file, the information about the actual linking (like linking rules, display age name, spawn point name & title etc.) is saved in the prp, in a linking responder. However this is a complicated matter, and age writers tend to get it wrong repeatedly (even Cyan got it wrong when they were not forced to be multiplayer-compatible, like in POTS). This is no problem offline, as the linking rule is always overwritten, and the worst that can happen is some broken pages in Relto. Everything can be fixed by removing the avatar. However, when the ages are used online - UU, Alcugs, MOUL, that does not matter - every mistake will be manifested in the vault, and removing it usually requires directly accessing the SQL tables - or removing the whole vault. Python files can be easily automatically checked and fixed to use the xLinkMgr shipped in the Offline KI (so that's what I do when I need a mutliplayer-safe version of an age). That xLinkMgr uses the information from AvailableLinks.inf which I worked hard on to be consistent with Cyan's linking responders wherever possible (which required disabling some of these responders). It literally took me weeks to get that file right. xLinkMgr also ensures that whatever the age requests, it will never do an invalid link.
If however fan ages do the linking like Cyan does, this can't be fixed in Python. And I am very sure that some age writers will get these rules wrong, link to ages they should not link to, add owners to ages without need, create inconsistent age display names or spawn point titles... that whole system is so horribly broken, you almost have to get it wrong. So, if it is somehow possible, please continue using D'Lanors book template, which does the linking in Python.

We can use D'Lanor's templates, but they'll have to be modified for Max/Cyan Plugin users. You HAVE to tell the linking panel what it's components are, and if you're going to use Max and the Cyan Plugin, this means assigning the panel a Python Mod, and a Responder. If you place D'Lanor's BookGUI python file in with the other python files for Max, you will not get the file mod options when you select it. Again, we could simply use a modified version of his template is all.

DO NOT place his PageDefs template in with the other python files for Max however. It will crash Max like you wouldn't believe! D'Lanor thinks it has something to do with his "creative way" of making the definitions, heh. But that's cool as you don't NEED the PageDefs there to make this work. Just the BookGUI file.

You're absolutely right about the linking rules, and it's why I made this tutorial here about them:

http://www.guildofmaintainers.org/Forum ... 154&t=1683

The important thing to note is: you apply the linking rules with the Responder that you attach to your linking panel.

Technically, you don't even need a python file to create a working link with they Cyan plugin. You can select any object you want, assign the Clickable component and a Responder component. That's all you need. In the Component Utils for the Responder, you simply define the linking there:



So no python files are absolutely needed. I show this in my tutorial here:

http://www.guildofmaintainers.org/Forum ... 154&t=1681

The python files are needed so that you can have a GUI Popup of a linking book, journal book, or Bahro stone. Technically, you could get around having to use xLinkingBookGUIPopup and xLinkingBookPageDefs by simply making your very own GUI Popup and using the xDialogToggle python file mod instead. You'd have to make your linking panel and ClickOff panel, etc, etc.

I'm going to mess around with this more this morning and I'll come back here and report what I've found

andylegate wrote:DO NOT place his PageDefs template in with the other python files for Max however. It will crash Max like you wouldn't believe! D'Lanor thinks it has something to do with his "creative way" of making the definitions, heh. But that's cool as you don't NEED the PageDefs there to make this work. Just the BookGUI file.

I have a few ideas about that. First you can try adding the line from PlasmaTypes import * to YourAgePageDefs.py. If I am not mistaken every Cyan Python file has that line by default, even if it doesn't need the PlasmaTypes module. So maybe it is just there for the benefit of the Max plugin.

Another "creative" method I have used is importing the PageDefs module through: __import__('YourAgePageDefs'). This allows us to import a Python module as a string. The advantage is that you only have to replace the name once in the template. Cyan never uses this method though. You can try to replace this with a normal import at the beginning of your BookGUI file (without quotes) and see what happens:

Code: Select all

import YourAgePageDefs

However, you probably won't get to see linking panels in Max anyway if you use my template. I suspect that the linking panel needs to be added as a parameter in the Pythonfilemod if you want Max to see it.

Thanks for that long and detailed explanation about linking rules, andy . It will hopefully clear some mysteries for some people.
However, even provided everyone reads and understands your tutorial, there are some pitfalls. For each link, you have to specify not only the age filename, but also the age instance name - and if that one is not consistent, the age name you see depends on where you get from when you link there the first time. The same holds for the spawn point title, which should be unqiue for each spawn point name. And then when someone links to a Cyan age... basically, you should never do that. As long as fan ages only link to other ages of the same author, he can make sure the settings are correct (though some shard admin might not like the age owners folder to be needlessly spammed with ages). But as soon as ages link to other people's ages, they need to coordinate - or a central place to store all information. Like that config file in the Offline KI.

I never understood why Cyan introduced this mess. Every reasonable programmer would have introduced a central database mapping age filename to age display name and linking rules, and that whole concept of spawn point titles is also needless. A link should just be the the age filename, and the spawn point name, so that the age designers don't have to think about all the rest ("bring me to this position in that age", and nothing more to think about), and the rule and age name definitions are easy to maintain in one place.