Python Files

[D'Lanor]

You are telling me? I have studied those Python files so much that I dream about them. But why does the max plugin need version numbers or id's? Usually those are for the programmers. Why bother the modelers with it? And why did Cyan go through all that trouble to make a dynamic Python parsing system and then make it not-so-dynamic-at-all by hardcoding the modules it can use?

So how on earth are we going to add our own Python files? I have a Blender age sitting here loaded with puzzles. It uses 14 custom Python files for its wiring and it needs a lot of pythonfilemods. I really hope someone can figure out how to do something like that in Max.

[GPNMilano]

You are telling me? I have studied those Python files so much that I dream about them. But why does the max plugin need version numbers or id's? Usually those are for the programmers. Why bother the modelers with it? And why did Cyan go through all that trouble to make a dynamic Python parsing system and then make it not-so-dynamic-at-all by hardcoding the modules it can use?

So how on earth are we going to add our own Python files? I have a Blender age sitting here loaded with puzzles. It uses 14 custom Python files for its wiring and it needs a lot of pythonfilemods. I really hope someone can figure out how to do something like that in Max.

The modules are not hardcoded. We can use our own pythonfiles. The version and Id numbers are to ensure within max that no two python files clash. (Not sure why this is) I know that using the Neighborhood02.py AND a KirelMOUL.py through up an error upon start up that the two id numbers clashed and so it was ignoring the two python files. However for each of my ages, as long as I gave them a unique ID number, the plugin recognized my SDLHook files. (IE EderLicinius.py)

[andylegate]

Got it!

I finally figured out what was causing Max to crash.

It's this single line in your PageDefs file:

Code: Select all

plyrName = PtGetLocalPlayer().getPlayerName()

Have no idea why. But once I removed that line, Max loads up fine now, and it has no issues with your templates.

[diafero]

A late follow-up on the linking responder subject: Sure I'm heavily Alcugs-biased, however the fundamental problem is the same on UU: linking rule and age title must me consistent for an age, and spawn point title must be consistent for a spawn point. The actual consistent content might be different depending on the server software and the admin's wishes, but it has to be always the same.
Btw, that "extended" central linking file to link to MOUL, Myst V, Fan, ... ages exists, it's the xLinkMgr contained in the Offline KI. It just has no interface to be plugged into an age, but using this file, one could have a linking python file mod taking only the age filename and the spawn point name, and doing the rest correctly, no matter where you link to (or it would show an error in case the link is invalid). However, this would make the age depend on the Offline KI, which is not available for UU.
Oh, and you can change the instance settings on Alcugs servers, as D'Lanor said. It's actually quite crude: There simply is a list of instanced ages in the config file. The rest is global. Unfortunately, it's not possible to use the actual linking rule supplied by the age, because Cyan broke that completely in POTS. It's wrong all over the place.

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.

Indeed it is, which is exactly the reason why I prefer Python linking: Such problems can be detected and fixed automatically then. This is much harder for a prp link.

[andylegate]

Hrmmmmmmm.......

Sounds like if you're going to be making linking books in your Fan Age then, one really BIG consideration is: where is the Age going to be hosted at?

Right now it's: a person's standalone Uru:cc/POTS, a Alcugs shard or a UU Shard.

Hehehehe.....if it were me I'd be like: "uh......er........*sigh*...to heck with any linking books......Here's a journal instead...READ!"

[diafero]

Sounds like if you're going to be making linking books in your Fan Age then, one really BIG consideration is: where is the Age going to be hosted at

If you really hard-code the linking details in the age, then - yes. If you do it in Python, you open the way for some patching

Hehehehe.....if it were me I'd be like: "uh......er........*sigh*...to heck with any linking books......Here's a journal instead...READ!"

That, or some miracle is happening and we can agree on something like a "linking standard".... go for the journals, I'd say

[andylegate]

*scratches chin in thought*

Well......you know most people don't have things always commited to memory. And we do have new people learning Age Creation all the time. We could create exactly what you're talking about, and tell them in the tutorials that you MUST do it this way.

Of course that won't stop the old people from doing what they want (like me), and they'll still just do it any old way (like me), and then look around in confusion when things break down with a innocent look on their face (like me)..........

Still, I think (and being an engineer can really agree on) that having a standard would be great!

[diafero]

I know I sound like a broken record, but the closest thing to a safe linking standard we have right now is the xLinkMgr in my Offline KI. It contains a function called LinkToAge taking the age filename and the spawn point name, and taking care of the rest. However, no matter how this is done, it will add an external dependency - and in case of the xLinkMgr, someone would have to change the AvailableLinks.inf file to work with UU (the code itself should work fine there, though untested). The one thing I can guarantee is that linking with this module works fine both offline and online, as the Offline KI uses it for all of its links, and I also tested it intensively on an Alcugs Shard (including patching all fan ages do use this module instead of the linking code in D'Lanors template, or custom linking code).

Linking would look like this:

Code: Select all

import xLinkMgr
xLinkMgr.LinkToAge("Pahts", "LinkInPointDefault")

The linking rule and age display name are determined from the AvailableLinks.inf file (where the age has to be listed - except for offline, where additional installed ages are automatically added with the default [kBasicLink] rule). The rule can be either a basic link (in which case each spawn point can be used), an owned age link (in which case the spawn point must be listed in the config file, and the title set there is used) or a sub age link (in which case it also checks whether you are in the right age to link there, and it checks the spawn point like for owned ages).
If linking is not possible for whatever reason (age does not exist, is not installed, spawn point does not exist, you are in the wrong age to link to a sub age), it shows the error in a message box presented to the user.

[Paradox]

Still, I think (and being an engineer can really agree on) that having a standard would be great!

My impression from these last few posts is that we have a standard. And another standard. And a few non standards.

[ddb174]

I'll be making some Python files that will show up in the 3dsmax GUI, which will make it so that for a lot of things, you don't need custom Python code for your Age. E.g. there will be a way to type the contents of the journal directly in 3dsmax so that you don't need to do Python code for a journal. And a simple linking thing which will, in the case of Offline-KI just call xLinkingMgr. Some puzzle primitives over time too, I imagine. And then Ages that use this will be Python-wise "cross-platform", in that they will work in Offline-Pots, Alcugs, and Moul. But right now I'm working on subworlds, which is more important!