[Kazan]

crashing on POF save? that's really screwy

if it gives you a stack overflow warning that means your model file is ****ED UP

[Kazan]

i see there is a saving bug.. nice of people to tell me

[Kazan]

it's in OBJ2... big suprise [/sarcasm]

[Kazan]

and another bug bites the dust!

fixed that damn saving bug.. commiting to CVS

[EdrickV]

FS2 doesn't store info in the registry about where it was installed, but it does put an uninstall string in that has the path and that's what PCS uses to find it. Interesting technique.

[Kazan]

i am well aware of this

[EdrickV]

But Bobboau wasn't.

[Bobboau]

so were is it?

[IceFire]

Probably on his source database thingysite (sorry, its late, im tired).

[EdrickV]

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\FreeSpace2 the UninstallString value. (FYI, I would recommend not changing it because that could cause you to be able to uninstall FS2. )

[Galemp]

OK, as long as we're talking about PCS bugs...

I've had models that convert fine with COB2FS2. However, they either cause a stack overflow in PCS, or they convert fine and crash PCS when I try to save. Also, the 'import values' buttons don't seem to work. At all. Not even a dialog box asking me which model I want to import the values from. I can send you some example models if you want.

That 'clearing current POF from memory' message bugs the heck out of me when I first start the program up. Can't you have it check to see if there IS a current POF loaded? Mouse support in the model viewer would be nice, too, but I don't use it much.

[WMCoolmon]

FYI, I would recommend not changing it because that could cause you to be able to uninstall FS2.

[Kazan]

the data import buttons were placed as place holders but i haven't got around to writing the functions yet

cob2fs2 doesn't properly generate BSP/IDTA data for the POF - POFCS is more sensative to conditions which cause infinite recursion because of this - if you go into infinite recursion your model is very ****ed up because it overcame a 16 perumtation avoidance algorithm that is in there to try and make the model compile anyway

i don't know why anything would be crashing on save except for that mysterious double-save crash bug which i squashed today


the first two "bugs" are well documented facts about PCS

[Galemp]

I'm sorry. Please define '****ed up' as it applies to COBs.

[KARMA]

little OT, but... somebody knows if the source of cob2fs2 is avaible somewhere? i need it to have vadar_1 fixing (if possible) a little bug i found sometimes ago

[Kazan]

Galactic: polygons with the same geocenter - the avoidance algorihtm can handle a few - but having enough to cause a stack overflow = model ****ed up

BSP splits operate off the position of the polygons in the universe - so when you have polygons in the same position it cannot "split" them into different regions and it goes into infinite recursion

[Bobboau]

ok, that got it, finaly works now, I had moved my directory without changeing that, didn't look like the path was stored anywere.

I can't beleve anyone would have the problem of haveing pollys in the exact same position, it sounds as though it would be a little hard to do it on perpose, do you think it could posably be something like the BSP generation code not takeing subobjects offsets into acount thus makeing anymodel with a bunch of turrets (or any submodel for that mater) that look just like each other and in the same orientation,
I have noted a slight bug when converting from a pof to a cob all subobjects are centered at 0,0,0 includeing turrets that are way the hell off center, this means I have to recenter them after conversion, this isn't that big of a pain, but it could be indicitave of this sort of misstep.
or maybe there are subobjects that have polys aligned to each other with faces placed at each others center, to make it look like there together (like the top of a turret base and the bottom of a turret barrel, some people do it that way)

GE see if you'r model has many identical turrets faceing in the same relitive direction, or has subobjects with pollys aligned

[Kazan]

each SOBJ is compiled seperately - it has to be - and it's coordinate system is relative to it's centerpoint

the polygons themselvs dont have to be coincident - just they geometric centers

[EdrickV]

Originally posted by Bobboau
I have noted a slight bug when converting from a pof to a cob all subobjects are centered at 0,0,0 includeing turrets that are way the hell off center, this means I have to recenter them after conversion, this isn't that big of a pain, but it could be indicitave of this sort of misstep.

You need to center the axis location for each subobject in TS before you convert it to a POF. Many 3D programs only assign 1 axis for all the subobjects. TS allows each object/subobject/combined object to have it's own axis. That's especially important for multi-part turrets, since the axis location is the location that the turret will rotate around. It's best to do the axis stuff before you start gluing things together, because when you glue stuff together each combined object has it's own axis which is taken from the axis of the main object in it. If editing a model that's already glued together, you have up to twice as many axis to fix. The axis center is also used as the object center for things like firing point locations and turret subsystem locations as shown in the HUD targeting box.

[Bobboau]

I know, I have made a few models
but when converting from a pof to a cob the axes of the subobjects are centered at the center
I don't have any problems the other way around