Thanks, that sound like a possible alternative. But what do you mean, pass the mesh to the material system ?
On Sun, May 22, 2011 at 3:26 PM, Saul Rennison <saul.renni...@gmail.com>wrote: > 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 > > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
