thks headthrump!

o mundo sorrindo

(all the Portuguese I know, and I learned it from a ringtone) 

Hey, yeah, this is neat! I never played with QuakeC back in the day - this opens up a new world of level editing! Heh.

I made my mover class that I wanted and it was pretty painless! This is going to be fun. 

You should do me a progs.dat with blood splats (zombie gibs which follow the tradjectory of bullet impacts with all enemies, stick to walls and slowly slide down).

That was my favourite once upon a time, but I cant find it anywhere and I'm allergic to programming :D

Apparently its dead simple... 

I saw that tutorial over on inside3d. All you have to do is type into a text editor. Get on it. :) 

...my ideal mod would basically be Quoth, with the above mentioned effect, and three increment painskins on most enemies except really weak ones (dog, fish, voreling)

I may have to start tinkering around with QC. No - wait - eyes growing redder, windpipe - tightening, skin - breaking out in - rash, nausia increasing... (*passes out from severe allergic reaction*) (*gone into anaphalactic shock*) 

Willem can you please email me the source code for your multithread vis and light? I am trying to get multithreading to work for linux vis and light tools and a working version would be helpful.

drofmij -AT- gmail -DOT- com 

Sure, I'll do it tonight. 

That would be cool. I want it. Where do I find Win32 exe?

(Is it as stable as AguirRe's?) 

Yep, the latest version of ToeTag includes a multithreaded version of VIS but it's only going to work on Mac OSX. The code was pretty easy to hook up in all honesty - it was mostly a matter of incorrect function names and a few small changes here and there. If anyone wants my source code for that you can grab it here:

http://www.wantonhubris.com/SrcForJim/

That's the source code for the original id tools that I based mine on, and the multithreaded versions of LIGHT and VIS that I did. I don't know what's involved in making it Win32 happy, but I know that jimbo is working on a Linux version. 

Sound very exciting!!

Unfortunately, I feel the usual symptoms of a severe programming allergy starting to creep in!

There must me someone out there who is interested in making a win32 exe!!

If not, Q1 mapping in OSX seems even more attractive.
:D 

Well, I've done what I can. :) There's the source and I assure whoever looks at it that the multithreading in there works on OSX. It shouldn't be a huge hassle for someone to port it to Win32 unless multithreading on Windows is a complete nightmare. In which, you have my condolences. 

http://img265.imageshack.us/img265/635/texturesfr5.png
??? 

Hello, been lurking here for a while finally got time in RL to fart around with mapping and Ive started using BSP & that nice WC3.3 conversion. I like BSP better but it doesnt seem to remember what textures you put on prefabs. Ive been using the "Save Brush" feature I figured this was BSP's "Prefab Factory" equivalent. If there is something else or if anyone knows wether or not BSP will actually save tex info on prefabs please, please fill me in. I have been unable to find anything referencing this in the docs or in the cfgs.

Thanks in advance!

Fatty 

The texture information is saved with the .bru file. However, if you then open that 'prefab' in a map whose pre-defined texture file (as defined in "worldspawn") does not contain the prefab's texture, BspEditor has nowhere to get the texture from.

If that helps... 

OK, I need some pointers here.

I'm working on a turtlemap which is like 80% done (no roofs and no monsters yet.)

My central area (a 1024x1024 atrium) shares the same sky with the surrounding corridors and rooms, because the roof construction is only made of a steel skeleton (no "shingles".) I'd like to keep sky visible and use sunlight.

So basically this is like a 1600x1600 area divided by some walls, and doors, and eventually probably inhabited by ~ 100 monsters - nothing more. Think Doom map with ceilings ripped open and 4 times the size.

How badly will something like this affect r_speeds?

Also, what kind of stuff apart from torches counts toward the static entity limit? ^^ I have a bad feeling there, too. This might combine into a gigantic mess.

It was my beginning concept though, large atrium surrounded by wide corridors with holding cells. Maybe this was faulty already, most maps have interlocking corridors and only peripheral outdoor areas.

It looked good on paper. Sigh. :-/ It's almost finished though, so we'll soon see anyway... maybe it'll serve as an example to others... :-/ 

Compile it and see if it runs in FitzQuake. Give it a full vis, and then when in FitzQuake type "r_showtris 1", to look at the mesh.

My visblocking is piss-poor at the best of times, but I know enough to know that you can get away with quite a lot when using a good glquake engine! IMHO. ..

As for there being about 100 monsters - this isnt too many for Quake by any means, so I wouldnt worry about that!

Try and block as many of the cielings off from eachother, think "If I put a sky-brush here, blocking this other part from view, will the player *really* be able to tell the difference, if they arent noclipping/flying around the map?". 'Vis-blocking' in this way will keep r_speeds down.

Try running the map in standard GlQuake or even software WinQuake, the original Quake executables. If it runs in them, I would say that its a reasonable statement that it will be fine in all other engines!!

Others will know better than me! ;-P 

...100 monsters on the screen at once wont be healthy for Quake. AguirRes engine, yess, other engines, probably not....

...but who's crazy enough to put 100 monsters on the screen ALL AT THE SAME TIME?!?!? 

Basically what Ricky says - closing off the various sections into rooms that don't look like rooms because their ceilings are sky brushes - the player just assumes its all open space and not completely boxed in.

I mean using 'invisible' sky brushes with a skybox, basically. It works even if you have a pointed roof - put a wedge coming down from the topmost skybrush that meets its top edge. You have to find the best way to fake the visual effect.

Static entities are decorative objects - crucified zombies, func_illusionaries, flames, torches, light globes etc. But not lights, there's a few other exceptions as well.

The map is outdoor, as in lots of triangular faces? In a way that's easier to solve from a vis point of view (even if it's more work) in that you can just throw a dog-leg into a corridor that'll break up LOS more - in a brick or metal corridor you have to do more thinking, although wall pillars and corners help. 

All the time, if it's less than 300 in view it looks desolated ... or limited by something ... 

 

If the walls are high enough (while the player always stays down on the floor) and the rest is sufficiently visblocked, having only 'one sky' shouldn't be much of a problem. Vis time will be longer than with smaller sky units though.

Are crucified zombies static objects as well? I don't think so. 

I managed to killtarget them in Nehahra, which should mean they're not, but I've heard alot of coders saying they are.

Another question would be does this apply to spawned models that don't necessarily have animation - Nehahra misc_objects, Quoth corpses and ID hacked bmodels.

I've never managed to decompile the QC and wouldn't know what it meant at first sight anyway. 

...but the Quoth corpses, erm, I can tell you one thing: if you noclip outside of a map, you can still see the corpses (certainly in FitzQuake), whereas you cant see monsters/doors etc.

Hope this helps! 

obviously Quoth corpses are static entities... 

It's actually a bit more involved than that. The lynched and crucified corpses are static entities in quoth, and the flayed ones are dynamic - although the tutorial says all of them are dynamic. Changing them now would be a bad move for quoth2, as it might break existing maps by leaving them with too many static entities, or too many dynamic ones! So instead we now offer two spawnflags on such mapobjects. Spawnflag 1 will make them static, and spawnflag 2 dynamic. This allows you to balance your load of dynamic and static entities as you need to. It also extends to things like torches and flames.