with 16 cores, just keep like 4 for you and the rest for vis. :P

well, unless it's used for cg rendering or something and let me tell you, 16 cores rendering would be pretty damn badass. 

 

are you could just make a script upload the file every few days along with it's .vis file to the same spot and you can keep checking to see when you have a complete map by starting the vis process up on your slow machine. 

there is a hard limit though. you can't build past +/- 8192. anything beyond that doesn't get displayed at all. in fitzquake, it looks like you have farclip on-- it's just cut off at that point and you see the void (or hom).

this behaviour is attributed to the fact that the coordinate system of the server runs on variables twice as large as that of the client.

this is not quite right. Both server and client use floats for their coordinate system, but the network protocol uses a special 13.3 fixed point format when sending coordinates. This means 13 bits devoted to the integer part of the number, and 3 bits devoted to the fractional part. So the precision is 1/8th of a quake unit, and the highest possible number is 4095.875 (lowest is -4096)

so when a client is rendering anything with coordinates that come from the server, it will never be outside that range. But the server side location and physics are actually working, just what you see is wrong.

The question of how far quake can draw world polygons should just be covered by the gl_farclip distance, which is configurable in some engines. Not sure if there are any other factors besides that. 

I made a google group because this forum is not very efficient, its only one thread. 

oh sorry. when we were talking about it before, it was a little complex so i guess i forgot some of it.

i'm not really sure what was happening regarding that 8192 hard limit, but that no matter what gl_farclip setting i set, i could never seen beyond, what i was guessing would be 8192 units away from the origin.
there was a solid cut off with just void at that point that didn't move at all. 

hmm, must be some other cause then, maybe the vis tool uses some distance limit? Does it show up with r_novis 1? 

Willem: Hm, I see. Don't want to cause you any trouble of course. I just want to finally get this thing out for good (and as soon as possible, not only in October). Maybe you could at least let it run during a lunch break for an hour or so to see how much progress it makes? I would then continue from there.

Spirit: Indeed, but I don't like the idea of leaving the computer on for such a long time when I'm not around. 

negke

Sure, email it to me or put it up somewhere I can download it. I'll run it overnight or something if you want... 

 

if anyone is still interested, my solution to my problem above with long vis times was simply to remove all the terrain into a seperate map. that map will only get a quick vis, leaving the left-overs of the original to get a full vis (which only took 20 hours vs 700-1200~, lol). 

What does that mean? Can you have separate maps like that for release, or is this just a way to let you iterate without killing yourself? 

I am confused about what you said.. Is it really possible to fastvis only one part of a map, and then fullvis the rest of the same map ? How do you do that ? 

Having a .bsp placed in the map as a model? 

sorry for the confusion, i just meant that i split the map up. the first portion has enough terrain to connect the interior areas, but i reworked gameplay such that the majority of the terrain could be removed and placed in a seperate map to be played linearily after the first.

terrain seems to be a serious vis killer. all those odd angles and varied planes really fucks the BSP process up resulting in thousands of extra portals or whatever. since the terrain section is mostly wide open anyway, and vising would have limited to no effect, that map will just be fast-vised. 

i would be incredibly bad-ass if you could, for example, modify qbsp so that if you cover an area with a 'fastvis' textured brush, any portals (or whatever they are) that are touching that brush are ignored in the full-vis process. :P 

Maybe placing bsp's as entities could work. How it'd not get screwed by vis (flickering entities) would probably depend on dividing it up into chunks with some trial and error though. 

lighting something like that would be a nightmare though. :S 

depends on the engine i guess. with a shiny swiss army tool like darkplaces it should work fine. for some fun copy some map to progs/player.mdl and do chase_active 1 plus chase_back 3000 (or something like that). a piece of cake for dp.

proper lighting (for the "external" objects "in" the terrain map) would hard though,yeah 

Where can I find a suitable add new weapon qc?
I searched at Inside3D but all there is are modified already ingame weapons. 

It's just a matter of finding the right tutorial:

http://www.inside3d.com/showtutorial.php?id=60

This one is about adding new weapons. You do have to pay attention to some of the slight cheats they have to use. One is that rather than setting up a new key to press for the weapon, they make it so that pressing 2 twice brings it up. They also don't make a new entity in the map for it, which is something I expect you'd do if you're making a custom map. 

Building http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/qeu03.zip on modern Linux is easy, just remove the lines containing the del and coff2exe references.

And now I'll continue the search for a commandline mip2saneimageformat tool. Could not get MIP2BMP.EXE from http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/qmaphack11.zip to work with Dosbox. 

Niels Froehling's QuakeTools-library would be an epiphany but compiling is just not possible without a tremendous amount of work I guess. http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/qtools0.3-src.zip 

the right tutorial indeed, but after covering all errors I just keep
drawing 2 untill I too error.
Seems as if replacing v_shot.mdl is an easier way for testing.

Strange to conclude these tuts are so wicked in error messages.
Although they added my EathQuake. 

i've been trying something new. essentially, working only from the top view, i'll drag out brushes 32 units high of varying width and length creating floors. i create a significant portion of the map at a time in this manner and i specifically try *not* to pay much attention to the size of those floors, other than keeping them on a 32x32 grid for texture alignment purposes.
i'll make the decision that, say, a generic hallway is 192 units wide, but everything else goes. a room can be any dimension (and any combination of brushes to create the final shape).
after doing this, in a side view, i'll semi-randomly move connected sections of floor up or down up to 256 units (in either direction).

this can lead to some pretty weird and convoluted shapes with that sort of 'tumor growth' mapping look.