Page 1 of 1

Switching Object Models in a MOD

Posted: Sun Mar 11, 2007 6:44 pm
by Floyd
is it possible to switch from one OOF to another for an existing object in a running game?
if yes, how do i do that with a mod?

help would be much appreciated, thanks.

Posted: Sun Mar 11, 2007 9:52 pm
by DCrazy
In the process of a game you want to swap out one polymodel for another? Or do you want the polymodel to be changed throughout the course of the game, from start to finish?

If it's the latter, then just put a polymodel with the same name in your HOG file.

Re:

Posted: Mon Mar 12, 2007 4:56 am
by Floyd
DCrazy wrote:In the process of a game you want to swap out one polymodel for another?
this one. an alternative was to change he light emissions (color). it will be used to distiguish to which team it belongs.

Posted: Mon Mar 12, 2007 6:26 pm
by Floyd
after a while of looking how to change light values, i eventually found out how to switch models too. :D

thanks anyway.

Posted: Tue Mar 13, 2007 4:25 pm
by Floyd
ok. i can switch polymodels for objects. but i can't find out the polymodel number of an (custom) object with no currently active instance in the level.

there is an ugly workaround: to just put one instance of the object in the level outside, so that it's just there for reference, and/or destroy it after aquiring the model number.

but since the necessary object should be loaded anyway on levelstart, it must be somehow possible to determine it's polymodel number, even if it's not \"alive\".
although .id is referenced as \"polygon model number. (Index in Poly_models)\" in polymodel_external.h, i have had no luck with this:

Code: Select all

poly_model *pmodels=NULL;
pmodels=DMFCBase->GetGamePolyModels();
[...]=pmodels[i].id;
anyone?


sorry for triple posting ...

Posted: Wed Mar 14, 2007 7:35 pm
by WillyP
I am thinking you could have, say object 'A' and object 'B' in the level at start. 'B' is ghosted at level start. Player can interact with 'A' until you want to switch, then you copy location of 'A' to clipboard, ghost 'A' then copy 'B' to the location stored in clipboard, and unghost 'B'.

Posted: Thu Mar 15, 2007 6:36 am
by DCrazy
WillyP: We're talking about using DMFC (C API), not DALLAS.

Floyd: if an instance of a polymodel isn't in a level at load time, I believe the polymodel is not loaded into memory. You could try looking at the functions that manipulate tablefiles and see if you can find otherwise. Maybe you could instantiate an object on demand, copy its polymodel to the player's ship object, then delete the temporary object. That's how the OG3 ship selection code worked.

Re:

Posted: Thu Mar 15, 2007 12:44 pm
by Floyd
DCrazy wrote:...
You could try looking at the functions that manipulate tablefiles and see if you can find otherwise.
thanks, i'll look into that.
Maybe you could instantiate an object on demand, copy its polymodel to the player's ship object, then delete the temporary object. That's how the OG3 ship selection code worked.
i kind of do it this way currently, but i placed the objects outside of the level shell, this way i can spare the spawning and deleting.
though i can read the polymodel list, which spits out all ~850 polymodels. the only thing i wonder about is why the polymodel id is different to the polymodel number of the object, which changes the actual polymodel ...
i'll see what i can do with your first suggestion.

thanks for the input. :)

UPDATE: polymodel ids are actually object polymodel numbers :oops:.
i think it didn't work, because the polymodel name is the complete file name, but i searched the pmodels array for the object table.gam name entries...
sorry.

i will verify if that works. if anyone is interested how that works, i can post that afterwards. :)

Posted: Thu Mar 15, 2007 2:11 pm
by Floyd
woohoo, it works! :D
turns out that my search routine was majorly flawed besides the above mentioned, which was not too obvious :oops:
but the nomenclature is inconsistent and thus misleading :/ (once it's .model_num, then it's .id)

anyway, my guess is, that D3 loads the table completely, as a list of all polymodels is in memory. and currently unused models are probably loaded on demand.

sorry for the inconvenience, and thanks for the input everyone :)