eezstreet

What mod is the server running?

We already addressed it. The use of # in shaders is: - Not supported in other similar projects for similar games (OJK is the ioq3 of JA, despite what certain people think) - Not mentioned in the Q3E shader manual - Not used by any base shaders So why would an undocumented, unintentional 'feature' be promoted as something we should allow, even though it might cause issues in the base game? It's a little ridiculous that we have to cave to support something totally asinine like this. Why don't we make text in ~~s be comments too? It worked in base. (...actually that's totally ironic because it might have.)

Here's a thought: keep it simple and tell us what you want to start on. If anyone else is like me, they likely aren't going to read that behemoth of a post. Tell us the first thing you want to work on, and keep it short and to-the-point. Now I understand that you want some feedback on your game mechanics. My feedback: - The idea of making weapons damage different enemies is cool, but be sure to include a variety of enemies. The biggest problem with games that do this is that then people are encouraged to use only one enemy because of the weapons. Furthermore, all weapons should be usable, but require different ways to kill enemies. - I have no idea what you mean by this. Elaborate. - Again, no idea what you mean by this. - ok? - Yup. Mind Trick is pretty cool. As far as random is concerned, there's no specific way to set things based on random, but you could use a target_random pointed at different target_scriptrunners.

This is due to his use of # in comments. // and /* */ are to be used exclusively, and while # is supported in base due to bugged behavior (it still remains unknown how it worked before without causing problems. This comment style is not supported in ioquake3 at all), this behavior is deprecated in OpenJK and not supported. It is up to him to fix his maps. If we support it, then that means that we will be supporting maps with undefined behavior in base, which might result in all kinds of wacky behavior... I'm surprised his maps haven't caused crashes or worse yet. Furthermore, we've attempted to engage in dialogue prior to this and he hasn't responded. So our response is: no, we aren't supporting the maps, it's his responsibility to fix them.

Spawn script, probably, if you have one.

I'm not a mapper.

Hmm. Has it ever crossed anyone's mind to use the G2API functions (the ragdoll ones in particular) to simulate cloth physics? (@@Xycaleth/@@Raz0r)

Maybe your problem lies in the .npc file. Try setting hfov/vfov to higher values (if they're set at all). Same for "earshot".

I'm a little curious as to why. Does it crash on startup, or?

Enter those cvars into MP and your questions will be answered.

BLOTH PYSCUCS OMGERD!!

Using the Github app, it's a simple process: - Make a fork of OpenJK on Github - In the Github App, clone the fork - Make changes to the code - Commit the code to your fork (github app -> hit arrow on your fork, select files and push to repository) - Make a pull request on JACoders/OpenJK

All of the above. SP is actually already up and working so far as I know.

They appear to be loaded like misc_model_static. Adding gi.linkentity to it makes sense as to why it would fix it. I'd like to mess around with it but I don't have the time or the willpower to do so.

Also that "moment where you focus on one thing" = Depth of Field, just an FYI.

+ trip mines on defending team make it damn near impossible

or use a different lipsyncing algo first ;/

The bloom looks okay in the first picture. Needs less saturation. inb4 Xycaleth fixes rend2 EDIT: Wait, this is worded pretty badly.. You should um...cite your sources...or reword this so it sounds like you didn't make this yourself.

There's a mod for that.

Yup. The same happens with misc_model. You can completely ignore these leaks so far as I know.

I think everyone forgot the biggest co-op SW game...Republic Commando. Some missions in OJP don't work or are unable to be progressed. I think you could get up to like vjun2 before it fails?

Or, "we're very careful due to our extensive background in software development" (read: "we're too chicken to touch the code and everyone else sucks, so yeah")

If what AshuraDX says is correct, then it's likely that you just have too much junk being rendered, or too long of a life. Heres some math for you. Suppose we have an efx file. In it, we have a simple spark effect that shoots out 6-10 sparks, with a life of 1200 for each. since the blade effect gets rendered _almost every frame_, that right there is 6-10 tris. Now suppose our client has 90 FPS. That means you're rendering 540-900 tris at any given point in time. For point of reference, the Galak model has around 1.2k tris. With more than one saber onscreen, it becomes obvious why there's issues.

Teamless player is caused by the same thing as it is in MB2. There's entirely too much data being shoved into configstrings that really doesn't belong there for the sake of siege. (For instance...why do we need to know a players model or force config? Both of those are easily available from the client, given a class index?)

You're probably using way too many tris/polygons. The effect gets repeated for each glow chunk of the saber I believe. Try it out with 1 particle, 200ms life and a simple white shader. Note how many times the effect gets repeated.