ensiform

Of course that's true. I never denied that. You'd most likely lose out on compatibility in some way or another though.

Mostly cause there's more activity in #JACoders

MP only allows you to use the original humanoid for players.

FWIW [shot] would be preferable to using spoiler but I guess this board software doesn't support it.

Until its packaged correctly and set to upload it waits.

Okay so I have permission with map source file to port the Q3A Custom CTF map, "Moonstone". And I have started some work on getting it into JKA but I'm not really an expert mapper by any stretch. Particularly in the lighting and item balance placement. Currently I think some items are placed just as 1:1 from Q3 to JKA semi-equivalent. http://lvlworld.com/media/moonstone The map was designed for Q3 so, it takes liberties in the lighting because Q3 uses the overbrightbits and map overbright bits options which makes maps brighter overall and JKA doesn't. I would say just brighter enough that people can see well while playing. So it doesn't have to be perfectly same as the Q3 version. I can give out what I have in PM or something if anyone is interested.

Imagine how much of a pain it would be to integrate and it would not work with a vanilla OpenJK, you'd be making your own engine+mod at that point. --------------------------------------------------- Please return to rd-rend2 discussion.

I think there is supposed to be somewhat of a time lapse between missions. Hard to say though because of the Rosh going missing bit. How long would they "wait" to go rescue him.

This sounds similar to what can happen when you delete a custom player model that was referenced by a save file in SP in debug mode.

All the NPC files are loaded into a buffer, so its possible. Especially in the regular sp/mp engines.

You only need the assets from Steam. OpenJK will still work if Steam is offline.

Cleaned up saberload parsing code in SP to match what was changed in MP by us. Might be a bit faster on parsing than before due to hash table lookup.

Tweaked the setForce* cmds so they display correct limits for all and descriptions for the JKA added powers. setForceAll <no args> looks like this:

That's a fontdat problem.

Increased max number of shader files allowed in SP to match that of MP. (1024->4096)

Buy an external optical drive then. Probably like $20.

No, he has a Core i3 with Intel HD 3000

I don't know what the bugs still are if many off hand. We were just not really focusing on Jedi Outcast for the longest time it was kinda "Use at your own risk". Now that we separated it to its own exe/renderer (openjo_sp/rdjosp-vanilla) and fixed some of the visual problems I think its mostly better. Possibly some issues on the other platforms still, but I'm not positive on that. I do know there are some things plaguing both games such as random NaN assert issues pertaining to impact marks among other things. Saves don't work cross 64/32. Memory leaking in save/load IIRC, can't reproduce it right now though. Also, the UI code in SP is essentially all JASP's code. So there are definitely some issues when running on JO game. And things like UI includes the JASP weapon headers, but the jk2game uses its own etc. We'd love to have it done, we just weren't intending to include it in the first release hence why it does not get built with buildbot. Feel free to chat with some of the regular maintainers on the IRC channel and maybe we can give you write access

Doesn't sound like its the game then.

Yea these are totally graphics intensive ...not Without knowing whats going on on your PC its going to be hard to determine if it's even the game or something wrong on your system at this point. :/

In a good way. Its just fixing stuff in the engine portion.

@@Didz I don't really notice much of a difference with the OJK gamecode and at my resolution settings. (r_mode -1, r_customWidth 1440, r_customHeight 900, r_fullscreen 0) Monitor is 1680x1050. Spacing looks a bit better I guess.

WE_IsOutside isn't available to cgame. I still don't see this being easily feasible. You can't run the mover code from cgame, which seems to be used. And I'm not sure if ICARUS interacts with them at all. And I don't know how you will get the origin information from the bmodel data in cgame either.

I'm looking for some coders who would want to help investigate and work on trying to bring the g_rail.cpp (t1_rail) flyby stuff to MP. It'll likely require moving to the cgame module and adding some new functions to the cgame's import tables though.