Redefining Polyobjs
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Beta 6, Engine, Releases, Version 1.9.</i>
A while back we were discussing the future of polyobjs and that it would make sense to treat them as mobjs. To that end, I have made a fair number of changes in svn in how these are handled.
Currently the maploader will locate polyobject constructs in the map and rather than letting the linedefs that define them go through the normal process; the structure is transferred to Doomsday as independently as a complete entities. The linedefs are removed from the map and Doomsday, as a result will build the BSP as if they were never there.
The way I've envisioned this working is that Doomsday constructs a model-like object that can be linked to multiple mobjs spawned and controlled by the existing logic for mobjs. Though as mentioned above, the extraction of them from the map data is actually handled in the map loader. I consider this as a pretty good compromise and will now allow us to manage them as self contained entities rather than as the old "collection of moveable wall segs".
The next step of course is to get them spawned into game world once more and to update their handling, which in practice means we now look at using a mobj to act as their controlling object and thus most of the existing code to handle them will need to be revised.
Now, how closely tied to the mobjs do we want them to be?
Certainly, a lot of the existing mobj properties have direct correlations to polyobjects; position, angle etc. However a lot of those properties are quite meaningless when a mobj is considered as the origin of a polyobject.
Perhaps we need to revise the base mobj structure itself and redefine mobj_t as "an anchor to a free-moving, world object managed by the engine". A more minimalist base struct which would appear at the start of other, more high-level structures (such as mobj_t, polyobj_t, whatever...) . This would allow us opportunity to control all variants the same way.
Naturally all this means that polyobjects will not be handled through DMU.
A while back we were discussing the future of polyobjs and that it would make sense to treat them as mobjs. To that end, I have made a fair number of changes in svn in how these are handled.
Currently the maploader will locate polyobject constructs in the map and rather than letting the linedefs that define them go through the normal process; the structure is transferred to Doomsday as independently as a complete entities. The linedefs are removed from the map and Doomsday, as a result will build the BSP as if they were never there.
The way I've envisioned this working is that Doomsday constructs a model-like object that can be linked to multiple mobjs spawned and controlled by the existing logic for mobjs. Though as mentioned above, the extraction of them from the map data is actually handled in the map loader. I consider this as a pretty good compromise and will now allow us to manage them as self contained entities rather than as the old "collection of moveable wall segs".
The next step of course is to get them spawned into game world once more and to update their handling, which in practice means we now look at using a mobj to act as their controlling object and thus most of the existing code to handle them will need to be revised.
Now, how closely tied to the mobjs do we want them to be?
Certainly, a lot of the existing mobj properties have direct correlations to polyobjects; position, angle etc. However a lot of those properties are quite meaningless when a mobj is considered as the origin of a polyobject.
Perhaps we need to revise the base mobj structure itself and redefine mobj_t as "an anchor to a free-moving, world object managed by the engine". A more minimalist base struct which would appear at the start of other, more high-level structures (such as mobj_t, polyobj_t, whatever...) . This would allow us opportunity to control all variants the same way.
Naturally all this means that polyobjects will not be handled through DMU.
Comments
We now need to get this working in a networked environment so that means in essence two things:
<ul>
<li>Plane deltas will need to be sent separately and not as part of the existing DT_SECTOR delta type.</li>
<li>We will need full create/destroy control deltas similar to those used for mobjs.</li>
</ul>
I have been considering though that given that maps are now constructed dynamically in the engine; whether we could make the whole lot available over a network. In other words, client<>server runtime map editing. How cool would that be :-)