Seeking Clarification - Various Uru Engines and Blender/Max

[Christopher]

So when I read "You only have to upload the age when you change it", I think, "But I sometimes change it 50 times a day!".

I already said it somewhere. You don't have to upload the age, but the .age FILE(!) (the text file where you set the sequenzprefix). You only have to upload this .age File ONE time (except you change this file e.g. the sequenzprefix, pagecount, etc. and I doubt that you change this stuff 50 time a day ) You don't have to upload the .prp files. If you changed them you can simply replace them in the shard installation as you do with Uru:CC.

I hope (again) this clariryfy the things a bit...

Christopher

[diafero]

Of course, if you use custom scripts for journals and such, those will need to be made to work with the engine proper (take a look at Fehnir's House for an example). I've made changes to the moul-scripts that remove a lot of the hard-coded nonsense and make it easier for us to flexibly add new Ages using the standard PythonFileMods instead of the custom ones used by CC's KI-mods. For journals, it becomes as easy as making the .loc files in whatever languages for which you have translations, and letting the PFM do the rest.

If we had some sane standard interface for this, we could even implement it for both Uru:CC and MOUL. Of course, we don't have such an interface

[DreamBliss]

WOW! Lots of information here, scanned through it and saved it for more reading later. Thanks everyone!

Just one thing I wanted to point out here... If we have enough good programmers in the community we could make an actual editor for MOUL. Meaning we would not have to use Max or Blender, we could use any modeling programming to create our models, and Gimp or Photoshop for textures. The editor would import common formats most modeling programs and image editors export to. The editor could then allow users to see, real-time, their age as it would appear in-game. No need for servers or clients. Of course to make the editor work these may still have to be running in some way in the background. But that can be automated with the installer based on each user's unique system configuration and OS.

I have had this idea in the back of my mind for some time. Cyan/Ubisoft essentially took Max/Blender and re-purposed them to the equivalent of a level editor. Having an actual level editor allows the community to contribute meshes, textures and whatever else, to share ages easily, and to make/debug them easily.

Unfortunately I am not a programmer. I can picture the editor in my mind's eye quite clearly. I could design it, describe what it should do, how it should work, what formats it should import/export to and so on. But I have no idea how to actually code the thing. Still if the programmers in the community are interested, and they just need someone to help design it, I freely offer my services, such as they are. Probably could even make icons and buttons.

Alternatively I have a few gigs of GCS on my machine, from CryENGINE to UDK and Unity. Any of these could be used for MOUL if we could figure out how to do so. But I think making an editor is simpler, easier to tailor to the current Plasma engine, and if coded right it can be updated as Plasma/CWE is updated.

[Christopher]

The programmers currently doing other stuff for uru (e.g. porting it to Linux). So if such an editor will ever be made, then it will take at least years until the work is started...

I can remember there was such a project some time in the past, but it never really worked for me and it also was in an pre alpha stage. AFAIK noone works on it anymore.

Christopher

[Deledrius]

Of course, if you use custom scripts for journals and such, those will need to be made to work with the engine proper (take a look at Fehnir's House for an example). I've made changes to the moul-scripts that remove a lot of the hard-coded nonsense and make it easier for us to flexibly add new Ages using the standard PythonFileMods instead of the custom ones used by CC's KI-mods. For journals, it becomes as easy as making the .loc files in whatever languages for which you have translations, and letting the PFM do the rest.

If we had some sane standard interface for this, we could even implement it for both Uru:CC and MOUL. Of course, we don't have such an interface

I'm not entirely sure what you mean. The PFM is a standard interface. It's been a very long time since I looked at them in Uru:CC though, so I'm not sure how hard it would be to fix Uru:CC to do this properly. Either way, the info is the same so worst case it's just saved differently.

Just one thing I wanted to point out here... If we have enough good programmers in the community we could make an actual editor for MOUL. Meaning we would not have to use Max or Blender, we could use any modeling programming to create our models, and Gimp or Photoshop for textures. The editor would import common formats most modeling programs and image editors export to. The editor could then allow users to see, real-time, their age as it would appear in-game. No need for servers or clients. Of course to make the editor work these may still have to be running in some way in the background. But that can be automated with the installer based on each user's unique system configuration and OS.

I have had this idea in the back of my mind for some time. Cyan/Ubisoft essentially took Max/Blender and re-purposed them to the equivalent of a level editor. Having an actual level editor allows the community to contribute meshes, textures and whatever else, to share ages easily, and to make/debug them easily.

Sounds like what was in mind for AgeCreator. Sadly, it is unfinished, and AC2 will probably never be.

[diafero]

I'm not entirely sure what you mean. The PFM is a standard interface. It's been a very long time since I looked at them in Uru:CC though, so I'm not sure how hard it would be to fix Uru:CC to do this properly. Either way, the info is the same so worst case it's just saved differently.

I meant Python File Modules with arguments like "Activator, Journal name, Cover texture" displaying the content of a text file as a journal when clicking something, or "Activator, Age Name, Age Spawn Point" displaying a linking book for an age - without the need to edit Python files or ship them with each and every age. If these xFanAgeJournal and xFanAgeLink or however they would be called were available for both MOUL and in the Offline KI (with independent implementations, obviously) it'd be easy to write an age using journals and links and everything which works both in Uru:CC and MOUL.

[Sirius]

About python files redistributed with each and every Age:
I guess Diafero is talking about the script D'Lanor wrote to create journals and linking books. The script gives you a lot of flexibility, as D'Lanor used in his Prad Age. But since most Ages don't have any use of advanced features, it could be simplified as a global script.

Personally I think this would be the best way, because people with little-to-no knowledge of Python are always confused by this script. Just setting a PythonFileMod with correct parameters, and writing the journal in a .txt (or .loc) file would be a lot simpler. And whenever the script's behavior is updated, every Age would be updated with it.
(This is basically what Cyan did, except for complex books such as Ahnonay's)
Also, a lot of Ages use journal covers to create notes, which means opening the book displays a message such as "this is not a book, close it now". It makes no sense using a complex script just for a GUI.

Writing the script itself wouldn't be a hard task. The hard part is post-editing 99% of the fan ages to use this script...

[Deledrius]

From a quick glance at the python for UU, it appears that they didn't have a generic journal script, so I see why this was done for fan Ages. Making a roughly-equivalent (even better, without the old MOULa cruft) PFM as a shim should be easily doable. Any missing-but-needed features to the moul-scripts repo to reasonably support fan Ages are welcome as pull requests too, of course.

On Gehn, when using the built-in xJournalBookGUIPopup PFM the author only needs to provide the Activator, Width and Height scaling, a LocPath to the .loc resource to use for the contents, and an optional book type for appearance. This could probably be easily done with a quickscript, as the PyPRP simple clickable QS is mostly providing the same output.

For Fehnir's House on Gehn, this is an example of what I use:

xJournalBookGUIPopup Alcscript Show Spoiler

Code: Select all

FehnirJournalRgn:
    type: region

FehnirBook:
    physical:
        pinned: true
    logic:
        modifiers:
            - tag: Click
              cursor: poised
              flags:
                - localelement
              activators:
                - type: objectinvolume
                  remote: FehnirJournalRgn
                  triggers:
                    - any
              conditions:
                  - type: activator
                  activators:
                      - type: picking
                - type: objectinbox
                  satisfied: true
              actions:
                - type: pythonfile
                  ref: $Click
        actions:
            - type: pythonfile
              tag: Click
              pythonfile:
                file: xJournalBookGUIPopup
                parameters:
                    - type: activator
                      ref: logicmod:FehnirBook_Click
                    - type: skip
                    - type: skip
                    - type: skip
                    - type: skip
                    - type: skip
                    - type: skip
                    - type: skip
                    - type: skip
                    - type: skip
                    - type: float
                      value: 0.8
                    - type: float
                      value: 1
                    - type: string
                      value: FehnirHouse.Journals.FehnirJournal


The comment book differs only by the final extra string for bkNotebook in the parameter list. The actual journal contents go into a loc file which supports any and all translations supported by the client. No more need for shoving content into the Python scripts where it doesn't belong (I did a lot of cleanup for that already in the official scripts).

Writing the script itself wouldn't be a hard task. The hard part is post-editing 99% of the fan ages to use this script...

Indeed. This is the same problem with fixing some of the journals in the base game as well. We simply aren't allowed to fix the PFM wiring in the PRPs.

[diafero]

I doubt anybody will post-wire the old ages. We just have to live with all the old leftovers...

On Gehn, when using the built-in xJournalBookGUIPopup PFM the author only needs to provide the Activator, Width and Height scaling, a LocPath to the .loc resource to use for the contents, and an optional book type for appearance.

In CC, of course, there's no loc system, so stuff can be read from files instead (Dustin already introduced a convention for this with his UamPlugin, and some ages use it). How's the cover set?

However, I don't think I am going to write such a script. Offline KI is in maintenance-only mode. I'd however be happy to include such a script and provide updated versions of the Offline KI. The sources are all at https://gitorious.org/offline-ki

[Sirius]

Alright, I started writing two scripts that could be used for books in future Ages, and won't need to be modified for each Age. Hopefully it will make things a lot simpler for Age users... I think it could work for both Max and Blender.
Obviously it won't have as many features as D'Lanor's script, but should provide most of the important ones.

I managed writing a script to create simple journals. It can be used by simply giving an activator (clickable), and a journal name. The content is read from dat/<agename>_journals/<journalname>.txt. Optionally, the user can provide scaling for the book, use the two different book type (notebook or book). He/she can modify the font and book cover directly in the journal .txt file, as well as put images in it (since these features are from Plasma and do not require any script).

Additionally, it supports localization - the script will automatically choose the right file depending of the language Uru is using.


I'm currently writing the script for linking books. User will just have to provide an activator and linking destination (plus some additional parameters if needed).
It's going to be a bit harder because of the linking rules. IIRC, the Offline-KI provides code to make linking simpler. Will have to check that.
I might also add support for Bahro Stones...


Anyway, if these scripts work fine, maybe we can release them with the Offline-KI.