Oolite Bulletins

Frame wrote:

Ahruman wrote:

Arexack_Heretic wrote:

we elites are adapted to seeing straight edged representations dammit! ;)

Tell a jackal to flank around and get a better look.

?

That was a Halo joke. Sorry.

If the bug persists in 1.69, I’d like to take a look at it. But no, I don’t intend to add any new scripting methods for 1.69. Put it in the scripting requests thread, which I’ll be going through before 1.70.

appearently it seems oolite do not like the length Or/and the size of the keelback...

Collisions are calculated wrong as i am hitting the ship where there is no model with my laser... This is on 1.68 and 1.69

At first i presumed it may to be with the bounding box of the model being used as collision detection, but it lookes like though that the smaller subentities are "well", which is also something i will work on, so that the main "mother" model with get split into more sub entities... perhaps even more polygons...

You can get the same effect by targeting a station and sometimes you get hits where this is no model... that may have to be however with the station rotating

all models main + sub entities are to spec which means below 1.68 max settings of 512 faces, 318 vertices... i really have no way of calculating Vertices per face that i know off...

i have no way of importing dat files to 3dmax 7, so im guessing what is wrong here, as i cant visually look at the behemoth and other size liked models...

My reasoning has brought me to the following presumptions

Presumption #1

Oolite simply dont like that many faces + the size of a model Which equals about 1100 polygons...

Presumption # 2

Python Script may convert values Wrongly, something i´m looking into as i earlier found a bug in this script, that however was easely fixed... and previous models has worked fine.. however there seems to be a snag with the Scarlett and the Shader Code... im not perticulary certain that it is the Shader code, it may be the keelback still playing tricks Via oolites 1.68 Cache system... again pure speculation....

So the concept has hit a deroute and will take longer to complete...


Cheers Frame...

Switching to "FULL DEBUG MODE".... ...

Which means Value bug hunting...

Crash problem seems to be sovled with 1.68, new model splitting seems to have solved the issues.... might have been a model fault... hard to tell...

Collision issues are still not solved though but it isnt to much of a annoyance since it will only be visually incorrect when you are very near the keelback...

Anyway it works, now to make the docking bay work.... and test that interesting launch ship thingi i found while scanning the svn...

may launch a ship or may not..

1.69 seems to crash for other reasons...

E-mail me (PYMOLCLSXGQP squiggle spammotel point com) the OXP or a link to it and I’ll look into it. Oh, and report 1.69 crashes properly. :-)

Ahruman wrote:

E-mail me (PYMOLCLSXGQP squiggle spammotel point com) the OXP or a link to it and I’ll look into it. Oh, and report 1.69 crashes properly.

Done...

im not sure why 1.69 crashes, so the report would be very vague, however i think no ships, or missing ships in demoships.plist will cause a crash after a death and the press space to continue screen pops up..

What, no ships in any demoships.plist? Emptying the built-in config files isn’t really a supported operation. :-)

Ahruman wrote:

What, no ships in any demoships.plist? Emptying the built-in config files isn’t really a supported operation.

yeah i know, but at least it worked in 1.65/68, i know you aint really supposed to do that... but sitting and waiting for all the "built in" ships to appear before my test object appears is beyond my partience...

Its like coding, you aint really supposed to do certain things, yet you do them anyway.. speaking from coders point of view...

OK, that shouldn’t crash but it’s not a priority fix. The laser hit testing problem is confirmed; I think it’s an octree calculation problem, which I’m not entirely sure how to debug; it probably won’t be fixed for 1.69.1.

Frame wrote:

yeah i know, but at least it worked in 1.65/68, i know you aint really supposed to do that... but sitting and waiting for all the "built in" ships to appear before my test object appears is beyond my partience...

Well, you can always name your test something like zzzzMyOXPTest.oxp (as LittleBear has mentioned on another thread), so that it will be read last and once the demo ships screen comes up press the left arrow key to go and view the last ship in the list. This will be your test ship and if there are many in your OXP then you can press left arrow to go through the list in reverse order. No need to wait for anything.

another_commander wrote:

Frame wrote:

yeah i know, but at least it worked in 1.65/68, i know you aint really supposed to do that... but sitting and waiting for all the "built in" ships to appear before my test object appears is beyond my partience...

Well, you can always name your test something like zzzzMyOXPTest.oxp (as LittleBear has mentioned on another thread), so that it will be read last and once the demo ships screen comes up press the left arrow key to go and view the last ship in the list. This will be your test ship and if there are many in your OXP then you can press left arrow to go through the list in reverse order. No need to wait for anything.

left key... left key.... left key.... Grrrrrrr....
why have nobody told me that before know... lol

Still have to wait for it to zoom in and out though....

nice trick though with the renaming of OXPs... reminds me of something i did code once... basicly used a Add packed files function for Mod support for a game named Freespace2. Tricked it so to speak into beleiving a mod was a CD so that it added the contents of the mod to the game.... before that it had been a messy way of copy /pasting mod-packs into the game direcotry, in order ot get a mod to work... but people had a hard time figurering how to use it... since it was a command line option.

namely fs2.exe -mod mymod

Would include directory contents of /mymod/*.* into the game...

This structure could also be used for oolite for example

oolite.exe -mod Assasins
OR
oolite.app -mod Assasins

would only include OXP content from assasins thus eliminating complications when two mods are having trouble running together...

But then you would only be able to run 1 mod at anyone time... And that is not in the spirit of oolite i think...

anyway Thanks for the Tip, its very usefull...


if you have more, bring them on...

Cheers Frame....

very nice looking! reminds me of a star trek episode slightly... ^^ too bad there aren't spinal mounted capitol ship weapons in oolite! ;D

what about borrowing the rock hermit's set up a bit and make a dockable area up front, under the cockpit? it doesn't need to be deep, just recognizable. even cooler would be opening bay doors, and such a large non-station-docking ship would surely have an indoor sales counter.... =)

nijineko wrote:

very nice looking! reminds me of a star trek episode slightly... ^^ too bad there aren't spinal mounted capitol ship weapons in oolite! ;D

what about borrowing the rock hermit's set up a bit and make a dockable area up front, under the cockpit? it doesn't need to be deep, just recognizable. even cooler would be opening bay doors, and such a large non-station-docking ship would surely have an indoor sales counter.... =)

It has a Dock at the rear, the section where it is widest... ATM only a carefully manouvred Cobra MK III or smaller craft can be docked....

maybe a Boa/anaconda or Python Cruiser can be docked tooo... but that is only because of theire pointy noses, i havent tried as i have focused on getting it to not chrashing 1.68.. The latest Model splitting has made shading look ugly, so i will prolly have to rework this...

smoothing and shading is a very punishing art, if the model is not designed towards this from the start... ill prolly have to reduce the polygons used again as i am starting to understand what is causing the Crashes... is not allways the keelback, but stupid mistakes of mine... thankfully i have lots of backups... so this should be a walk in the park....

but you never know.. old murphy is such grunt...

I have a suspicion that Oolite will crash if the number of polygons in a model is less than the limit, but they subdivide into more than 512/800 triangles. I can’t say for sure, because I don’t entirely understand Giles’s model-loading code… it’s one of the many things I want to give a good going-over. :-)

i just noticed the freespace comment! yea! love that game. =D just found a mod that allows you to play the pc version on a mac. ^^ may have to dig it out again. =D

Ahruman wrote:

I have a suspicion that Oolite will crash if the number of polygons in a model is less than the limit, but they subdivide into more than 512/800 triangles. I can’t say for sure, because I don’t entirely understand Giles’s model-loading code… it’s one of the many things I want to give a good going-over.

None of the models of the keelback exeed 512 faces(triangles), the largest one is 468 faces... Not polygons, if you refer to polygons as if they where Quads.

You cant know... but i have been modeling for so many years now, that i´m allways measering my polygon count, in faces which are triangles. It´s sometimes a funny debate wheter a polygon is a face or not...

3dmax have a way of triangelating(im refuse to use the word triangulate which is totale different thing). meshes, however the export from max to Obj files is in itself a triangelisation of the mesh since this seems to be a requirement of obj files.. that all faces are triangles...

now, i can´t know how giles code or the python script rather... subdivides it...

but i can subdivide it before the export thus theoreticly eliminating the need for sub division and prevent

but i´m not convinced this will solve any problems since on all accounts, the faces and vertex count in the dat files, matches that in 3d max..

Cheers Frame...