FreeGameDev

I've just checked in the completely rewritten version of the STK property browser (stk_browser.py). The old code hit the limits, so I decided for a redesign.

It's got a lot of new features, for instance you can pick your colours with a colourpicker and you can select files from a directory browser. See for yourself.

Currently it's still a little buggy (I put too much features in there ), so I'll leave the old browser (stkpropbrowser.py) in SVN for now.

Hi,

thanks for the nice work

But I am unable to use it, I get :

Compiled with Python version 2.5.4.
Checking for installed Python... got it!
Traceback (most recent call last):
File "/Applications/Blender 2.49/blender.app/Contents/MacOS/.blender/scripts/stk_browser.py", line 566, in Draw
tmp_but = Draw.Number("", self.NextButton(), x, y, 100, textheight, int(current_value), 0, 100000000)
ValueError: invalid literal for int() with base 10: ''

Any idea what is the problem?

The script is trying to convert a (albeit empty) string to an integer and fails. This is most likely a property which I defined as an integer which in this blender file is currently filled with a string.

Adding try-except statements should help making the crash more gracefully. Thanks for the report.

Edit: I committed a patch, along with some other bug-fixes which I found myself

Hi,

thanks Now it works. Looks nice, good job

See attached screenshot; I tried it on Canyon track and I get a lot of parameter errors

EDIT: also note that "arena" is neither yes nor no; I suppose "no" should be checked. Same for fog

Also, I believe many sky-* properties are only appropriate for sky domes so if you wish to make something really neat they could be hidden if you select another sky type
Also, we have the need to support plain-color skies, so I suppose this should be another option

Auria {l Wrote}:See attached screenshot; I tried it on Canyon track and I get a lot of parameter errors
EDIT: also note that "arena" is neither yes nor no; I suppose "no" should be checked. Same for fog

I would love to see the blend file and use it to run tests on the browser.

The original property browser used weakly type strings to store the information. The new one uses strictly typed values, so they are easier to manipulate.
Once you pressed the reset button it should be all right, but it would be nicer if it would do the conversion for you. Some work to be done there...

Auria {l Wrote}:Also, I believe many sky-* properties are only appropriate for sky domes so if you wish to make something really neat they could be hidden if you select another sky type
Also, we have the need to support plain-color skies, so I suppose this should be another option

My first piority is getting it to work right. After that we could have a look at improvements.

asciimonster, you can find all the blends in our media repository : http://supertuxkart.svn.sourceforge.net ... dia/trunk/

My first piority is getting it to work right. After that we could have a look at improvements.

sure

The bend was a good test sample. A summary:

• A lot of values were actually empty. I think it's better for these values to throw an error in stead of silently inserting a default value. I hate programmes who try to outsmart you.
• fog: 0 is not equal to yes or no, hence no button is selected. I'm thinking of making a new type called type_BOOLEAN, so I can test all the ways you can call something true or false. It will also simplify hikers work.
• arena: "" in not equal to yes or no, hence no button is selected. In my view this is wanted behaviour (see above)
• start-forwards-distance/start-upwards-distance: I defined them as integers, but in this track they are clearly floats. I have changed that.

P.S. Wouldn't it be better to have the modellers determine where the start positions are just like the collectibles now (empty objects with type "start") the in stead of the game engine that take the, somewhat cumbersome, start-* properties?

asciimonster {l Wrote}:P.S. Wouldn't it be better to have the modellers determine where the start positions are just like the collectibles now (empty objects with type "start") the in stead of the game engine that take the, somewhat cumbersome, start-* properties?

*grin* I've said that for ages, till too many people complained that this is just too much work (e.g. to define the 20 correct start positions). So that's why I added the values, and all in all I think they work rather well, though are not easy to visualise.

Sorry for not participating actively here, too busy

Cheers,
Joerg

hiker {l Wrote}:*grin* I've said that for ages, till too many people complained that this is just too much work (e.g. to define the 20 correct start positions).

I've been thinking about also making a reverse browser. So not select an object to set its properties, but select a property and apply it to several objects. That would allow making start positions very easy...

hiker {l Wrote}:Sorry for not participating actively here, too busy

That's all right, we know that you have 1 million and one other things to do... And it makes me feel that my work really makes a difference .

Could somebody explain what properties are assigned to end camera's?
I can't seem to understand the explanation on this page

This is as far as I came:

• type = ignore -> Don't use as end cam
• type = "" -> Use as end cam (but that is not the behaviour I have seen)
• type = "ahead" -> Seems to be the default now
• type = "fixed" -> What's the difference with a single end camera?
• start = ??? -> I have no idea what type this property should be...

I think it's easier to set type="endcamera" to use it as an end cam rather than type being empty. Then a second property "endcamtype" defines it's behaviour.

P.S. Are particle-emitters and billboards attached to objects, and if so which ones?

asciimonster {l Wrote}:Could somebody explain what properties are assigned to end camera's?
I can't seem to understand the explanation on this page

Could you perhaps try to improve the docs (once you understand what I meant)?

This is as far as I came:

• type = ignore -> Don't use as end cam

This is a general property for all objects: anything with type=ignore will be ignored, so that's not camera specific.

• type = "" -> Use as end cam (but that is not the behaviour I have seen)

This is the default, and atm the same as 'ahead'. Though that might obviously change in the future, so best is to define one of the currently supported types.

• type = "ahead" -> Seems to be the default now
• type = "fixed" -> What's the difference with a single end camera?

Ahead is the default camera - the one you would get if you don't specify anything for any camera. The camera flies ahead of the kart, showing the end animation.

The 'fixed' camera is a camera that is at a fixed position. It points at the kart and zooms in so that the kart is nicely shown. Try the island track to see how this camera works. The position of the camera in blender is used to place the camera, while an 'ahead' camera does not use the position the camera is at directly (but see below).

• start = ??? -> I have no idea what type this property should be...

One thing that needs to be defined is when to use what camera. First of all the cameras are sorted depending on the quads of the driveline they are closest to (that sounds complicated - it basically means that the first camera is the one closest to the start line, the next camera is the one the kart reaches next when it keeps on driving along the driveline). This defines in which order the cameras will be used. When a kart crosses the lap line, the first camera in this order is activated (independent of any other settings). If the camera is an 'ahead of kart camera', it means that the camera will be moved (from the position in blender) to just ahead of the kart; if it's a fixed camera this camera will turn torwards the kart and zoom in.

The actual time when the switch to the next camera is happening depends on the 'start' value: imagine a sphere around each camera position in blender. After the first end camera is activated as described above, the kart will keep on driving. The moment it crosses the sphere of the next camera, the next camera will become the active camera (it 'starts' - that's why I called it start, though perhaps a better name might be found). Again, if that camera is an 'ahead of kart' camera, it will be positioned just ahead of the kart, and if it's a fixed camera, it will turn towards the kart and zoom in.

So the location together with the 'start' value allow you to define when to switch on the camera.

I hope that's a bit clearer?

I think it's easier to set type="endcamera" to use it as an end cam rather than type being empty. Then a second property "endcamtype" defines it's behaviour.

I don't recommend to let the type empty for a camera (perhaps the track exporter should print a warning and ignore the camera??). Your approach needs to define two properties, while mine only needs one (basically type=endcamera is deduced from the fact that the object is a camera, and your endcamtype becomes my type).

P.S. Are particle-emitters and billboards attached to objects, and if so which ones?

I am currently re-working the billboards: they will be attached to meshes with 4 vertices and one image (this is already the case, but the whole code to export it will be rewritten, esp. it will allow billboards to be IPO animated). I haven't really looked at the particle-emitter code.Ideally we would use the data from blender's particle emitter somehow (so that a blender rendering would be at least similar to the stk version), but if this is too complicated, we will probably just attach it to a mesh with some properties - samuncle, any comments here?

Cheers,
Joerg

hiker {l Wrote}:Could you perhaps try to improve the docs (once you understand what I meant)?

Will do.

[quote="hiker"]This is a general property for all objects: anything with type=ignore will be ignored, so that's not camera specific.
Hmm . Just this line forces me to rethink parts of the Property Browser. I was under the assumption that all objects only have one "type"; now I see that every object has a Blender "type" and a STK "type", which are dependent on eachother. Good thing holidays are coming up.

asciimonster {l Wrote}:

hiker {l Wrote}:Could you perhaps try to improve the docs (once you understand what I meant)?

Will do.

Thanks!

hiker {l Wrote}:This is a general property for all objects: anything with type=ignore will be ignored, so that's not camera specific.

Hmm . Just this line forces me to rethink parts of the Property Browser. I was under the assumption that all objects only have one "type"; now I see that every object has a Blender "type" and a STK "type", which are dependent on eachother.:

Well, in terms of the track exporter everything has a 'type' property. But most stk-types are restricted to certain blender objects (e.g. 'type=item' to empties etc). But I do use the type of the object to reduce the amount of work/typing (and the number of things to remember) for artists. I.e. if there is a camera, you don't have to specify that again

Cheers,
Joerg

hiker {l Wrote}:

asciimonster {l Wrote}:

hiker {l Wrote}:Could you perhaps try to improve the docs (once you understand what I meant)?

Will do.

It's an important element for me, so tell me when it will done, So I will make a translation in french (In the same time of reading).

... Take your time, and Thanks too

Just added a "Use Current" button. This makes the browser lookup which object is currently selected and uses that.

Thought it might be useful.

I've made some large changes to the STK browser. The behaviour is now different, it now suggest values depending on current settings. It should also prevent some values from being set too low/high (e.g. sky-texture-percent cannot be set higher than 1).

Please download the latest version of stk_browser.py and try it out. I'm looking forward to you bug reports.



P.S. How many of you are using the stk browser? And if so, do you find it useful?

Hi,

looks nice
Now I don't need to change track parameters that often, so sorry if I don't have immediate feedback, but be assured I will be using it next time I work on tracks

Hi,

asciimonster {l Wrote}:P.S. How many of you are using the stk browser? And if so, do you find it useful?

well, I am not doing much work with blender. Once we publish and document this a bit more, it will certainly be very useful. Atm it requires people to dig through the forum to find it,

Cheers,
Joerg

Hi asciimonster,

I played a little with the property browser and found a couple bugs :

* in "sky", "dome" is selected by default (when you create a new track), but the parameters under it, like sky-texture, don't appear until you click "box" then click back on "dome"
* if you're already scrolled to the top and you press "up" one more time, the next click on "down" has no effect

Also, I might add that the "Use Current" button is not very clear? Maybe a tooltip could be displayed when you hover the button

Otherwise, very nice work, don't give up

Auria {l Wrote}:* in "sky", "dome" is selected by default (when you create a new track), but the parameters under it, like sky-texture, don't appear until you click "box" then click back on "dome"

Was hard to find, but I squished that bug.

Auria {l Wrote}:* if you're already scrolled to the top and you press "up" one more time, the next click on "down" has no effect

I had already seen that one long ago and had it low on my priority list (being only visual). I think this would be better now.

Auria {l Wrote}:Also, I might add that the "Use Current" button is not very clear? Maybe a tooltip could be displayed when you hover the button

Done.

Auria {l Wrote}:Otherwise, very nice work, don't give up

Moi? Never!

Hi,

I added the "additive" property to materials.xml (it can be "Y" or "N", default should be "N"). Maybe you could add this to the materials setup editor?

Auria {l Wrote}:Maybe you could add this to the materials setup editor?

Your wish is my command.

Question: If you have additive mixing, why not have subtractive mixing?
Mixing(none,additive,subtractive)

The main reason is that I think additive mixing is way more useful than subtractive mixing additive mixing is nice to make fire effects. Subtractive mixing... not sure what it's useful for? But if someone wishes to request new blend modes I'll add them

Oh and : thanks for adding it so quickly. But I now have an idea for improvement

atm we have "alpha", "transparency", "additive". Those 3 are exclusive. So I suggest to create something like "graphical-effects", with all those items (plus "No transparency" or so) on a single line and you can select only one item.
Sounds feasible?

Auria {l Wrote}:we have "alpha", "transparency", "additive". Those 3 are exclusive. So I suggest to create something like "graphical-effects", with all those items (plus "No transparency" or so) on a single line and you can select only one item.

The picklist graphical-effects already exists:

{l Code}: {l Select All Code}

lSTK_Picklist = {
                "graphical-effect": "none|water|smoke",\

I'll create a picklist called texture-effect:

{l Code}: {l Select All Code}

+                "texture-effect": "none|alpha|transparency|additive",\

With "none" as the default value:

{l Code}: {l Select All Code}

lPropertyDef = {
+    "texture-effect":[type_PICKLIST,"none"],\
-    "additive":[type_BOOLEAN,"no"],\
-    "transparency":[type_BOOLEAN,"no"],\
-    "alpha":[type_BOOLEAN,"no"],\


And make it show on every texture:

{l Code}: {l Select All Code}

lSTKTypes2Properties = {
+-    "Texture":["clampU","clampV","texture-effect","light","sphere","slowdown-time","anisotropic",\