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
