Korman Python Eureka moment

Help bring our custom Ages to life! Share tips and tricks, as well as code samples with other developers.

Korman Python Eureka moment

Postby J'Kla » Fri Jun 15, 2018 1:41 am

This morning I awoke to a true lightbulb :idea: moment. I have always understood that in Uru is a doorway puzzle in a 3D environment, and as age builders both in Blender and 3DMax we build environments that have doorways.

Said environment gives us clues and puzzles that result in keys to open the doors of said environment.

Beyond each door there is an extension to the environment (perhaps a new age) where there is either a reward (clothing or some new feature for our Relto) a new set of puzzles that will lead to another as yet unseen or possibly a very visible door or doors.

This is true of even of the most basic 1st person shooter where in that case the door you need to pass is mobile and shooting back at you, and the tools/keys you have to open those doors are weapons with various levels of destruction.

When the only tool you have is a hammer everything looks like a nail.

One of the nice things about Uru is there are no guns and the tools are observation and intelligence and sometimes patience.

One of the simplest locks in this type of 3D world is the combination lock where there is some value that’s either written somewhere or is a value that can be gleaned from the environment. By inputting by some method that gleaned value you unlock or open the door

For my age Enobmort I had figured out the second part (that is my hidden value and how to embed it in the environment) and I have worked out the door placement I have even worked out how the player is going to enter this value and the actions needed to completely open the door.

Let us be clear here I am saying this is the door, this is how the player is going to open the door, but I have long been struggling to find a way build the lock the key, and for that matter how to make the door move within the game.

One of my primary problems was finding a way to add a variable into the environment to store the lock combination.

Here we come to my Eureka moment. One of the most basic elements in Blender that we export to the game is the Empty that we use as a place holder for a link in point.

That Empty consists of a Name and a value for its x, y, and z co-ordinates within our 3D environment.

As a link in point, it does not even have a physical appearance in your age it has no colour and no texture.

This makes it a prime candidate to store three variables EmptyX, EmptyY and EmptyZ.

There has to be a way of saying within the game set EmptyX to some value and then within Python and therefore also within the game increment or decrement EmptyY and then test if EmptyX is equal to EmptyY change EmptyZ to some value that represents the state of our door lock or even the door.

Once this is developed as a basic tool we could make lots of puzzles because we don’t even ned this to be a combination lock all this represents is a three value state and a basic test where EmptyX is some value that we want to test combined with some means of changing EmptyY to some new value be that a click or whatever and some test for equality between EmptyX and EmptyZ.

Now my second doorway in Enobmort requires following a route passing through a set number of locations in a particular order and for that I need to think about how I could possibly use this empty as a way of solving that one but that is going to have to wait on another Lightbulb. :idea:

[edit]
As a postscript and afterthought I was wondering if we could develop a way to manipulate this with nodes (that I know don't exist yet but could be Python nodes)

So for example in the Blend file we add an empty and give it a name.

Then a clickable node chain that leads to a python node where we select the object from a drop down and we can choose to increment or decrement the x, y or z value.

Then a test node that checks for equality where we can choose which attributes we will be testing.

We could link to a Message node that makes some change to the age.

I hope everyone realizes I am just kicking ideas around here to test the waters for what is possible.
[/edit]
User avatar
J'Kla
 
Posts: 900
Joined: Wed Feb 20, 2008 3:16 pm
Location: Geordieland UK

Re: Korman Python Eureka moment

Postby Sirius » Sat Jun 16, 2018 4:46 am

That would be a possibility. But in order to make it work online you'd have to make it synchronized between players (and also saved in the savegame). That, and develop a few Python scripts to work with those values. Not worth the trouble IMHO, since SDLs and Cyan's scripts should be able to do what you require.

I have to do a bit of research, but I'm pretty sure that we have all we need to create basic logic in Korman. We only miss the ability to setup SDLs directly in Korman, but they are pretty easy to write by hand, so not a big issue.
I have a lot on my plate currently with Plasma-on-Unity, work, school etc, but I'll try to post detailed instructions once I've figured out how to work with those.
User avatar
Sirius
 
Posts: 1088
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Korman Python Eureka moment

Postby J'Kla » Sun Jun 17, 2018 4:55 am

Sirius wrote:That would be a possibility. But in order to make it work online you'd have to make it synchronized between players (and also saved in the savegame). That, and develop a few Python scripts to work with those values. Not worth the trouble IMHO, since SDLs and Cyan's scripts should be able to do what you require.

I have to do a bit of research, but I'm pretty sure that we have all we need to create basic logic in Korman. We only miss the ability to setup SDLs directly in Korman, but they are pretty easy to write by hand, so not a big issue.
I have a lot on my plate currently with Plasma-on-Unity, work, school etc, but I'll try to post detailed instructions once I've figured out how to work with those.


SDL files may be simple text files but simple to write I would have to say a big NO as the result of some simple experimentation to try and just understand the basics of the SDL environment I have ended up having to rebuild two of my shards twice.

I am beginning to get my head around it now but I am still not totally confident I know what I am playing with.

The saving grace has been my ability to do a shard rebuild almost seamlessly.

In one of the other threads you mentioned your scripts xSimpleLinkingBook and xSimpleBahroStone where can I find those?

I am not saying I will understand them but it is all material I can use as a reference the theory being that if I examine enough scripting some it may begin to make sense.

This is actually a method that I can say has worked in the past. :)
User avatar
J'Kla
 
Posts: 900
Joined: Wed Feb 20, 2008 3:16 pm
Location: Geordieland UK

Re: Korman Python Eureka moment

Postby Sirius » Sun Jun 17, 2018 5:16 am

SDLs are complicated because we don't have a lot of information on how to use them, so you have to learn the hard way. But after we have more documentation on those (and possibly better integration with Korman), they will be easier to use.

The files I mentioned are included in the Offline-KI, and can be found here. Keep in mind that they are intended to work on Complete Chronicles with the rest of the Offline-KI framework, so they probably won't run on a Dirtsand server (the linking part definitely won't, journals should). Oh, and here is the tutorial for those - it's outdated as it was made for PyPRP, so you'll have to find the node equivalent in Korman. Since it consists of clickables linked to a Python script this shouldn't be too hard.
User avatar
Sirius
 
Posts: 1088
Joined: Mon Jul 26, 2010 4:46 am
Location: France

Re: Korman Python Eureka moment

Postby J'Kla » Sun Jun 17, 2018 8:54 am

I just want to put this out there and I may have this dead wrong.

At present we have three ways of making fan produces ages.

Lets forget the old Blender via PyPRP way producing Alcugs output that uses AlcScript for functionality.

We have 3DMax that can make Alcugs or MOULa output

We also have Blender Korman 0.06 that can also produce Alcugs or MOULa output.

Alcugs output produced by either method is suitable for Drizzle Combined Chronicles Shards like Deep Island.

When MOULa output is produced with 3DMax or Blender Korman 0.06 it is valid for MOSS and dirtsand test shards like Minkata, The Open Cave, Ghen, Destiny and my LAN dirtsand.

Now the following depends upon me being right on the previous line.

Python script produced for 3DMax is suitable for Blender Korman 0.06

This is based on the assumption that MOULa code produced by either method is the same for MOSS and dirtsand.

What we need is a method of making Blender produced ages access the same Python scripting as those ages produced using 3DMax.

Do we need to change those 3DMax Python scripts or is it that we are just looking to embed blender links to the scripts?
User avatar
J'Kla
 
Posts: 900
Joined: Wed Feb 20, 2008 3:16 pm
Location: Geordieland UK

Re: Korman Python Eureka moment

Postby Sirius » Sun Jun 17, 2018 2:32 pm

Python scripts don't depend on which software you use for modelling - they should be compatible with both Korman and Max (and PyPRP, but who cares). The output file will be correctly setup to use that Python script in all programs.

However, the Python script itself need to be added to the game (to one of the PAK files - read below), AND be compatible with other scripts and the engine's own Plasma API (application programming interface - essentially the layer that allow Python scripts from interacting with the engine).

- Alcugs/DeepIsland and Dirtsand have a different library of scripts, so for instance the xSimpleXXX files are already included in the Offline-KI and Deep Island/Alcugs, but are NOT present in Dirtsand Shards. You can however include them by simply creating a new PAK file (with PlasmaShop) and put the scripts in it. Ideally we should strive to make the default library as complete as possible, and make the scripts in it match between Alcugs and Dirtsand, so you can export to both engines without worrying about whether the script is there (and to avoid people redistributing their own PAK).

- The API can change from game to game. For instance, the networking API was removed or hidden in End of Ages, but Slates and such were added to it. This is an example, but some smaller parts of the API can vary from MOUL/CC/EoA, so sometime there will be incompatibilities. For instance xSimpleJournal uses text files in the Uru folder, but that was PotS's way of doing things. In Dirtsand, journals now use localization files (.loc). This theoretically shouldn't prevent xSimpleJournal from working on Dirtsand but isn't the "correct" way to do things so will need to be fixed eventually. For xSimpleBook/xSimpleBahroStone, a part of the Plasma API and a script from the Offline-KI which is missing or incompatible. These unfortunately can't be ported easily, so you almost definitely won't be able to use those when targetting Dirtsand. They work perfectly well on PotS/CC though.

Hope that clears some things up 8-) Hopefully there will be a standard way of doing things for both types of games at some point.
User avatar
Sirius
 
Posts: 1088
Joined: Mon Jul 26, 2010 4:46 am
Location: France


Return to Scripting

Who is online

Users browsing this forum: No registered users and 1 guest