Thanks, I may give it a try, but I checked his website about his forest fire simulator, but he seems to have gone for another engine completely. I think I should be able to do what I want with simply scaling down. At least, until I hit another wall. The completely new map system also sounds like an interesting challenge.
On Mon, May 23, 2011 at 6:07 AM, Jed <j...@wunderboy.org> wrote: > 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 > >
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
