Guild of Writers

Okay, I was going to say, I don't have any alcscript for the softvolumes, as I put it in like you said to, using the logic smiley face.

Let me go look at what's going on.

Oooooookay.

You had told me to add softvolumes this way:

that is correct.

Adding a softvolume is very simple. Easier than adding a sound region, and you've done lots of those.

use the pyprp softvolume to make a new cubic softvolume, name it, edit it, and the add a "softvolume: <name of volume>" property to the lights you want to work inside the volume.

I take it that with the new plugin, that this has changed. That in the logic properties I now have to go:

string: Name:softvolume softvolume:nameofthevolume

EDIT:
Okay, not understanding how to put softvolumes in correctly now with the new plugin, I just went and deleted all my cubic softvolumes and deleted the logic property for it on my lights for now. The redundancy of the above makes no sense to me at all, meaning more than likely I'm misunderstanding how to install softvolumes.

Upon deleting my softvolumes, the new plugin exported just fine with no errors.

SoftVolumes are now handled like all other types of references (although the string method should still work for complex volumes).

The ref parser requires that both the object name and the object type be specified.
In your Blender logic properties, you can add a property that looks like this:

Type: string
Name: softvolume
Value: 0088:<softvolumename>

Value could also be "softvolume:<softvolumename>", but 0088 is less typing and feels less redundant.

SoftVolumes are now handled like all other types of references (although the string method should still work for complex volumes).

Actually, this is new, for me at least. Using the logic properties before has always been:

Name:type
value:region

Name:page_num
value:3 (or whatever)

Name:rc
value: 0.5

So, for me at least, this is the very first time that I've ever seen the value needing something with a colon and then the name.

That's cool, but we need to let people know, as I imagine there will be a lot of people downloading the plugin, and suddenly can't export because they have softvolumes the old way:

Name:softvolume
value: <whatever>

it is a little redundant, because you are quite likely to be handing a reference to a softvolume when filling in the "softvolume" property on an object, but the softvolume property on actual prp objects is simply a generic object reference. You could say, for instance reference a scene object, rather than an actual softvolume ("scnobj:randomThing") although that would make very little sense. So what you're saying is, "I want to set the "softvolume" reference in this object to reference a softvolume with the name <whatever>.

Code: Select all

sv field    reference to softvolume with name whatever
softvolume: softvolume:<whatever>


You have seen this before, you even had a little issue with the spacing. Remember when you were working on the sound on the clickable door?
there was a line in receivers that said

Code: Select all

0011:zcdoorsnd1

that is a reference to an audio interface. It could be rewritten like this:

Code: Select all

audioiface:zcdoorsnd1

the same way that this sofvol reference can be rewritten

Code: Select all

0088:<softvolName>

The reason it's confusing is that references like this were really not used in the "exposed" areas of alcscript. ie, most of the "properties" you've been setting are names for things that just need values, for instance, the rc and page_num properties just need a number, not a reference to another object.

Ok, to preserve my, and everyone else's sanity, I've added a check. If the string in the softvolume field has no type, it will automatically add the "0088:" type. You can grab the version in the svn, and go back to exporting your ages without needing to change all your softvolume strings.

Note: Following info is directed at pyprp devs.

There should already have been a feature for that in the ref parser.
The PyArg classes use it too.
It should be just a matter of specifying the default type

Oh, *reads ScriptRefParser* indeed it does.

Ok, no more nasty check.

However, even though they export without errors now, it seems that the softvolume is never actually created, except by the refparser, which doesn't provide any data. Hence, the volumes don't actually do anything.

Now THAT would explain why after putting in the softvolume, my avie is STILL being lit up by the sun in the caves! Okay, I'm not crazy then!

My age doesn't have soft volumes, but it still crashes like Aloys said. What do I have to do to get it to work?