eezstreet

Compatible, just move your assets over and you'll be fine.

jedi_random has an entirely hardcoded effect that's specific to that NPC.

It's an open source project, which means that they're going to release the binaries for general people to use. Everything in general needs to be fixed. This means merging the SP and MP modular renderers, and fixing general issues in JK2 mode.

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.

 Perhaps we're getting confused over terminology but thats the esseence of what appeals about manvis.

I wat'd

 

As for that CPU comment in post - yeah that saves only up to 5% and is already auto calculated. Thats not where the majority of the fps saving comes from, it comes from effectively blocking or causing areas not to be drawn which would otherwise have been using the q3map2 vis tracing. Is that a better way of putting it.

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.

 

And @@MoonDog...Um... not so much? Thats still creating portals automatically or with hint, which usually only works well in corridors or interior areas. Although Id take that scissoring and stuff over the current system.

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.

Somwhere in cg_draw.c/cg_draw.cpp in the sourcecode...

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.