[Kazan]

someone requested export i think... but it's not an important feature to me... go ask in the feature request thread

it would probably add a lot because each time it changes is a GDI redraw on the UI plus it's difficul to really say at any one point - because first you're generating a tree... then you're writing it.  No way to guess completion on the first.. second i atleast know how many bytes should be written - but again it's a recursive function.

[Vasudan Admiral]

Import data would do a similar thing anyway wouldn't it? I can't really think of a good use for chunk export.

Anyway the subobject import is great! This is going to be incredibly handy for making gun count varients on already poffed ships and lotsa other stuff.
The global data import seems to work fine as well, but it'll need more testing to be sure.

I'm currently still experimenting with conversions and collision detection - because I'm getting a lot of problems there still.

[Water]

Only problem I found during testing was a crash if you click on subobjects with no model loaded (pre-existing). Didn't think it was important before , but may get used with the import ability. Otherwise it worked without any problems. 

Export, with what you have added, pof, pmf, and cob are all that is needed.

[Water]

new build - debug build included in this pair will generate a pcs2_txtsrch_log.txt upon it running texture load so if you need to debug your texture paths use it

http://ferrium.org/media/pcs2-alpha-20070625.zip

Got the debug build to work.

Your search is logging the textures in <path>/data/maps but doesn't generate a hit.

[Kazan]

then that means it didn't see the texture matching the name there... check that the ile is actually there - if it is see if it got missed by the dir wind - look at the list of files pumped out

[Kazan]

[edit]
nope.. i was wrong

[edit]
i'm stumped.. collision detection problems isn't because of an axis translation problem.. all the positions are correct, polygon norms are correct, etc... i don't get it

[Water]

then that means it didn't see the texture matching the name there... check that the ile is actually there - if it is see if it got missed by the dir wind - look at the list of files pumped out

By "logging the textures" , I mean it is listing the names of the files that should be generating a hit.

[Kazan]

it's showing the filenames in the big list of files... but it's not showing them being found?

what are the filenames and what type of file are they

[Kazan]

i think i've isolated WHERE the bug is.. and half solved it.

take a model and convert it in PCS1 and PCS2 .. open both in PCS2 and enable BSP debug... compare the red boxes (sort norms) you should see more in the PCS1 compiled one (there are actually less being made by PCS1.. but they're of MUCH higher quality) - code on my machine has that siginficantly cleaned up.. now i just need to find the other little problems with it

[Bobboau]

check the build in my sig kaz, the last tree item might prove useful, though I'm not committing any of that unless you want me to.

[Kazan]

what's it supposed to do?

[Bobboau]

look for the BSP DEBUG item in the tree. you can simulate collisions with a point and it will only draw the bboxes that are pertinent to that collision test. and you can limit how deep it goes into the recursion with the depth parameter.

one thing I've noticed with it is the sortnorms seems to fill up the same voluem for the most part, over and over, 50% seem to have a edge at the center, for example, most pofs, you don't see them pile up right on top of each other like that. it also seems like child bounding boxes go a lot further outside the parent than they should, like there will be a bounding box that covers everything on the right, then the child of thab box will have everything in the middle (both left and right)

[Water]

it's showing the filenames in the big list of files... but it's not showing them being found?

what are the filenames and what type of file are they

You are really hard to convince. This is my last test on this issue.

Tested tga vs dds - not relevant
Tested files with various names - not relevant

<path> is explicit c:\mtest\data\maps\

c:\mtest\data\maps\ Files
c:\mtest\data\maps\data\maps\ Files
c:\mtest\data\maps\ VPs
File matched: c:\mtest\data\maps\v_atkcarrier.DDS
c:\mtest\data\maps\Arwing-glow.DDS
...
...
c:\mtest\data\maps\v_atkcarrier-glow.DDS
c:\mtest\data\maps\v_atkcarrier-shine.DDS
c:\mtest\data\maps\v_atkcarrier.DDS
...
...
c:\mtest\data\maps\yellow_glowpoint1.DDS

<path> root only c:\mtest\

c:\mtest\ Files
c:\mtest\data\maps\ Files
c:\mtest\ VPs
c:\mtest\data\maps\Arwing-glow.DDS
...
...
c:\mtest\data\maps\v_atkcarrier-glow.DDS
c:\mtest\data\maps\v_atkcarrier-shine.DDS
c:\mtest\data\maps\v_atkcarrier.DDS
...
...
c:\mtest\data\maps\yellow_glowpoint1.DDS

[Kazan]

no water, i am being very clear because lack of clarity results in bugs not being fixed

bobboau: i noticed that about the snorms too and already fixed it in code, but that didn't seem to fix the collision problems.

[edit]
using your BSP debug stuff i figured my outermost bounding region may be to snug against the model

[Vasudan Admiral]

Bob; that thing is great! Can I safely assume blue = not in this box, red = in this box and green = collision? It's showing a massive difference (far fewer boxes of any type) between the PCS2 generated models and the previously converted ones.

[Kazan]

it's just not drawing all the boxes.  green = bbox, the rest are snorms (containing and not containing the sphere)

not drawing all the boxes actually annoyed me a fair bit i was like "Where the hell.."

it was useful to play with for a few minutes.. but it didn't find me the solution

[Bobboau]

yea, red is a sortnorm you colided with blue is a sort norm you tryed to colide with but failed to, and green is a bbox, hitting a bbox usualy means there will be a colision (exept when they are around 45 degreeish geometry)

I had actualy forgot about the blue box.

try moveing the test point onto an area were you are haveing colision problems, and if you can't get a green box to apear then that would be the problem (though it could just be very hard to see)

[Water]

no water, i am being very clear because lack of clarity results in bugs not being fixed

ok -  understand

[Kazan]

ok -  understand

which file is the one that should be being hit, but isn't? (that log output from builds i post after this point will have more detail)


Bobboau: i tried it.. it was giving me BBox hits in spaces that FS2 wasn't... so it's not going to help

[TrashMan]

PCS is driving me crazy lately..both verisons..

Older one keeps SHOWERING me with "stack overflow - too many polygons in same average location" and PCS2 keeps messing with the bounding/collision boxes and re-scaling of my friggin model!