eezstreet

You'd have to do it through code.

If anyone wants to take a crack at doing some kind of AI for this, I suggest taking a look at how the ATST's pivoting mechanism works. Should give you the exact same effect as to what you're looking for. It could be rigged to replace the ATST if done properly, with the gun on top acting like the ATST's "head". The gun would have to be rigged to a "thoraic" bone (iirc).

Probably scared him off.

Yeah, I was like "wtf?"

I'd look into how modern engines handle vis. I believe they use volumes and buffer zones similar to how Doom 3 handles it. Vis shouldn't be a hassle, it should be automatically handled by the engine.

I wat'd Are you talking about CPU usage in q3map2 or ingame? I've read up on this fairly briefly, and MOH and JKA are essentially the same when it comes to the way it works ingame, it's the actual compiler itself that's different, as far as I can tell. The CPU usage you're referring to is probably the improved vis or whatever overall, and Manvis would not contribute to that at all, if you got the exact same groupings of tris to show up. Everything you've described so far sounds like it'd be better off being implemented on the compiler. No it isn't. It's portal-based vis, instead of vis based on Potentially Visible Sets. Furthermore, you contradicted yourself here by saying you'd "take scissoring and stuff over the current system", despite dismissing his suggestion as being the same as the current system.

or or or just use a portal based vis system instead of PVS, which is practically an antique these days. And yes, what mrwonko said. Vis is already calculated prior to runtime in the vis stage, and all the server has to do is figure out if they're in the same PVS. You still have to do this regardless of whether you're using manually defined vis or not, because it's the same exact data ergo, handled the same way. This is why I think its much more relevant to talk to q3map2 developers about this, since it's mostly their job to handle MANVIS. btw, if 85% of people can't vis properly, why would a change in vis help them? It'd only hurt them really, since most JK2/A oriented sites focus on "auto" vis, or the current vis system. Manusl vis also sounds more error prone and more usage of brushes/more time consuming in general for a mapper to use.

Probably can't find default.cfg

Its a long shot request, and since it really doesn't benefit anyone (especially since 85% of mappers can't even vis properly to begin with) and only in very severe circumstances, I'd say there's a slim chance of it getting implemented anyway. Ask q3map2 devs if they have it implemented, also.

CG_DrawHealth, CG_DrawAmmo, CG_DrawForce and CG_DrawArmor would be what you're after. Specifically, when there's a trap_R_SetColor / cgi_R_SetColor involved.

About 90% of those warnings are easily fixed also (unreferenced local variable u_u )

Err.. Do r_mode -1, and set the resolution using r_customwidth/r_customheight, then r_fullscreen 0, and finally a vid_restart. What happens?

Naw, go with spam or vienna sausages. Or if you're really money-starved, go with rice. Not cooked, obviously.

er..define horrible.

No idea, ask @@ensiform or @@Raz0r.

If it's any bit of reassurance, it's a simple matter of porting to all the correct platforms once it's converted from an MFC app to a Qt one. Even mobile, if you were so inclined.

Because it's irrelevant. jasp.exe runs JK2 as well as JKA now, provided you keep JKA assets away from JK2. Do "set com_jk2 1" on startup, and it'll run JK2 instead of JKA. The stuff in codeJK2/ is meant for jk2gamex86.dll, which is the JK2 equivalent of jagamex86.dll, and is more or less considered the equivalent of modcode. The JA solution includes the jk2gamex86 code and it compiles both jagamex86 and jk2gamex86 into the same folders.

MBII's is pretty shit though and consumes a lot of CPU to work properly, because it hashes every single file every time the game loads (including the assets in base... zzzz). I'd suggest something more akin to how a Git, Subversion, or Mercurial repository compares differences. I'm not totally sure of the performance difference there, but it would appear to judge based on last file modification date. Alternatively, one could take the JKG approach and distribute a launcher with the game that does the updating for them, albeit on a more stable host.

@@Syko: WTF, my previous post didn't come up. You need to install the Visual Studio 2010 Service Pack 1. You can get it here: http://www.microsoft.com/en-us/download/details.aspx?id=23691

Either way, it should be getting recompiled with Mac in mind very soon. I think @@Xycaleth is working on this as we speak.

ModView isn't available for mac yet, I don't think.

General Rules Please do not ask what is possible with the source, because anything is possible! If you have a question about the particular progress on a feature within OpenJK, please use that thread, and don't make a ton of topics. Warez/Pirated software is not allowed, nor is the discussion of it. This is a forum dedicated to coding, so let's keep it that way. Please use tags properly! Recommended Forks: http://github.com/Razish/OpenJK - General OpenJK [JKHub Topic] http://github.com/xycaleth/OpenJK - Rend2 Programs Needed/Advisable: Choose one from each category for optimal setup. Compiler/IDE: Windows: Visual Studio 2017 Community Edition (free download; preferred. Community Edition is the one you want, not Visual Studio Code!!), MingW (not recommended) Mac: XCode Linux: vim, emacs, or another editor; gcc to compile. Git: SourceTree (preferred): Download Here Github App: Windows / Mac / Eclipse Git CLI: Linux / Solaris / OpenBSD / Windows / Mac CMake Learn How to Code: General C++ TutorialGit TutorialHow to compile OpenJKOpenJK Wiki Common Issues These are categorized in "[Compiler/IDE] - Error" format To browse and report bugs for OpenJK that don't involve compiling specifically, visit this link. [Microsoft Visual C++ 2010] COFF file error [Windows/CMake] NSIS Error: Later versions of CMake have an issue with NSIS. If you are having issues compiling, try falling back to an older version of CMake, or comment out this line. Chat online with other coders via the JKCommunity Discord. (#coding channel) Legal OpenJK and the JA source release follow a GPL license. Here are some general things you should know before you dive into the engine code: You must be prepared to provide all source code. GPL requires that you give source code to anyone that asks you for it.The game is not free. You must still pay for the game in order to get access to the level files et al.You can use this to make a standalone. Please be aware that additional Star Wars license issues may arise.Standalone games may not contain original game assets, and likewise we cannot distribute any game assets with OpenJK that aren't cleared by Raven first. So far, the ext_data folder and patch assets (ie, the 4 new maps introduced by JK2 Patch 1.03) are allowed to be distributed, with the exception of ext_data/NPCs, ext_data/sabers, and ext_data/vehicles.If your game consists of modified assets, ie, a reskinned Kyle or whatever, you may not distribute the assets and the .exe together.Standalones can be for-pay, as long as they follow the general guidelines above and contain no Star Wars references. The details here are a bit murky however as this is mostly uncharted territory.You cannot rig SDK code up to work only with a modified engine. Doing so requires a conversion from the SDK license to the GPL, and therefore requires you to go open-source. Otherwise, you'd be breaking both the SDK license and the GPL.Raven and Activision are the sole entities which can prosecute for violations of the license, but you still may be shunned by the community!Disney is not legally obligated to defend anything other than the Star Wars license. This code is licensed by Raven Software and Activision.You are not allowed to use the original release code that was linked by Kotaku and others. This code contains Rad Game Tools code, as well as Feelit, Xbox Development Kit code and Carmack's Reverse. Using that code requires redistribution of your source code, which contains illegally relicensed code. I hear Microsoft has great lawyers.

Assuming it's a multiplayer TC, they can use the Auto Download feature as it is now exploit-free. Not really ideal. I'd suggest something like an updater for a JKHub API. An official API would need more backing than it currently has in order to get made.

Open up .sln. Hit Build Solution. That's pretty much all there is to it. Don't open the .sln in codeJK2/, use code/ or codenp/.