If all you want is massive extending terrain then: You could make your own terrain, and pass the mesh directly to the materialsystem and then your co-ordinates would only be bound by float limits. Also, you can make your own physics collision mesh by creating a polysoup (see the VPhysics interfaces).
In effect, it'd be a custom displacement system. No idea how you'd get this to work in Hammer. Thanks, - Saul On 22 May 2011 19:55, Psy_Commando <psycomma...@gmail.com> wrote: > Thanks, for the answer, but we are already using this solution. The main > problem with it is that the collision mesh gets horribly mangled by the > model compiler. > > Now that I think about it, I guess we could split the model into smaller > convex chunks. However, I don't know if it would be a pain to animate and > properly assign bones? > > And there's also the issue that in multiplayer games, coordinates are > limited to 3 digits precision after the decimal point, so anything more > precise than 0.001f would get floored. I'm not sure what would be the > immediate effects of this though, with the client interpolation... > > It's such an irritating problem, it would probably take me less than a day > to patch, if I had access to the code that loads the bsp and build the map > mesh... I even investigated where it didn't work, comparing the debug > messages and the old leaked beta code. I could have probably bypassed the > current engine code and replaced it with some code from the leaked beta > engine, but I can't use that stuff because it's illegal! :( > > > On Sat, May 21, 2011 at 11:26 PM, Skillet <skillet5...@gmail.com> wrote: > >> The solution that Empires and Eternal Silence used (AFAIK) is to shrink >> down everything including the player so that the effective map size is >> increased. Relatively simple idea and seems to have worked well... >> >> On Thu, May 19, 2011 at 4:25 PM, Psy_Commando <psycomma...@gmail.com>wrote: >> >>> Hi. I know nobody was able to actually change the hard coded map size, >>> but I gave a try anyways. >>> And as expected it didn't work. >>> Hammer don't want to load.vmf with solids further away than 16384 units >>> from origin. And that's hard-coded in hammer, since setting @mapsize(-32768, >>> 32768) in the "base.fgd", won't change anything, except the grid size in the >>> map editor. >>> >>> And even when tweaking the datatype of bounds in vbsp, vrad, and vvis, >>> just resulted in the engine dll crashing on load with a "funny lump size" >>> error. Because I guess, the lump size are constants in a shared header. >>> >>> So I got two questions: >>> >>> Has anybody tried to contact valve about that, or play around with that ? >>> Because we have the source for all bsp stuff, but we can't make lumps >>> bigger or smaller, because the code that loads the actual bsp is >>> uncooperative, and inside the engine dll. If they could query a couple of >>> constants via the server dll interface for various lump sizes, or map bounds >>> typedef, that would be much appreciated. >>> >>> Any idea or suggestions on how to make a space shooter with the source >>> engine ? >>> We're using corridors with teleports at the end of each to take the ship >>> to the next corridor. >>> There also the make the world move around the ship approach, but we cant >>> move displacements with collision... >>> >>> Any comments or advices are welcome. >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
