Base JKA Source Files (decompiled)

Amazing job. the best way for learn how maps and how jka works is to study original maps.

Light will not be decompiled too. =(

7 hours ago, Laisum said:

Light will not be decompiled too. =(

Unfortunately I'm not sure if there's anything I can do about that. If I can find better ways to decompile the .maps I'll be sure to update these.

15 hours ago, JesseHumphry said:

Unfortunately I'm not sure if there's anything I can do about that. If I can find better ways to decompile the .maps I'll be sure to update these.

Sadly lights never be decompiles and get ever losted alls. textures lots their alignments.

misc_models are losted too, they become structural brushes.

Again i not way a better way to decompile BSP.

13 hours ago, Asgarath83 said:

Sadly lights never be decompiles and get ever losted alls. textures lots their alignments.

misc_models are losted too, they become structural brushes.

Again i not way a better way to decompile BSP.

SOME textures lose their alignments. I decompiled with map_bp and it keeps the alignments in some cases. You'll need to have UV lock on in NRC if you use anything though. 

20 hours ago, JesseHumphry said:

SOME textures lose their alignments. I decompiled with map_bp and it keeps the alignments in some cases. You'll need to have UV lock on in NRC if you use anything though. 

Interesting. i didn't knew that uv lock can preserve from this issue.

thanks man! :)

On 11/24/2021 at 11:42 AM, Asgarath83 said:

Sadly lights never be decompiles and get ever losted alls. textures lots their alignments.

misc_models are losted too, they become structural brushes.

Texture allignment is much less of an issue when decompiling with current q3map2 from NetRadiant Custom - misc_models are not lost, the point entity will be where it should be - it's just when the mappers didn't include the md3's you'd have to extract those in another manner - such as the blender bsp importer route and make .md3s out of them again.

11 hours ago, mjt said:

Texture allignment is much less of an issue when decompiling with current q3map2 from NetRadiant Custom - misc_models are not lost, the point entity will be where it should be - it's just when the mappers didn't include the md3's you'd have to extract those in another manner - such as the blender bsp importer route and make .md3s out of them again.

Lights are preserved too?!?!!? O_O "

7 hours ago, Asgarath83 said:

Lights are preserved too?!?!!? O_O "

The lights included in the .bsp are decompiled too - if the mapper compiled with _keeplights 1 - if not, like most ravens JKA maps, you don't get the lights back

Cool. i should remember to use _keeplights on my projects. thanks.

3 hours ago, Asgarath83 said:

Cool. i should remember to use _keeplights on my projects. thanks.

You could just include the source file instead, though, to remove the need to decompile. No point in using keeplights if the source file is intact. 

22 hours ago, JesseHumphry said:

You could just include the source file instead, though, to remove the need to decompile. No point in using keeplights if the source file is intact. 

Yes, that's make sense.

If you were to lightmap your map in blender instead of q3map2 - using _keeplights 1 still spares you an extra import of a file with just the lights compiled into it. The keeplights stuff doesn't affect ingame entity count as far as I'm concerned and thus the few KB extra per .bsp really are worth the effort - especially if sourcefiles and compiled files magically get separated by whatever circumstances.

On 11/26/2021 at 9:30 PM, mjt said:

The lights included in the .bsp are decompiled too - if the mapper compiled with _keeplights 1 - if not, like most ravens JKA maps, you don't get the lights back

I came just to say this; the thing about lights is that when you compile (not decompile), you can decide to keep the lights as dummy entity data with -keeplights, most base maps were compiled this way, I learned a lot about how to properly do lights by looking at lights key/value data from single player maps, there you can see the little tricks to make illumination work in many different ways.

  

On 11/29/2021 at 9:45 PM, mjt said:

The keeplights stuff doesn't affect ingame entity count as far as I'm concerned and thus the few KB extra per .bsp really are worth the effort

You are correct, they are saved as entities but the engine pretty much ignores them. I do believe tho, that they're needed for SP maps for the NPC "senses" since there is code around light level regarding NPC AI.

Edit; got it, it's unfinished code (funny comment right there) so yeah, the engine pretty much ignores light data:
 

float G_GetLightLevel( vec3_t pos, vec3_t fromDir )
{
	/*
	vec3_t	ambient={0}, directed, lightDir;
	cgi_R_GetLighting( pos, ambient, directed, lightDir );
	lightLevel = VectorLength( ambient ) + (VectorLength( directed )*DotProduct( lightDir, fromDir ));
	*/
	float	lightLevel;
	//rwwFIXMEFIXME: ...this is evil. We can possibly read from the server BSP data, or load the lightmap along
	//with collision data and whatnot, but is it worth it?
	lightLevel = 255;

	return lightLevel;
}

My theory about why they compiled most SP maps with -keeplights is that maybe they had in the design phase to actually have some sort of hide mechanic so you could hide in the dark, who knows?

On 1/17/2022 at 9:24 PM, CansecoDev said:

Edit; got it, it's unfinished code (funny comment right there) so yeah, the engine pretty much ignores light data:
 

float G_GetLightLevel( vec3_t pos, vec3_t fromDir )
{
	/*
	vec3_t	ambient={0}, directed, lightDir;
	cgi_R_GetLighting( pos, ambient, directed, lightDir );
	lightLevel = VectorLength( ambient ) + (VectorLength( directed )*DotProduct( lightDir, fromDir ));
	*/
	float	lightLevel;
	//rwwFIXMEFIXME: ...this is evil. We can possibly read from the server BSP data, or load the lightmap along
	//with collision data and whatnot, but is it worth it?
	lightLevel = 255;

	return lightLevel;
}

My theory about why they compiled most SP maps with -keeplights is that maybe they had in the design phase to actually have some sort of hide mechanic so you could hide in the dark, who knows?

Good catch on the lightgrid data being intended to be used. I think this feature could actually still be imlemented without too high a cost... It doesn't really need lightmap data, just the lightgrid, and also no light entities. That'd be overkill to calculate from - and also the lightgrid can include indirect light, bounced around. It'd make more sense to use that for visibility checks.

Download not working?

nvm it is!!!!!!!! thanks for making this