You can tweak the various datatables and/or proxies to change the
precision limit.
On 22/05/2011 7:55, Psy_Commando 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
<mailto: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 <mailto: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
