that's cool! how'd you make that? 

It are free OBJ. files from Poison on Renderocity. Mighty objects there!
I just packed them up in Vue with a red fluid into a bright skybox.

http://www.renderosity.com/mod/bcs/cliff-demons-landscape-props-/60215 

could even be imported into a Quake 1 map by using q3map2 and a q3bsp supporting engine with reflective water (ie FTEQW).

Nice scene madfox. 

Does 8008 sign-on buffer exceeds 7998 affect how sound is played?

I have a triggered sound in one map that, if playing when the player dies, stops immediately and the death sound starts. Just right.

The same sound in a differnt map, with the same progs.dat, with the same trigger, does not stop and continues playing when the player dies and the death sound plays over the top.

To all intents and purposes, the scenario is fairly simmilar except that the entity and brush count in each map is different: the sign-on buffer error only happens in the second map.

Actually, the error count is quite high in the second map:-

* at game loading
- marksurfaces 33824
- 8008 sign-on buffer

*at map loading
- 64 lightmaps exceeds 64 (?)
- 1046 byte packet exceeds 1024
- 295 visedicts exceeds 256

* in game
- 602 edicts exceeds 600
- 33 blights exceeds 32
- 602 edicts exceeds 600


Any ideas?

(in FitzQ these errors do not affect gameplay so I am not minded to do anything about them. But the overwritten death sound error has nuisance value above the other errors) 

The signon buffer would only affect things when a map is loading. It's something to do with all the data being uploaded to the server for the first frame (monsters for example, which is why spawning them in delayed reduces the signon buffer).

More likely something else in your progs is doing it and it's a coincidence that it occurs in one map and not another or something else in that map is causing it. 

OK, thanks.

I think it's time to retire. 

... 

So I thought I'd see if the map ran in another engine and I tried Darkplaces. All brushes and all entities have outlines in-game. What's that all about? 

.obj can be used in Darkplaces at least like any other .bsp file in a q1bsp, eg using Quoth's map model entity.

Mike: Delete all configs, delete all mods, protect your sanity! 

I cant delete ALL mods as the map I am testing uses my own mod.

I can also see the entities bounding boxes as a fairly transparent grey box. Interestingly, I get no error messages at all.

As for saving my sanity: I fear it is too late Esmarelda, for the cows are now nesting in the trees, and the time is way past cloudy. 

r_showbboxes 0 

I'm working on an experiment to create a highly detailed somewhat large room. Not really a conventional map (no monsters). Now it's time to vis the map. I could call it finished without running vis.exe, obviously it will not benefit from vis. Problem is if I want to create a proper Quake level adding more areas vis will take days/weeks.
My question is to anyone who knows in innards of vis.exe. Could a version of vis be created with a way to flag an area as ignore. A bounding box around a room that tells vis don't calculate whats inside but calculate the box to the rest of the map.
I know how to use func_ as details and all the tricks like that. Too much func_ makes for crap lighting.
func_viscluster?
https://developer.valvesoftware.com/wiki/Func_viscluster 

No. 

 

We tried for a func_detail entity, and it worked. But functionally its the same as a func_wall. To keep shadows you can place floating blocks (that don�t touch anything else) inside the func_.

The big issue to overcome however is flickering entity. The RMQ engine has this. Basically, if a func_whatever crosses more than x visleafs thenit�ll flicker / dissapear as the player moves through different leafs, thinking that the object can no longer be seen.

If you saw the floating galley I did in one of the RMQ demos - that entire thing was func_. Although lighting did suffer because I didn�t add any shadow clipping blocks.

Vis blocking can solve lots of stuff as well. Bit busy, but try searching �doughnut corridor�. Adding switchbacks and doglegs should always speed up vis against a map with open corridors.

If you�re doing a void style thing as opposed to room-corridor-room then you�ll have to use other tricks, like sealing off rooms with sky brushes. 

ijed Thanks for the info. I do know the vis tricks. Had a thought of making the whole thing into a bsp model and using skip and clip, connect to other rooms with vis blocked halls. maybe....

If only func_ could do lighting. 

Receives light, but doesn't cast shadows. Its still possible to get decent looking stuff with it, but more likely to produce artefacts as well. 

will not be solid, while the q3map2 compiler can simply compile it into the map, including clipping. 

I made a map in radiant then used worldcraft to compile it, when I did it saved over the map in some crazy valve format that radiant can't read, is there any way to bring it back? 

Use TxQBSP to make the .map into a .bsp

Use WVis to do the vis process

Use Light to do the light. 

but how do I get the sucker back into worldcraft? 

 

it says it's saving it as a game map, when I open it in notepad++ data is formatted differently and when I open it in radiant it says it was expecting a # instead of a [ 

AFAIK - although I heard mention of a script that strips out the extra texture information that WC adds.

Essentially it adds a few numbers to every brush to describe extra texture information - which is how WC3.3 manages to have so many more controls for alignment.

Not familiar with Radiant but if it refuses to read a WC3.3 level then maybe another editor will allow you to convert it back. Beware though, since you could well lose all texture alignment using either a script or editor to bring it back. 

WC saves in Half-Life / Valve 220 format. Someone posted a converter program at quakeone.com once, but I don't remember who or when. It might have been Scrama...

http://scrama.3dn.ru/tmp/MapConverter.zip

I haven't tested it.

http://quakeone.com/forums/quake-help/servers-coding/3997-half-life-bsp-q1-8.html