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.
Switching Object Models in a MOD
Re:
this one. an alternative was to change he light emissions (color). it will be used to distiguish to which team it belongs.DCrazy wrote:In the process of a game you want to swap out one polymodel for another?
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:
anyone?
sorry for triple posting ...
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;
sorry for triple posting ...
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.
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:
thanks, i'll look into that.DCrazy wrote:...
You could try looking at the functions that manipulate tablefiles and see if you can find otherwise.
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.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.
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 .
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.
woohoo, it works!
turns out that my search routine was majorly flawed besides the above mentioned, which was not too obvious
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
turns out that my search routine was majorly flawed besides the above mentioned, which was not too obvious
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