Music Man,
I dont think you should have any collision problem on large entities if they are set as static entities. i.e. to be considered by the engine as would any piece of world geometry (walls, floor)
You can use a terrain model entity (static entity) in FPSC which covers the whole 40 x 40 tile area (or thereabouts) and walk over it without falling through. Collison is correct and you cant get anything bigger than that. Centre point of entity is in centre tile of world and thats where FPSC sees the centre of the object and believes it to exist yet you can walk over the whole terrain. In this instance world tile size has no bearing, either horizontally or veritically.
Having said that I have not tried very large entities V1 yet so this needs confirming in the release version of V1.
Mr Love,
You can indeed use your own segments or entities. Both use .x files for object description in something of a different manner. If you can design your objects so that they fit within the tile cube size then do so and use as segments making up an object in pieces if necessary (as with ramps spanning more than one tile height) - they do not necessarily have to be square or exact cube shaped, however for complex shapes or in the case of large objects spanning multiple tiles they are best inserted as entities. Effectively the begining and end result is the same. Both segments and entities are composed of .x files and in both cases visually in game there need be no difference whichever is used.
Its a matter of choice, experience and testing to see which is the best choice. In some instances this is obvious as its more difficult to achieve complex or large shapes with segments. Other things like how a lot of (complex) segments or entities affect fps will need actual testing during development. In some instances you may wish to use a lot of large entities as world objects but may find they slow down fps whereas a lot of smaller even more complex ones wont - How FPSC sees and complies world objects and the resultant no of ploys seen to view from any one location in game is not known exactly to me and in highly detailed complex levels it seems FPSC does not cull all the Polys that should be hidden and discounted as effectively as it should so some experimentation is needed in complex levels to get the best result.
As a general rule as would be the norm segments should be used for most general buliding of the level and entities used for detail active content and any things you cant achieve using segments.
Building a whole City with numerous entities or just one entity well it could be done I guess but I would not like to say how FPSC would treat that in compile and decide how it would compute the resultant output in terms of what it culls and how it would affect fps. TGC may know the answer to this?
As a matter of point certainly FPSC does seem to have some problems in rendering a view in game and deciding how many polys are being seen and are to be rendered to the view. I have a City where the player standing close to a wall - facing it so that there is nothing much in view and fps drops off to an unacceptable and unplayable figure as FPSC calculates there are in the region of 80,000+ polys to view. As far as I can ascertain it draws all the polys from one end of level to another even though theres little in view. FPSC in some instances calculates every poly and draws every object whether in view or not, whether segments or entities. i.e. sees around corners and calculates everything.
