colour bug,

[Frame]

reading the wiki i found this..

Colour specifiers

Colour specifiers are used to declare colours in material attribute dictionaries, and in other contexts such as lasers in shipdata.plist. Colour specifiers take any of several forms

so i read on and read this

RGBA tuples

Colours may also be specified in RGB or RGBA (red, green, blue, alpha [transparency]). RGB or RGBA tuples may be specified as arrays or as strings separated by spaces. The values may range from 0 to 1 or 0 to 255. (If no value is greater than 1, 0–1 is assumed, otherwise 0–255.) Examples:

* <string>1 1 0</string> <!-- yellow -->
* <string>0 128 0 128</string> <!-- medium green at 50% opacity -->
* <array><real>1</real> <real>0</real> <real>0</real></array> <!-- red -->

So for a particular ship, I set it to medium green at 50% opacity in open step format... as stated it could be done on the wiki

Code: Select all

laser_color = "0 128 0 128";

it does however come out deep red Like this: press thumbnail to enlarge



My settings are

shaders:full
detailed planets:on
reduced detail:off

So is this not a bug ?, I can't make sense of it.

[JensAyton]

Fixed in r3113. (Note: the alpha component is ignored for laser colours.)

[Frame]

works

however I got possible insignificant warning in rvn 3113, while making the build..

Code: Select all

src/Core/Scripting/OOJSShip.m:1788:2: warning: no newline at end of file

not sure if it has been there all along or for how long, my guees is that the compiler does not like a file to not end with a new line as a quick check seemed to indicate that other files end with a newline

Cheers Frame...

[Cmdr James]

I added a new line for you in 3114.

[JensAyton]

not sure if it has been there all along or for how long, my guees is that the compiler does not like a file to not end with a new line as a quick check seemed to indicate that other files end with a newline

The compiler doesn’t really care, it just warns you because some stone-age Unix tools will crash if text files don’t end with a newline (or have too many characters in a line). Anyway, putting the newlines in to appease it is simple enough.

[Frame]

not sure what goes on now--

spawning some OXP content that used to work, even when accesing the load game and for it to show an OXP ship makes Oolite crashes with no warning or error logs...

im trying to nail what is causing this, so far without luck :-/

[another_commander]

Do you have a reliable way to reproduce, so that we can attempt to have a look at it, too?

[Frame]

Do you have a reliable way to reproduce, so that we can attempt to have a look at it, too?

yes try spawning this

http://www.box.net/shared/jjtccmve33

with player.ship.target.spawn("avengerpirateframe")

it just crashes the game, with no warning or it seems valid reason

[Eric Walch]

it just crashes the game, with no warning or it seems valid reason

It seems to hang with me in OOMesh.m line 1287 were the normals are generated.

I get the same crash when i just spawn the cockpit or frontgun subentity or spawn the enclosed missile.

Unrelated: PirateAI.plist should be pirateAI.plist

[Frame]

it just crashes the game, with no warning or it seems valid reason

It seems to hang with me in OOMesh.m line 1287 were the normals are generated.

Unrelated: PirateAI.plist should be pirateAI.plist

I seem to have narrowed it down to something about normals too..

I think its models generated by the Obj2DatTexNorm.py script..

since models I convert with the old obj2dattex.py script seems to not crash the game...

[Frame]

http://www.box.net/shared/4lv7hobkoy

The models converted, by the old obj2dattex.py script..

however with the smooth section slightly modified to accomodate for 17 explicit smoothing groups.

I think the obj2dattex.py script in trunk is sufficient too..

[Eric Walch]

After importing the missile in wingz and writing out an obj file I still had the crash. It did not matter is I set all vertices to hard or soft. And that missile looks not complicated as model.

[JensAyton]

Fixed in r3116.

[Frame]

Works again...

However Obj2DatTexNorm.py can sometimes generate the following

Code: Select all

C:\WorkArea\Ootilities>Obj2DatTexNorm.py DreadEngineLowerWing.obj
converting...
['DreadEngineLowerWing.obj']
DreadEngineLowerWing.obj->dreadenginelowerwing.dat
going to open material library file: ./DreadEngineLowerWing.mtl
Material orig_01_-_Default -> Frame_Polaris_PatchSteelPlates.png
Traceback (most recent call last):
  File "C:\WorkArea\Ootilities\Obj2DatTexNorm.py", line 244, in <module>
    if (bits[2] > ''):
IndexError: list index out of range 

I know how to get around that and where it happens to my models, and I'm not sure it can be replicated in wings, at least once I fix the polygon/smoothgroup/normal in question, I cannot manually replicate the error..

I Think it happens when some optimizing routine in max, makes funny things.

In another case it did not like that I deleted a face, without redoing the smooth groups..

anyway it works now

superb work Ahruman and Eric Walch

Cheers Frame..

[Eric Walch]

anyway it works now

superb work Ahruman and Eric Walch

I didn't see how to fix it, so the credits belong fully to Ahruman.

Even better, I noticed also a collision related update by Ahruman this weekend. I was curious, loaded myself in an omega-caduceus and flew several times through the fuel stations. From both sides and at the end at full injector speed. No crashes.