destrType addon "fixing" for objects placed in wrp

[fasad 1]

G'day all,

I'm working on an island, and have placed some mapfact heaps in wrptool. I've noticed that in OFP that these heaps will "flip up" 90 when destroyed, displaying their non-existant undersides. I assume this is destrType=tree. Unfortunately it looks completely absurd for these heaps... Ideally I would like these heaps to be indestructable, as they are when placed in the mission editor. Is there any way to change/fix this without having to revert to placing the heaps in the mission editor? I want them in the wrp file if possible. Using a looping script is not an sensible option.

I understand there is a destruction method specified directly in the p3d - does this override the config.cpp? Do objects placed in the wrp even use their config.cpp?

I have a similiar problem with BIS data3d/patniky.p3d, which flips up along it's longitudinal axis when destroyed. Can I change this without having to use O^2? I intent to change the destrType rather than rotate the object as I have never used O^2 (BIS have apparently done this themselves for data3d/plot.p3d - it vanishes when destroyed and is long in Z axis, wheras all other fences are long in X, and destrType tree rotates around X)

Once I have a new class, maybe I could use replace in my islands config, similar to the noe forest trick described in the wrptool manual?? Any suggestions?

Lastly, I'm not interested in any issues regarding messing with others work just yet. That's a seperate problem...

[.kju 3245]

EDIT: it should be about the destrType in the config.cpp and correctly named named damage properties.

so you should define a new class which inherits from the MAP heap in a new custom addon of yours and change the destruction type there.

[fasad 1]

Are you sure? I've come to the opposite conclusion.

I've changed and even deleted the config.cpp within MAP_heaps without any effect on the wrp placed objects. So long as the game can find the p3d and it's textures it is happy. Mission editor placed objects do behave as defined in the config.cpp.

Unless i've missed something huge, both visitor and wrpTool add objects directly from the p3d files, not through any config reference. For OFP to simulate these objects based on configs, it would need to load every config, then search backwards for any reference to the relavent p3d!? Also I can config two or more distinct class names that refer to the same object p3d!

I've looked at some BIS p3d files in hex, and found they do specify a destruction method (dammage). The Mapfact p3ds do not, so OFP apparently defaults to destrType Tree.

Looks like I'm learning how to use Oxygen : /

[ProfTournesol 956]

I'm almost sure that when models are placed on the map through Wrp, if they do not have correct named properties, particularly in the Geo lod (class, map and dammage) they will not use their config.cpp.

Named properties thread

This doesn't happen when placed in the editor.

If they do have named properties, i don't know what will be used first for the dammage system : the configed one or the p3d one, but i guess it is the configed one.

In brief, the models you're using are basically incorrect, they should be reworked in O2 to add correct property names, with the permission of their authors. Pay attention, if they are binarized, you must un-binarize them with Odol explorer (to have "mlod" models readable by O2), and Odol explorer will mess up the fire, view and Geo lods...welcome in Ofp's modelling world !  

[Fab. 0]

to answer your question, some object classes (like class house) - and when i say class, i'm talking about the "class" property in the p3d, not the config.cpp - do use the properties set in the .cpp

if i remember correctly, you can easilly check if an object use its cpp : add that somewhere in a script :

format["object class %1",typeof(object ID)]

(and replace ID by the object ID you see in the editor (and first you have to click the button "show IDs")

if it returns a classname (and the object is definied in the cpp) then it definitly reads from the cpp... if it doesnt then it doesnt use the cpp...

so yeah i'm about 99 % sure of that

and of course to emphasize what ProfT. said, it wont even work if the p3d or the config isnt made properly.

the best is to compare with some original BIS object and make it from there... and of course get permission and original mlod from the author first

good luck

Fab

Ps : for any objects that dont use the cpp there's no other choice but to edit the p3d... well in most cases unless the objects is made right to being with you're going to have to open o2..