I've done the initial release of a framework that allows for a person to more easily make Ages in 3dsmax with Cyan's Plugin. It makes it so that you don't have to use Python or SDL for common tasks, and it is such that it is supportable in Moulagain, so that you don't need to rescript things! You can find more details at http://dusty.homeunix.net/wiki/UamVars or visit one of the following forums for the announcement: uruobsession.com, mystcommunity.com, forum.almlys.org, guildofmaintainers.org, guildofwriters.com, huru.info, or afteruru.forumakers.com.

There are already lots of x*.py and x*.sdl files that can be integrated into ages quickly and easily - have you looked at maybe documenting those and making it easier to use them, instead of re-inventing the wheel?

_________________
MOULagain KI #: 66990

When I was your age, we rocket-jumped up hill both ways in boiling lava.

I'm actually extremely well acquainted with those methods (ddb174=Dustin, you see), but they have various problems, some of them quite severe. However, the two systems are entirely compatible, so you can use both in an Age. Furthermore, if you take a look at what this first release includes, you'll see that it enables you to do two common things that aren't doable with the current PythonFileMods and SDL: show Linking Books and Journals. (Cyan's files require the Journals and LinkingBooks to be hard-coded.)

"hard-coded" is relative - you can send a notify message from inside python and trigger any other set of receivers and messages you want.

What sort of problems do you see with the current python and SDL? Implementing them in PlasmaClient they've seemed fairly elegant.

_________________
MOULagain KI #: 66990

When I was your age, we rocket-jumped up hill both ways in boiling lava.

My thoughts exactly. The existing SDL system already does a very good job if you know how to use it.

On the other hand some features of this new system, for example the implementation of new Relto pages, would be difficult with the current files which were made with a single content developer in mind.

Still I would rather see the current system made more flexible than a second system alongside of it.

_________________
D'Lanor (ɹǝʇunч puǝƃǝן uɐqɹn)

♪ KI# 33949 ♪

Well, for starters, Age authors shouldn't need to write their own Python and SDL, especially not for common tasks. Which as I say, they currently have to do even for things as simple as Linking Books and Journals. Another thing is a lack of primitives: you should be able to take a bunch of simple things and tie them into something more intricate. Not having primitives means that a lot of stuff winds up being redone for different Ages in Cyan's Ages, which results in bugs fixed in one place but not another. Another one is debugging: it's nice to be able to take a look at the log and see what is happening, whereas ResponderModifiers can be a black box from a debugging perspective. Another is the unclear (to Age authors) network syncing behavior; what state is it in and why is it not getting to the state it should, they wonder. Another big one is cross-platformness: some features don't work on all games (i.e. Pots and UU and Moulagain) and now the Age is accidentally specific to one game. (Some of the linking features are especially bad for this.) I've listed more reasons in the past, too.

Indeed, I was the one who originally documented how to use SDL and Python in fan Ages! (See my old tutorials for Blender.) (And I've implemented SDL and vault engines for Talcum, so I know the technical particulars.) I've paid close attention to the problems they have and why, and spent a lot of time thinking of the cleanest way I can conceive within the confines of Plasma. They may have some elegance to them (as I noticed in 2005), but I think that it is mostly illusory to us developers, especially when I talk to Age authors. (Of which I am also one :P)

Edit: It's less of a second system, as it is a library which makes use of certain parts of the old way, to provide a better way of doing things. Again, an Age can use both ways, as the author sees fit. Both coexist perfectly.

So in summary, I've used both methods to make Ages, and I find this method I've been working on to be much, much easier. And I think nearly everyone who uses both with an honest mind, will agree.

Being a developer myself (generally speaking - not for Plasma and Uru), like many technical discussions about platforms and languages, I can see this could become an interesting debate among experienced Plasma/Uru fan developers.

But specific to this development, all things being equal, I would put more weight on how well beginners or new studios could get started, learn and grow into each of these choices. In other words, posts from a new generation of developers which indicate whether it can make things more successful for a wider development community.

_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Perfect Speed Is Being There.

If it's easier, I'll use it.

_________________
I am a member of Team OSCAR. I make content for MOULa. Help OSCAR here: http://forums.openuru.org/viewforum.php?f=103

I have only a vague idea what this tool means on a technical level, but if it lets me poke things graphically to make "stuff happen" in my ages, it's all good. I, for one, am spectaularly bad at scripting, to the point where learning basic python gives me a headache. However, I'm good at 3d modeling(or at least decent enough to make game models). I'm very much an artist, not a programmer, and it's good to see this headed in a direction where I don't have to know all the nitty gritty coding details to make a simple link between two ages.

From the wiki it doesn't sound like it does very much yet compared to what some scripters apparently have been able to do in their fan ages, but I for one think such a tool is a very good idea. (I haven't tested it myself, I don't have the right copy of 3ds max to run the age plugin with. ) I disagree that it's not useful, becuase users, such as myself, who were previously scared away by the coding side of things can now begin to work. Even if they can't do the more advanced stuff or don't understand the code details behind what is happening, it's good to be able to give more power, and thus more inspriation, to the new users of the toolset.

After all, Uru is all about the artwork and story in the new ages when all is said and done, not about learning python code. No offense meant at all to those who know the codes, in fact, I hold you all in the highest regard, since without your vast knowledge of how uru and python works these type of tools couldn't exist. But it's refreshingly good news to know more users like me will be able to make ages too. The more storytellers we get working, the more stories we all will have to share and experience, and in the end, I think that is much more important for Uru then teaching everyone how to properly code.

darkgriffin wrote:

I have only a vague idea what this tool means on a technical level, but if it lets me poke things graphically to make "stuff happen" in my ages, it's all good.

Heheh, that's precisely what it does!

Yes, this first release only has a few things that can be done this way, but they are also the most common things people like to do. (And as I say, using some things from UamVars in no way limits an Age author from using the other methods.) The idea is for me to take requests, and add what is needed, when their Age is almost ready for release.

I tend to see the python layer as volatile and building a framework at such a high level seems a bit futile?

One of the problems that Age developers encounter is the lack of easy GUI tools to handle game logic, and a lack of full implementations of everything needed for game logic.

Originally, PyPRP had no responder modifier support or animations. This led many developers to do things like write Python scripts to animate doors opening. Pretty much everyone agreed that this was a terrible idea, but there weren't other options at the time.
As the tools became more advanced, newcomers took advantage of things like animation support in Blender, and some of the older Ages were updated. Some people prefer sticking with their existing solution rather than learning the new features and new interface.
The end result is that we have a handful of Ages that use Python hacks for things that "should" be done differently, but due to how things were implemented it wasn't possible.

Python in Uru should never be an Age developer's first thought when looking to implement logic. There are a handful of messages to deal with things like playing sounds, playing animations, fading effects in and out, etc. This is where we really need to put together good documentation and a user-friendly GUI (PlasmaMax has a pretty good one, but I don't think it lists all of the possible messages).

If your puzzle/problem needs more advanced logic, the second step is to look for global Python files that accomplish what you need. Making things visible/invisible based on states in the database, saving states to the database, and playing animations/sounds/fancy effects when a state changes are all possible using the global scripts.

Then, if you need something even more advanced, is when writing your own Python should come into play.
Python should always aim to sit as a layer between a LogicModifier and a Responder.

Some of the global scripts are designed in such a way that using them in fan Ages is almost impossible. Linking Books are the best example of this. Every Linking Book needs to be added to a Python script before the book can be displayed. Clearly this will cause problems if every single Age developer is trying to add stuff to a shared global file!
This is where solutions like Dustin's are most useful.

Regarding database states, SDL is a complicated system, and it's confusing for Age developers. I definitely agree with those sentiments, but it's also a brilliant design that is essential to just about every aspect of Uru. Personally I'd rather see effort put into making tutorials and user-friendly tools rather than providing SDL alternatives.

Been trying this out. Cyan's plugin for Max already made many things for Age creations a LOT easier than before due to how the plugin's interface is.

However by comparison it made linking books and journals a pain.

This on the other had just made it a LOT easier. Big thumbs up from me.

_________________


My Tutorials

Paradox wrote:

Some of the global scripts are designed in such a way that using them in fan Ages is almost impossible. Linking Books are the best example of this. Every Linking Book needs to be added to a Python script before the book can be displayed. Clearly this will cause problems if every single Age developer is trying to add stuff to a shared global file!
This is where solutions like Dustin's are most useful.

Clearly the Python scripts were never designed for distributed development of ages. The limitations can easily be overcome with a plugin or component based architecture where ages can register features like books, relto pages, cloths etc.

A simple plugin interface can be implemented in a couple of lines of Python code. Third party extensions like zope.component are offering even more powerful ways to extend or customize parts of a large software stack.

_________________

[KI again #01792364]| Uru images | KI guide

Well, if this makes age creation more user-friendly, I'm all for it.

But what would really be great is a version of the 3ds max plugin that can work with the current version of 3ds max, or (better yet) a GUI system for Blender age creation that applies the user-friendly elements of Cyan's plugin to a program that most age creators can actually get their hands on.

As is, only a minority of GoW members have copies of 3ds max 7 or 8, so this tool - even as good as it is - can only be used by a few.

That's not to say we don't appreciate your work, but many of us in the age creation community can't do anything with it because we don't have old copies of 3ds max.