Python Files

[andylegate]

Thanks diafero for the info, I'll add it. 99% of what you read is from D'Lanor. I didn't know squat about linking rules until he sent that to me.

Okay, sorry D'Lanor, but no matter what I try, your PageDefs crashes Max every time ("Error 988 - Invalid Memory Access). I tried everything you suggested, and I don't see WHY it should cause that, but it does.

The good news is that I did make it work by using a modified copy of xLinkingBookGUIPopup and xLinkingPageDefs. My book popped up just fine, with the correct linking panel image that I specified, and I linked just fine.

Let's be clear: if you're making an Age and plan on making a linking book that links to a "stock" Uru:CC/POTS Age, you don't have to have your own python file for that, and can use xLinkingBookGUIPopup python file mod, and make sure you use the Linking Rules in the responder correct.

But for converted MOUL Ages, Myst V Ages and Fan Ages, yah, we have to have our own python file. I propose a rewritten xLinkingBookGUI and xLinkingPageDefs files, that can be used as templates for Max users. I can write a tutorial how to use it, and why you have to use it.

[D'Lanor]

My notes which Andy has used for those tutorials are rather old. They were made during Until Uru and are for Cyan shards only. Diafero's point of view however is heavily Alcugs biased. Alcugs shards by default have no instancing. Even though one can configure ages for instancing it is not often done on Alcugs shards. And that is the main gripe I have with Alcugs.
IMO fan ages should be personal ages - in the AgesIOwnFolder - unless specifically designed as community ages. This is especially important if there are puzzles: People should have a choice to solve their puzzles alone. And yeah, I can see a conflict there with puzzle shells in Pahts...

The tutorial does mention that for the kOriginalBook linking rule one must set the correct age info, including the age instance name. What it does not mention is that if you do not set the age instance name the age name is used as the instance name. For most fan ages that is fine, but Cyan's ages often have different age instance names. Personal vs Relto, Garden vs Eder Kemo, Garrison vs Gahreesen, city vs Ae'gura, etc. etc.
However, I cannot think of any examples where a wrong age instance name actually breaks anything but it does look ugly in the KI.

Now spawn points are a different story. If you get those wrong you will break the Relto bookshelves and Nexus of your users. Their linking panels may never show up if they use a link from a fan age before getting their link the "official" way. Unfortunately writers keep linking to Cyan's ages no matter what we say. I think this is a lost cause diafero.

[Aloys]

IMO fan ages should be personal ages - in the AgesIOwnFolder - unless specifically designed as community ages. This is especially important if there are puzzles: People should have a choice to solve their puzzles alone. And yeah, I can see a conflict there with puzzle shells in Pahts...

hmm, indeed. I guess we'll have to give that some thinking..

[andylegate]

IMO fan ages should be personal ages - in the AgesIOwnFolder - unless specifically designed as community ages. This is especially important if there are puzzles: People should have a choice to solve their puzzles alone. And yeah, I can see a conflict there with puzzle shells in Pahts...

hmm, indeed. I guess we'll have to give that some thinking..

Sounds like an excellent reason to have people test things before they are put on a game server (very, very shameless plug for Maintainers.....hehehehehehehehehe)

You know, I didn't know that about Alcugs. Is it something that can be changed? I mean for people that want to have personal instances?

I know what you mean about linking to Uru Ages however. But also, while editing the xLinkingBookGUIPopup, and looking at the linking rules in the responder with the Cyan Plugin, when used right, a player should never be able to link from say, Bubba's BBQ Diner and Pub Age straight to Kemo let's say, if the play does not have Kemo on their shelf.

But yah, as I just said "when used right".

While looking at the python files though (the xLinkingBookGUIPopup), I want to edit out all the stuff for Ahnonay spheres and the cleft, etc, etc. But when it comes to Python, I'm like an Electrician trying to disarm a Bomb. I know just enough to be REALLY dangerous, hehehehehe.

[D'Lanor]

I know what you mean about linking to Uru Ages however. But also, while editing the xLinkingBookGUIPopup, and looking at the linking rules in the responder with the Cyan Plugin, when used right, a player should never be able to link from say, Bubba's BBQ Diner and Pub Age straight to Kemo let's say, if the play does not have Kemo on their shelf.

Yes, in that case you would use kOwnedBook. But then it will look strange if you click on a linking panel and nothing happens. That is why I added a "force owned" setting to my template which will hide linking panels for unowned ages. Now if only the template would work... but since I don't have Max 7 there is just no way for me to debug this.

[andylegate]

Well I don't have an extra copy of Max.......but I do have this, some text from the Plugin Documents that talks about Python and how it relates to the Plugin. I don't know if you bothered to look at the document that Chogon put out since you didn't have Max:

PLASMA PYTHON ATTRIBUTES
When the Plasma Max plugin starts, it reads in the Plasma Python components. It then extracts the attributes and build Max rollout dialogs based on the attributes. This way the Python programmer can create a unique Max interface for each python component.

When the Max users selects a Python component and attaches it to a scene object, the unique rollout dialog is shown and allows them to specify what objects and parameters that the Python code will test or manipulate. This allows the python component to be re-used in different places because of the uniqueness of the attributes.

The attribute types available are:
• ptAttribBoolean – true or false
o in Max: a checkbox
• ptAttribInt – integer number
o in Max: a number spinner
• ptAttribFloat – floating point number
o in Max: a number field
• ptAttribString – a string
o in Max: an edit box
• ptAttribDropDownList – number selection
o in Max: a pull down menu
• ptAttribSceneObject – scene object
o in Max: a scene object picker
• ptAttribSceneObjectList – a list of scene objects
o in Max: a multiple scene object picker
• ptAttribActivator – a detector
o in Max: a detector picker
• ptAttribResponder – a responder
o in Max: a responder picker
• ptAttribDynamicMap – a dynamic texture map
o in Max: a material picker with just dynamic texture maps
• ptAttribGUIDialog – a Plasma GUI Dialog
o in Max: a GUI dialog picker
• ptAttribExludeRegion – an exclude region (may not be used in Sasquatch)
o in Max: an exclude region picker
• ptAttribWaveSet – a wave set pixel shader
o in Max: a Wave set picker
• ptAttribGlobalSDLVar – a global SDL variable
o in Max: a pull down of SDL Variables
• ptAttribAnimation – an animation
o in Max: an animation picker
• ptAttribBehavior
o in Max: a behavior picker
• ptAttribMaterial
o in Max: a material picker

That's all they have. And it makes sense as if you look at the beginning of the xLinkingBookGUIPopup file, you see this:

Code: Select all

from Plasma import *
from PlasmaTypes import *
from PlasmaKITypes import *
import string
import xLinkingBookDefs
from xPsnlVaultSDL import *
import time
actClickableBook = ptAttribActivator(1, 'Actvtr: Clickable small book')
SeekBehavior = ptAttribBehavior(2, 'Smart seek before GUI (optional)')
respLinkResponder = ptAttribResponder(3, 'Rspndr: Link out')
TargetAge = ptAttribString(4, 'Name of Linking Panel', 'Teledahn')
actBookshelf = ptAttribActivator(5, 'Bookshelf (Only used in PsnlAge)')
shareRegion = ptAttribActivator(6, 'region in which the sharer must remain')
shareBookSeek = ptAttribBehavior(7, 'smart seek & use book for share acceptance')
IsDRCStamped = ptAttribBoolean(10, 'DRC Stamp', default=1)
ForceThirdPerson = ptAttribBoolean(11, 'Force 3rd person', default=0)
LocalAvatar = None
OfferedBookMode = false
BookOfferer = None
stringAgeRequested = None
PageID_List = []
SpawnPointName_Dict = {}
SpawnPointTitle_Dict = {}
OffereeWalking = false
ClosedBookToShare = 0
BookNumber = 0
CurrentPage = 1
gLinkingBook = None
NoReenableBook = 0
kAhnonayBookshelfBook = 12
kGrsnTeamBook = 99
kFirstPersonEnable = 1
kFirstPersonEnableTime = 0.5
class xLinkingBookGUIPopup(ptModifier,):
    __module__ = __name__

    def __init__(self):
        ptModifier.__init__(self)
        self.id = 5221
        version = 27
        minor = 4
        self.version = version
        PtDebugPrint(('__init__xLinkingBookGUIPopup v%d.%d' % (version,
         minor)))



And when you select this file as your python file mod in Max, you can see in the roll out boxes for the component:



I don't think it's your PageDefs that is actually causing the crash. I think it's the BookGUI. The plugin seems to ignore the BookGUI unless you have the definitions file there. It would not let me select (heck, it wouldn't even show it in the drop down box) xLinkingBookGUIPopup file unless I have the xLinkingBookDefs file in the same folder.
This goes for my modified version of those 2 files too. OutsideBookGUI would not show up until I had made and placed my OutsideBookDefs file in the same folder.

So, yah, I think it's in the BookGUI folder. I tried removing the ___import___('YourAgePageDefs'), but that didn't fix it.

I'm wondering if it might be something here, under the class. Here's xLinkingBook's:

Code: Select all

class xLinkingBookGUIPopup(ptModifier,):
    __module__ = __name__

    def __init__(self):
        ptModifier.__init__(self)
        self.id = 5221
        version = 27
        minor = 4
        self.version = version
        PtDebugPrint(('__init__xLinkingBookGUIPopup v%d.%d' % (version,
         minor)))

And then your BookGUI template's:

Code: Select all

class OutsideBookGUI(ptModifier,):
    __module__ = __name__

    def __init__(self):
        ptModifier.__init__(self)
        self.version = '3.0'
        print ('__init__%s v.%s' % (self.__class__.__name__,
         self.version))

The plugin does get upset if the Python Version does not match the same version number. It reports that you have a out dated python file, and when you save your file, it will do so without the python file mod in place. Next time you load up, you have to select it all over again.

[andylegate]

Uhm wait.....

I think I may have figured it out:

With Blender and the GoW Plugin, to make a linking book, all you have to do is make your objects, set up a region for a clickable, and then we define that in the ALCScript as:

Code: Select all

Direbo:
     quickscript:
           simpleclick:
                  pythonfile: Andy_NexusBookGUI
                  region: MystVRegion

So were defining the responder as your BookGUI python file. And in your BookGUI file you're using a responder to have the link initiated as long as all the conditions are met in the python file (having the correct linking panel, spawnpoint, etc, etc).

So what happens, in the game, we click on the book, your python file initiates the Popup first, and then if we click again, your python file also then acts as the responder to initiate the link out.

With Cyan's plugin, it's done differently:

Once we build stuff, we make the panel a clickable by simply assigning that plasma component to it, then we have to select 2 resonders. The first responder is the python file:



Here we are saying, when you click on the book, run this python file, which makes the Book GUI Popup happen. The python file is then waiting to see what you do. If you click on the book panel that you defined in the plugin, then the 2nd responder kicks in:



The 2nd responder is what actually initiates the link out. It's detector as you can see from my red circle, is the GUI Popup file. The Command Parameters for linking out are defined here, not in the python file. If you remove this responder, what happens is the book will pop up all right, but when you click on the panel, you don't link. You MUST have a 2nd responder that actually performs the link.

I'm wondering if THIS is what is causing the plugin to crash Max with your BookGUI template. What do you think?

[ddb174]

I've posted something about this here: http://www.guildofmaintainers.org/Forum/viewtopic.php?f=101&t=1702&p=14197#p14197 if people want to take a look.

[D'Lanor]

I'm wondering if THIS is what is causing the plugin to crash Max with your BookGUI template. What do you think?

I don't think so. You are talking about the equivalents of the pythonfilemod parameters within the Python file. The plugin parses those parameters and builds the menus dynamically from those. I already understood that:

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.

So don't expect a different Python file to work the same way. That doesn't matter though. You don't really need to see your panel in a Max menu. There will just be less to click but it should work anyway.

The plugin does get upset if the Python Version does not match the same version number. It reports that you have a out dated python file, and when you save your file, it will do so without the python file mod in place. Next time you load up, you have to select it all over again.

Now here you have found something I think. Long ago I noticed that Uru doesn't need the version and id numbers. So I simply stripped them out. I also started using version numbers as strings because the tools we use to decompile Python files turn float values into crazy long decimals like 1.100000000001 which gets worse every time you decompile/recompile.

So apparently Uru does not need the version number but Max does. Do you have any idea what exactly those version and id numbers are supposed to match in Max?

[andylegate]

That's the crazy thing! They're all different (which tells me that the version number is internal).

The BookGUI file is version 27, Minor 4
The DialogToggle is version 1, no minor
The StarTrekDoor is version 2, no minor

They are all over the place. You have to open it up and look.