FreeGameDev

Water effect? You mean like a watersplash effect: http://www.baileycare.ie/images/water%20splash.jpg?

I see several possibilities, but I'll have to see this in my minds eye first...

Basically at this point, two properties are needed for a material : one to say that a material has a water effect (this already exists); the other is to add a "height" property

Auria {l Wrote}:Basically at this point, two properties are needed for a material : one to say that a material has a water effect (this already exists); the other is to add a "height" property

Now I realise that there might be a minor problem: our idea was to get the height implicitly by computing the difference of two meshes (the 'river bed' surface the kart is driving on, and the water surface). But since it's a material setting, we don't easily have the first object. Even worse: what if we have two places in the track with the same distance, but different heights? We could not specify this (short of duplicating the texture with a different name). *sigh* Any suggestions?

Cheers,
Joerg

I've just discussed this with Auria, for now just wait before implementing this, I'll try if we can find a better solution in STK.

Cheers,
Joerg

Hi,

I've added support for weather settings to the track exporter. I also converted fog color from [0.0,1.0] to [0,255], before noticing that you already do this for sky-color. Now I am a bit confused I don't care where we do it, but it should be done in the same program

Could you have a look? I don't understand the property browser enough. I converted the values using a new 'convertColor' function in stk_track.py, just search for it, it's easy enough to see what I did.

Thanks!
Joerg

Hi,

more news: I also added animated textures for water nodes (identical to animated textures in the normal track). But I think that this is not yet supported by the browser (or did I miss something)?

Cheers,
Joerg

hiker {l Wrote}:I've added support for weather settings to the track exporter. I also converted fog color from [0.0,1.0] to [0,255], before noticing that you already do this for sky-color. Now I am a bit confused I don't care where we do it, but it should be done in the same program

First off let me say, unequivocally, that the browser should supply the correct value. If it doesn't it's my problem to solve.

A guiding principle in the browser is that it doesn't change any property until it is... changed. Even more so: The properties that have not yet been changed from it's default value aren't even created. It works similar to XSD vs. XML. In the XSD a node is defined with a default value, but that doesn't mean it has to be present in the corresponding XML.

So my guess is that the value has been set with the old version of the browser (set to 0.0,0.0,1.0) and hasn't been changed since (which automatically changes it to 256,256,256 format)... If it has been changed and it's still in the 1.0,1.0,1.0 format this is a bug I need to squash.

Also just like XSD you can define types. Both fog-color and sky-color are defined as type_COLOUR, and therefore handled exactly the same.

hiker {l Wrote}:I also added animated textures for water nodes (identical to animated textures in the normal track). But I think that this is not yet supported by the browser (or did I miss something)?

There is not supported and not supported. The datamodel of the browser isn't configured to allow water objects to be animated. It's a question of changing the proverbial XSD.

Yesterday I 've tried to use script I get this error :



What I've done wrong

What is your version of python ? (just enter "python" in a terminal)
Which distro ?

If you do this :

{l Code}: {l Select All Code}

python
>>> from symbol import except_clause


Do you get an error ?

I tried it on a windows computer at work I didn't know that python have to be installed. It's ok on Ubuntu.
It's a VERY good tool

I report maybe another bug which appear in type-selection-menu : when I select start python crash in blender and report :

{l Code}: {l Select All Code}

Traceback (most recent call last):
  File "stk_browser.py", line 704, in Draw
    for (prop_name,prop_type,current_value) in data.GetProperties(cur_objname):
  File "stk_browser.py", line 368, in GetProperties
    for prop in lSTKTypes2Properties[cur_stktype]:
KeyError: 'Start'



Nice job, congratulations

asciimonster {l Wrote}:First off let me say, unequivocally, that the browser should supply the correct value. If it doesn't it's my problem to solve.

'Correct' is a matter of definition, and if the values were [0,1] it is just as correct as the values being [0,255] - as long as it is consistent.

A guiding principle in the browser is that it doesn't change any property until it is... changed. Even more so: The properties that have not yet been changed from it's default value aren't even created. It works similar to XSD vs. XML. In the XSD a node is defined with a default value, but that doesn't mean it has to be present in the corresponding XML.

Hmm - I am not sure if that might have some disadvantages in the future. E.g. what if we should decide to change a default (admittedly unlikely, but who knows). If we would then re-export an old track, those properties would still not being exported, but since in STK then a different default would apply, some tracks might look different. From that point of view it looks to me to be better to export all values. Or am I missing something?

So my guess is that the value has been set with the old version of the browser (set to 0.0,0.0,1.0) and hasn't been changed since (which automatically changes it to 256,256,256 format)... If it has been changed and it's still in the 1.0,1.0,1.0 format this is a bug I need to squash.

I am not entirely sure what happened at that time, since I just assumed that the color values were still in [0,1] everywhere. I'll see if this happens again.

Also just like XSD you can define types. Both fog-color and sky-color are defined as type_COLOUR, and therefore handled exactly the same.

hiker {l Wrote}:I also added animated textures for water nodes (identical to animated textures in the normal track). But I think that this is not yet supported by the browser (or did I miss something)?

There is not supported and not supported. The datamodel of the browser isn't configured to allow water objects to be animated. It's a question of changing the proverbial XSD.

OK, I think I am getting a hang of the programming - quite powerful once you had a good look at how things work - great!

Cheers,
Joerg

Hi asciimonster,

I have a bug report : sometimes "anisotropic" is checked (set to 'yes') but when I export the track, materials.xml does not include anisotropic="y"

EDIT: another bug : many zipper parameters are not exported, I customized all parameters byt only "speed-gain" was exported

EDIT: oh, and yet another -.- we have a property called "friction" that can optionnally be set, it seems like the browser doesn't support it

EDIT: one more, sorry when skid condition is set to "skid" only, condition is not exported at all

STKRudy85 {l Wrote}:I report maybe another bug which appear in type-selection-menu : when I select start python crash in blender and report :

{l Code}: {l Select All Code}

Traceback (most recent call last):
  File "stk_browser.py", line 704, in Draw
    for (prop_name,prop_type,current_value) in data.GetProperties(cur_objname):
  File "stk_browser.py", line 368, in GetProperties
    for prop in lSTKTypes2Properties[cur_stktype]:
KeyError: 'Start'

Ah, I think I found the cause: There was an object defined as "type=start". Since the browser doesn't know this type of object it crashes.
I think it's best if this incongruity would be handled a bit better than a blunt crash...

Auria {l Wrote}:I have a bug report : sometimes "anisotropic" is checked (set to 'yes') but when I export the track, materials.xml does not include anisotropic="y"
EDIT: another bug : many zipper parameters are not exported, I customized all parameters but only "speed-gain" was exported

Hmm. That may be due to typo's. I'll have to test them separately.

Auria {l Wrote}:EDIT: oh, and yet another -.- we have a property called "friction" that can optionally be set, it seems like the browser doesn't support it

In what context? I can't find it in the wiki anywhere. Adding support for it should not be a problem.

Auria {l Wrote}:EDIT: one more, sorry when skid condition is set to "skid" only, condition is not exported at all

Hmm. I think I may overlooked something. Since "skid" is the default value, the property is not created. And the exporter isn't aware of any defaults... Thanks for spotting this.

You're right, I just added friction to the wiki ( http://supertuxkart.sourceforge.net/Mat ... Attributes )

hiker {l Wrote}:

A guiding principle in the browser is that it doesn't change any property until it is... changed. Even more so: The properties that have not yet been changed from it's default value aren't even created. It works similar to XSD vs. XML. In the XSD a node is defined with a default value, but that doesn't mean it has to be present in the corresponding XML.

Hmm - I am not sure if that might have some disadvantages in the future. E.g. what if we should decide to change a default (admittedly unlikely, but who knows). If we would then re-export an old track, those properties would still not being exported, but since in STK then a different default would apply, some tracks might look different. From that point of view it looks to me to be better to export all values. Or am I missing something?

Thanks a lot for implementing this. But then I noticed what I was missing (why didn't anyone tell me?? ) - it's much harder (if not impossible) to see why a certain material was listed. And also now (correctly of course) all materials are listed, making the files bigger and even more difficult to see what the important points are. Would it be a lot of work to disable this (i.e. leave the code in so that we can use it if we need to), but for now keep on getting the minimal materials files back? It's just that esp. atm with a lot of development happening I found myself looking at the materials.xml file quite often.

Cheers,
Joerg

hiker {l Wrote}:Would it be a lot of work to disable this (i.e. leave the code in so that we can use it if we need to), but for now keep on getting the minimal materials files back? It's just that esp. atm with a lot of development happening I found myself looking at the materials.xml file quite often.

Just revert to the previous version of the track exporter. That should undo the "damage" I've done

Auria {l Wrote}:I have a bug report : sometimes "anisotropic" is checked (set to 'yes') but when I export the track, materials.xml does not include anisotropic="y"

EDIT: another bug : many zipper parameters are not exported, I customized all parameters byt only "speed-gain" was exported

EDIT: oh, and yet another -.- we have a property called "friction" that can optionnally be set, it seems like the browser doesn't support it

EDIT: one more, sorry when skid condition is set to "skid" only, condition is not exported at all

I think they should all be fixed either by asciimonster previously, or at latest in r7728.

Cheers,
Joerg

Added new type_CHOICELIST. It's like a picklist but the options are not mutually exclusive.
Hiker, I hope you will appreciate the new option...

Hi asciimonster,

did you see those :

https://sourceforge.net/apps/trac/super ... /ticket/18
https://sourceforge.net/apps/trac/super ... /ticket/41

I think they're for you the first I'm sure, the second perhaps

Rehi asciimonster, I have another bug to report

See attached screenshot : the "sound effect" section and the sound-related parameters are not together, which is rather weird (and, little feature requests, do you think sub-parameters like SFX parameters could appear indented?)

thanks!


EDIT: oh, and also, graphical-effect="smoke" no more exists, it was superseeded by "particles", so you can remove that option please

Oh, yet another bug

I got this :

{l Code}: {l Select All Code}

  <sun  fog="true" fog-color="3060 1530 0" fog-start="0" fog-end="50"/>


This color definitely doesn't look legit (this is in the mine track; the color looks all fine in blender)

Auria {l Wrote}:See attached screenshot : the "sound effect" section and the sound-related parameters are not together, which is rather weird

Hmm. Some new additions were placed in between the (loosely) grouped items... I've corrected that.

Auria {l Wrote}:(...) and, a little feature request, do you think sub-parameters like SFX parameters could appear indented?

I've done that, but the effect still is not very pronounced... Any more suggestions?

Auria {l Wrote}:oh, and also, graphical-effect="smoke" no more exists, it was superseded by "particles", so you can remove that option please

I have removed "smoke". However, graphical-effect is now a picklist that only exists out of "none" and "water". And I believe "water" isn't even used. Are you considering removing it in the future?

Thanks a lot for the nice work

"Water" *is* used so don't worry

Hi,

the fog issue described above is still there in latest version, is this known?

Auria {l Wrote}:the fog issue described above is still there in latest version, is this known?

You mean the colour issue. No, I was not aware.
Are you sure the value was recently altered in the browser? Because values that do not need alteration are not altered... even if they are incorrect.