You might want to try and get in touch with Tim "Waldo" Holt. He was experimenting with various game engines and procedural terrain generation to simulate large areas of forest based on geodata. I know he used Source at one point and had the same problem that you have - maps are too small - and he managed to get everything scaled down to compensate.
- Jed On 23 May 2011 01:02, Psy_Commando <psycomma...@gmail.com> wrote: > Hey thanks for the idea! I think I could work out some kind of hybrid map > system, so I can fallback on bsp. It might turn out a little complex, but > it's worth a try! > Hell, I could even code an in-game level editor.... > > On Sun, May 22, 2011 at 6:04 PM, Saul Rennison <saul.renni...@gmail.com> > wrote: >> >> Literally create a mesh via CreateMesh, populate is with your >> vertices, bind a texture to it then draw it. >> >> I'm not 100% how it works but it would be quite simple to adapt some >> DirectX heightmap code to use the materialsystem instead of direct API >> calls. >> >> Good luck! >> >> On Sunday, 22 May 2011, Psy_Commando <psycomma...@gmail.com> wrote: >> > 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 >> > >> > >> > >> > >> > ______ >> >> -- >> >> Thanks, >> - Saul >> >> _______________________________________________ >> 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
