Water Texture

[Jojon]

No, not really. That's python. Plasma does not run on python, it is controlled by python. The layers and such being talked about are part of the model files. A completely proprietary file format that is not documented. (except for the stuff that's been hacked out of it)

Exactly! Depending on the complexity of the Plasma<->Python API, of which I know nothing, I'd expect you have one command that copies the relevant data from the model in memory to an instance of your structure. Then you can alter the structure and issue a second command that updates the model with the new data (or maybe there is one that lets you change a single parameter within?). Isn't this pretty much how you handle translations and such today? (Guess I've got to do that reading up )
I imagine a hierarchy of structures and sub-structures, accessible somewhat like: ObjectStruct/MaterialStruct/TextureStruct/TxAnimType

[Nadnerb]

No. Not really again.

The python api doesn't allow any finer control past the object level. You can rotate, scale, translate, and disable/enable visibility on an object as a whole, but there is no ability to actually edit the model from a python script. As for objects that change in ways other than this in game, the python script simply triggers animations that are built into the objects from the start.

[Trylon]

Yup, you'll have to forget any relation between python and the PRP (age) files.

Basically it's like this:
- Plasma is written in C++ (or some similar language)
- Plasma has it's own (very extensible) file format, PRP which is just binary code.
- Plasma converts this to objects displayable in DirectX
- Plasma happens to have a basic scripting interface in some obscure language called Python.

And on another page:
- We have a free 3D program called Blender
- Blender happens to allow plugins to be written in some obscure language called Python
- So, when work started on converting Blender files to Plasma files, we used Python to write the plugin that would build up the neccessary binary files (PRP files)

So, basically it's just a really big coincidence that Python is both used by plasma and by the blender plugin.
Any control of objects in In-Game-Script-Python, is limited to what the Plasma programmers allowed in the scripting engine. That's limited to basic object transformations, and certain switches that trigger things...

[Jojon]

That's limited to basic object transformations, and certain switches that trigger things...

Aaww, limitations. So to set these thing within Blender, "we" may be stuck with some kludge, like a text-file, named the same as the material then? Same-name is how Blender relates vertex groups to bones, so I guess that would be consistent, in a way... But a single global file may be easier to handle... :7
Surely, however, there must be a duo of routines to call, in order to read and write .sav files, or is that not standardised?

[Paradox]

Blender doesn't use any of the Plasma Python stuff.

All of the materials are handled by Blender, and then exported to the PRP format. The only Python involved if the exporter for Blender, which doesn't use Plasma's API in any way.

[Jojon]

Blender doesn't use any of the Plasma Python stuff.

All of the materials are handled by Blender, and then exported to the PRP format. The only Python involved if the exporter for Blender, which doesn't use Plasma's API in any way.

Uhm, ah, I guess I should get it out of the way, that I have been well aware of most of the stuff that you all have just explained, all along, with the exception that I would have believed the Plasma scripting interface to be more extensive. I am flabbergasted that you have managed to reverse engineer the PRP format, to the point you can build your own files from the ground up and can only imagine the number of hours of flipping bits and seeing what happens, it has taken. I'd assume much of the format encapsules 3ds geometry data unchanged and that you have had some knowledge about that, to give you some sort of starting point.

Now, the problem, as stated, was that you had not decided where a modeller should enter texture animation-effect parameters, within the Blender interface (..where the exporter may then find them), since it does not really provide any obvious place for such, right? My initial reaction was: don't bother - set them at runtime, through plasma scripting. Ok, that doesn't work, too bad.
The thing I was wondering was whether materials are actually entities in their own right, in the PRP format, so that you can have several objects, all pointing to one shared material, or whether complete material data is written with every mesh. If it were the latter, I'd guess you'd simply come up with new property strings that one might attach to an object on the Blender Logic panel, so I am assuming the former.

So what would be the most logical place to put them? I suggested a text file (or several, but a single one should be simpler), listing all the materials, with banks of anim parameters for all their textures (and these banks, I hope, are selectable with Python, while Plasma is running, or is it all tied to greater animation stuff?).
I guess one could still attach them as properties to an object that happens to use the material in question and have the exporter scan every object for these properties as it works, but that could get messy, maybe.

This is all assuming that Plasma has simple moving offset texture animation and such, in the first place - maybe the meshes or UV maps are actually animated - what do I know? :7

Ok, I'm way past getting tedious - I'll try to shut up, promise. :7

[Paradox]

All of the objects in the .prp files have their own unique format, usually unrelated to any other existing formats.

The best way to handle animated textures (which are much different than geometry animations, and don't share any similar flags) would be to use Blender's internal texture animating settings, and then export those with the plLayer object in the PRP file.

[JulyForToday]

This is all assuming that Plasma has simple moving offset texture animation and such, in the first place - maybe the meshes or UV maps are actually animated - what do I know? :7

Can UV maps be animated in plasma? How would that sort of thing be handled? That would be another interesting feature to have...

[Paradox]

I don't think that animated UV maps are possible, the UV maps are saved in with the geometry.

[Nadnerb]

Hmm.. that's an interesting question.. I'm pretty sure that vertex colors can be 'animated' in an animation.. (think the glowing KI symbol) so why not the uv coordinates? Are the vertex colors for verts not stored the same way as the uv coords for verts?