<aguiRe> Great, now you'll just have to move the sun...

*Kinn is now also known as Apollo

<Kinn> Nah, I'll just alter the sky...

*Kinn is now also known as Jupiter 

My power fantasies come from rereading my Silver Surfer collection -- I'll add to my list of inspirations. 

but unfortunately I am more like Homer . . .

I'll add Kinn! to my list of inspirations  

Well, as you certainly noticed, I've released my latest map called CMC last saturday. I have a big problem in hard skill: suddenly during the game, a "No Free Edicts" error occurs. My quesion is: what is this fucking error, and how could I solve it ?? 

Nice one, distrans ^_~ 

aguirRe: that warning should be useful. I guess reducing the number of edicts present at startup would be the solution then?

JPLambert: No need to get stressed out. "No Free Edicts" just means you have too many entities in the level at a given moment. I believe if the number of edicts exceeds 600, then the game will exit with this error. The obvious way of solving this is to reduce the number of entities in your map. Of course, there are loads of edict-reducing QC changes you can make, but that might be a bit daunting if you're not into the whole QC thing. For example, in the original Quake progs.dat, items don't actually get removed from the level when you pick them up (this allows for deathmatch respawn, but in single player it is useless and can contribute to edict overflow). Making items remove themselves properly is a good start.

Another reasonably easy one (and something I make use of extensively in my Marcher map), reduces the need for multiple trigger relays, by giving triggers something akin to Half-Life style "multi-manager" type behaviour, with new fields .target1-5 and .delay1-5 . These work just like the normal target/delay combos and let me use a single entity to trigger up to 6 staggered events. It's an easy one to incorporate, because all you have to do is modify the SUB_UseTargets function to look for these new fields and take the appropriate action. 

Take a look in the file sv_main.c (found in glquakebjp.zip), function SV_CreateBaseline. In that function the server goes through the entities and creates a baseline which is sent to the client.

If the total size of this baseline is larger than 8k, normal engines will abort here. I've put my check at the end of this function. 

Maybe the easiest solution for you is to just add the progs.dat from earlier packs that just removes corpses? You'll then have to put your files in a separate dir beneath Quake (e.g. quake\cmc). 

Thank for your help.

aguirRe, as well, give me precious advices as you've just did by mail. I will try to update the map tonight, or tomorrow if I didn't found enough time. I really hope I will be lucky and find the good way to solve the problem quiclkly...
I already have some ideas about it, for example some flashing lights are not usefull, and can be removed... (some guys complains about it... so... why not...) As well for some health in hard skill... I can "win" some edicts.. aguirRe told me edict count was near 620 , so trying to reduce it of 30 will for sure help... and this time I will try it in hard to be sure it will works... ;)
So, thank you for your precious informations... As I said before, I'm pretty young in mapping, so I really need feedback and advices from all pros you are, in order to improve myself..
Thx 

I have just changed to use GTKRadiant for mapping, and i would like to know in what dir i should put my textures, and should they be .wad, . png or .tga and what not? 

Should go in Quake/id1/

I don't know about Q2, but Q3 should already be setup correctly if you've not changed the basic directory structure of the game. 

If you don't have GTKRadiant set specifically for Quake, then you will need to use that game as your base file. Earlier versions (personally I wont go near 1.5) did not have Quake I as an option so I keep it set up for Quake III Arena (1.3.11, and 1.4 for Quake 2 and Half-Life)with this file set up Quake III Arena --> BaseQ3 --->Textures ---> Metal (example set of textures), with the .wad textures unpacked and converted to JPEG's.

The versions of Radiant I use don't support .wad files natively except in the case of 1.4 which supports Half-Life wads in the Classic version.

When I am ready to compile the map, I use a seperate set up. AquiRe's tools plus a utility called mapconv which converts Quake2 & Quake3 maps to the quake format (trivial difference really, but they can cause a ton of headaches if not converted).

Two things to watch out for if you are using GTKRadiant. Don't use the mesh feature which is native only to the Quake3 engine and also be aware of the default texture settings. Quake uses a 0.5 ratio and Quake and Quake 2 use 1.0. Trust me on this ;) 

I have tried putting the wads in quake/id1/textures.wad but it looks for some textures dir and can't find it, I know that you can use older version and convert q3>q1 but is that better, to use an older version of GTKRadiant? and what version should i use then? 

If you use 1.5, you put the .wad file in Quake\id1, Earlier versions you must extract the textures from the .wad file as jpeg's to Quake\id1\textures\WHATEVER, you must extract them so as Radiant can use them, use TexMex (or whatever you want), to extract them from the .wad as jpeg's, plus you must also have a copy of the .wad file in the same directory as your .map file/compile tools for compiling.

As to what version, I use 1.4, others would have differing preferences from the 1.2.XX or 1.3.XX series. It takes a little bit of messing around to get it set up, nothing to painful though, and once set up correctly Quake will be selectable from the games selection menu at start up. You'll need a map converter to convert between Q3/Q map formats and some compile tools. I prefer to use Sleepwalkers mapconverter, the non java version, if you wanted that version and can't find it, I can send it to you, and aguirRe's compile tools. All you really need to know can be found at the link below. It really isn't as complicated as it may seem, and once you have it set up, you'll be laughing.

http://industri.sourceforge.net/howto.php 

at http://user.tninet.se/~xir870k . Main features are a new ShadowSense feature in Light, updated Win/GLQuake engines with support for up to 64k clipnodes and a new enhanced Nehahra engine. Please also see readmes for more details.

Any comments are welcome. 

Thx for the info Vorelord, but i have already set up to versions of GTKRadiant, one with 1.2.13 and one with 1.5, i got it working now, both of them, now i just got a new problem, if using curves and whatnot it creates something called patch in the map file, and the converter don't know what to do with this, nor does the map exporter in 1.5. So it just deletes the parts made as patch, is there someway to convert patch to brush? since the curve features is really the reason why i want to use radiant 

You are not going to get curve/patch geometry in a quake 1 map. Fundamentally impossible. 

Maybe I misunderstand something, but isn't having curves/patches/other q3 bsp features the main reason for q3 bsp support in engines like Darkplaces? You can have a q3 bsp be a q1 map, so why wouldn't it be able to have curves and whatnot? 

Yes yes. You're talking about q3 bsps, which of course will run in DarkPlaces.

I was under the impression that Zalon somehow wanted a way to get q3 curve information compiled into a q1 bsp, which as I stated before, is not possible. 

that will accurately decompile Q3 bsp meshes to brushes. I use bspc myself. You will probably want to convert these brushes to func_walls if you decide to do this as they add quite a few brushes to your count.

Personally, I believe it isn't necessary though. Pingu's curves never suffered due to the fact he was limited to the Quake1 format. 

The float/integer-problems has nearly driven me insane, so ^^
I trust in your map-experience: What editor shall I choose for quake1-maps? I know it's quite a general question and I don't want any kind of flame war! But maybe you could give me some advices. Thanks;) 

I prefer version 1.5 (beta) 

How can you 'accurately' convert patches to brushes? Assuming a patch is just a set of control points, which can have a varying level of detail (depending on the settings in the game engine)? Who decides what is the 'correct' number of subdivisions/polys/whatever to describe that curve with brushes? 

as in not distorted to an extent that is noticeable in game, and the brushes are not divided to the extent that they are overly simplified.

I have converted all of the original Q3 Arena maps using bspc and then converted over to Q1 maps for testing purposes, and it works fine without a hic-up. 

moving ones, like the expanding intestine like things in Q3DM4 do not translate well.