Dont worry I am downloading the demo but I was wondering what the flesh/wall_impact efx looked like that you guys are using? If you could post some screenshots it would be nice. Depending on what thay look like I may need them for my mod.

Dont worry I am downloading the demo but I was wondering what the flesh/wall_impact efx looked like that you guys are using?
Go ahead use it and see for yourself, just remember to credit the team.

Originally posted by Salv
Go ahead use it and see for yourself, just remember to credit the team.
Ofcource I would most deffinatly give you guys the credit I just wanted to see if thay are what I want. See I have somone working on the same efx files and I dont want him to waist his time working on efx files that arent going to be used. And it wont be until next month that I finaly finish the huge download so it would be appreciated if you could maybe post some screenshots:)
Please:)

I dunno, it seemed like on Secbase I always heard the "heartbeat" sound effect whether the shots hit bodies or rock.

Only glancing shots seemed to make familiar sounds.

Btw, I really like the new "weapon clank" sound when blasters drops. Though it sounds like they're falling on metal. I guess you can only do so much with that. ; )

On an interesting note, I think the flesh/wall impact noise is causing the maps to crash in MP mode.

Still haven't totally isolated the problem, but it appears to crash whenever a shot is about to hit something.

interesting. If you have mapping skills, you could try to isolate it in a small test map, that would not take that long to load...

Actually, I'm just using one of the default JKA SP maps (which I know works in MP). I'm pretty sure is the impact sounds or effects since it crashes whenever sabers or blaster bolts impact something.

Does it crash with a blinking console error message or disappear totally from task list?
Hmm sounds like the wall hit uses a non-mp feature....

In JA, there are a few MP effects, but i doubt test_wall_impact is used...
Different weapons have different wall_impact.efx btw.

I think its not the efx itself since the same weapons run in SP as well as in MP.

I think it the compile process itself that puts different wall properties relating to SP or MP.

Let's try it with a simple SP compiled map, use it in MP to test. And then compile the same map in MP and test again.
How does this sound?

Well, according to my debugger, it's a read/write error inside the executable. Could mean a variety of issues.

However, I've tried completely pulling the effect and gfx files out of the .pk3 so I think it's the sound files since that's the only thing left of the impact effect replacements...at least that I know of.

As for the map, I'm pretty sure it's not the .bsp simply because the same crash occurs even when using one of Raven's SP maps.

Well, to think being "pretty sure" is not enough.
From my software debugging experience in know we must exactly know what's happening if we want to really eliminate the problem.

The wall_impact.efx is made of 3 parts (example: blaster)
- sound (sounds/weapons/blaster/hit_Wall.mp3)
- decal (gfx/damage/burnmap4)
- FxRunner (effects/blaster/sparks.efx)

Now sparks.efx itself contains:
- 2 lines (gfx/misc/spark and gfx/misc/spark4)
- Tail (gfx/misc/spark)
- again FxRunner (volumetric/black_smoke and volumetric/smoke)

And i'm talking about only the wall_hit related to the blaster...

As you see the EFX contains much more than a sound... mainly various GFX effects. But I guess i'm not telling you any new stuff, eh ;)

Did you remove step by step any of these to see what really causes the crash?
If you think its the sound, then try playing it alone inside MP engine.
Perhaps it might crash if the MP3 format is not supported.
BUt usually JA tells it instead of crashing.

You can't just exclude the BSP because it doesnt work with original JA BSPs... thats wrong logic i think.

SP-BSP most probably don't work in MP exactly because they have been mapped using different settings.
The compile process itself should be the same. But check Radiant... why are there two settings, one for SP and one for MP? There are many different entities... and most certainly the source code is also different, e.g. regarding surfaces tags etc.

MP is meant for fast fun gaming,
while SP is meant for better quality and atmosphere.

If it means we have to remove half of the shaders and effects to make SP maps run in MP, then its again a sad drawback
:(

I'm reading "read/write" issue... can your debugger tell you on which file? Or is there perhaps an empty string?
This might come from something that got removed from SP with respect to MP...

Unhandled exception at 0x00496711 in jamp.exe: 0xC0000005: Access violation reading location 0x46b9bd4c.

Not very useful without the executable code.

ouch. indeed real crash.
Did you try to compile the JAMP game DLL in debug mode and to debug it with JAMP ?
When the crash occurs, you might be able to see the previously called parts of the custom DLL.

That's what I've been doing.

It's an executable crash, so I can't see the crash point in anything other than disassembler, which is basically garbage.

On the other hand, I've isolated the crash issue to something inside the /models folder. Deleting this directory appears to put everything in the clear on the non-DF maps.

But this causes a crash on secbase (haven't tried the other maps yet) when you try to attack the Commandos since they now don't have a model to do ghoul2 traces on. Interesting.

Which maps use the Commandos?

Oh wait, I think I see the problem. You guys replaced the kyle model with a different .glm. The MP code uses kyle's model for all the hit detection by default so replacing the model will probably cause bookoo problems.

Trying now to see what will happen.

"This sounds interesting, except those sounds i've noticed."

The commandos are indeed used in Secbase already. But now you're saying that the Kyle model is not working properly?
*arrgh* Guess what, it's a JO model!
Because Hap/ has no JA and therefore cannot use JA tools correctly to build and test correct JA models...

Well, more specifically, it's the fact that the default kyle model is being replaced by this new kyle merc model.

Right now the MP engine is configed to use the kyle model to represent all of the player models on the server (for hit detection and such). My guess is that the modified model doesn't have the same surfaces, tags, or something that's resulting in something not existing when it should inside the MP executable.

All the crash issues disappear when you remove the modified kyle directory from the .pk3. To fix this issue, all that needs to be done is to change the model's directory structure so it doesn't override the default kyle model.

I have been chatting with Hap/ this morning, and in parallel i compared JO and JA Kyles. Only differences: JA has different Skeleton bone tree.
Hap will try to get the JO DF Kyle recompiled using JA skeleton.

That's not really nessicary as long as the directory name is changed. I'd recommend that the name is just changed to avoid all the possible issues with overwriting.

From what I can tell, the only thing that needs to be changed to adapt everything would be the autoexec.cfg and the .npc file for the dummy model used for cutscenes.

If we want a functioning JA mod, there is no other way, we need a proper JA model.

If you just change the directory, the model needs new skin names inside the model in order to prevent console errors.