This sounds odd. Why would the compilers refuse to accept a map that exceeds a limit. Usually it's the engine.
I don't know if it helps in this case, but you could give the -hilimit option a try. 

-hilimit is required for QBSP processing, or am I wrong ? 

Starkmon was already released, with exactly 2048 entities in it :)

But when I tried to run tyrlite with more entities in the map than that it threw out an "excessive entities" error and wouldnt run.....

Annoying at the time. Although it brings light (no pun intended) to the issue: with all of these expanded limit engines, coloured light can only be applied to maps with less that 2048 enitities..... 

hmap2 supports sunlight etc, AND colored lights.

The result looks noticeably different from bjp-light though. :-/

There's probably some command line option buried somewhere that makes it behave like tyrlite etc.

Coloured light / tyrlite is somewhat old, hence maybe the limit thing.

Hack the source to increase the numbers? Or try hmap2.

Or ask Willem to hack colored lighting into bjp-light. I really can't do it atm, my schedule is full. 

i'll ask. i tried hmap2 and tyrlite out but i can't believe the difference not having all the extra stuff aguirre added. it's like going back 5 years. :P 

Can't you just use aguirRe's tool for the lightmap data and independently from that Tyrlite for the .lit file?
Assuming you don't want colored sunlight. How does the delay 5 attenuation formula differ from the regular one? 

colored lighting is basically the difference. so it looks at the point in the map with whatever light level, then it subtracts from the lit the the amount stored there to give rgb, so if the lightmap data is different from the .lit lightmap data, you get garbage.

also, delay 5 is like delay 2 except the max light level never goes over the 'light' amount, so you don't get overlit areas that are completely saturated. it's basically an upgraded delay 2 

from tyrlite with a light data from light.exe results in a weird disco light effect, not good. 

i was looking at the vis source code from aguirre's vis.

in soundpvs.c, there's:
if (!Q_strncasecmp (miptex->name, "*water", 6))
Ambient[i] = NoAmbientWater ? -1 : AMBIENT_WATER;
else if (!Q_strncasecmp (miptex->name, "sky", 3))
Ambient[i] = NoAmbientSky ? -1 : AMBIENT_SKY;
else if (!Q_strncasecmp (miptex->name, "*slime", 6))
Ambient[i] = NoAmbientSlime ? -1 : AMBIENT_WATER; // AMBIENT_SLIME;
else if (!Q_strncasecmp (miptex->name, "*lava", 5))
Ambient[i] = NoAmbientLava ? -1 : AMBIENT_LAVA;
else if (!Q_strncasecmp (miptex->name, "*04water", 8))
Ambient[i] = NoAmbientWater ? -1 : AMBIENT_WATER;

you can see that slime gets assigned to AMBIENT_WATER, but it seems as though lava will be assigned AMBIENT_LAVA.
the thing is, it doesn't actually do anything.
i looked through fitzquake source code, but i wasn't able to find the spot that starts and stops the looping ambient sounds (wind and water) depending on where you are. does anyone know more about this? 

those four ambients (sky, water, slime, lava) are global sounds that play in the map, and vis calculates the appropriate volume to play each sound for each leafnode.

I don't have the engine source with me at the moment, but there will be client-side code in there that plays those sounds and adjusts the volumes based on the current leafnode. 

I was curious about some old files I have with quiet remarkable capeabilities. Fact is that I often tried to decompile the progs.dat of files with the
qcc.exe -dec
but then I received the error
Error opening defs.qc: No such file or directory (ENOENT)

Is there a way to translate these stuborn files? 

decompiling 

UnQCC ProQCC and FrikDec can. 

I ment proqcc but my hastiness cropped the text.
I used it to decompile the old Wilbur mod in which I succeeded.
Now I have the flamethrower.qc
Then I spend houres to subverse all the binairies in the Malice progs.dat to get the progs.scr which didn't worked. (of course)

Why did they messed up the progs.dat so bad?
I thought the licencewars nowadays were fairly obsolete?

o^o^o 

If I recall decompiling progs correctly: Their source code might have been good. But the decompiling cannot restore it in its glory. Thus the results from decompiling are not good.

It's almost like decompiling maps. 

I might be violating a GPL licence. 

Normal progs.dat is divided in parts like:
defs.qc blah ai.qc blah world.qc blah etc

Malice progs.dat is divided in parts like:
��&#9788;&#9835;* blah &#9689;��&#9786;&#9787; blah &#9658;&#9835;&#9668;�� blah >��#&< blah etc

so the decompiler immediatly stucks on the
can't decompile ��&#9788;&#9835;* part.

I thought to be clever to change these parts in the same text as in the normal quake progs.dat but this didn't worked (of course). 

And Spike's version? Even if there's not an official it's a cert he has one.

We can't compile RQ without fcqcc for the multi-frame and the other stuff. 

I don't know if FTEQCC can decompile. I do know that stuff compiled with it will usually not be able to be decompiled by other things.

MadFox: Yeah. Someone believed that it would make it impossible to decompile if they used a program to scramble the strings that were the filenames of the QuakeC files used to compile it. If you can hex-edit something meaningful into those parts of the file, then you should be able to do it. 

I don't know about Spike's version, where can I get it?
Should I check his site or email?

I tried FTEQCC, with no succes. And as I tried to fill in the hexidecimal parts I'm sure they're reiterated in the folowing hexidicimal part. As I'm not convenient with a binaire interpretator it's almost impossible for me. 

 

Hello again,

When I started my map in Bengt Jardrup's engine some items are not there. They were there in Dark Places. I use Worldcraft 1.6, by the way. I remember reading about this happening sometimes, but all related internet articles seem unfindable now. 

You placed them too close to brushes (walls probably). Move them away a few units and it should be fine. 

Of course walls, you can place stuff on the floor just fine. 

It's gonna be a damned puzzle making it alright though. Strange DP's doesn't mind. I had most of the weapons in cases. Oh well, I'll try something else then ...