News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
Well 
i messed with it yesterday, but it doesn't seem to actually work.

-tyrlite95 works, that alone doesn't generate a .lit.
according to the tyrlite docs, you're right, you need -lit before it generates anything. unfortunately, -lit is an invalid command line arg for aguirre's light. :S

so it looks like it's either use the real tyrlite and make do without sunlight stuff and delay 5 lights, or colours. :P 
Necros 
Other solution is to ask aguirRe about his modified tyrlite light tool.... I'm using it actually... The only penalty is it does not support the second sunlight.. but is it really a problem ? 
JPL 
Modified Tyrlite light tool!?!?

I hit an "entities" limit (of 2048 I think) with the last map. Does the modified tool allow for more entities in the map (not light entities, but ALL entities)? I had to keep switching entities about just so I could light the map! lol . . . . 
RickyT23 
I clearly don't know: ask aguirRe directly 
Entity Limit 
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. 
AFAIK 
-hilimit is required for QBSP processing, or am I wrong ? 
Well There's Not Much Of A Problem Now: 
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. 
Thanks Jpl 
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 
Probably Silly Question 
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? 
Iirc 
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 
Mixin The Lit File 
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? 
Necros: 
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. 
Decompiling 
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? 
Right 
decompiling 
Original QCC Can't Decompile 
UnQCC ProQCC and FrikDec can. 
Well... 
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. 
On The Other Hand 
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). 
Mf 
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. 
Hmm... 
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. 
Digit Block 
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. 
Check Site First? 
 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.