Xycaleth

Sure, it was general advice. Raz0r's post should fix the problem?

You could always try it out one thing you would need to do is to make sure you use a misc_model and not a misc_model_static, otherwise I don't think a lightmap would be created for the model.

To be honest, said "hacker" is probably nothing more than some kid who has nothing better to do and thinking he's "leet" by running one of probably numerous getstatus flood scripts circulating around the interwebs. If I were you, I'd send a report to his ISP (though from the information you've given, I don't see how you could know who this is) as a warning as he will probably continue attacking other servers anyway.

Does the bumpmapping effect only work on patches? Or does it work with brushes as well?

Generally you should wrap the source file in namespace DisplayContext { } as well like you do in the header file. It's not common (and therefore confusing) to define namespaced functions like you do there.

In simple terms it's exactly the same as a lightsaber works. You have a model attached to the player, and the saber damages anything that touches it when you're swinging it. The same can be applied to the whip, so the whole model does damage. The difficulty with a whip is it needs to be animated as well, which the code doesn't support. In an ideal world the whip wouldn't even be animated and would bend/flex using some basic physics system but that would be some way in the future

I think @@mrwonko made a Jka game pack for gtkradiant 1.6. Or it might have been TheOneAndOnly.

I've made a start on this and was happy to find that the FBX SDK is relatively easy to work with. Using @@DT85's FBX file I've been able to establish the surface hierarchy and extract the mesh data. Should be about a full day's work to get a basic converter working Now I just need to find the time.

The types of calculations you need for collision detection against detailed models would give a noticeable performance hit. This is why even modem games use a simplified mesh for collision detection.

Toshi's Luke would be good, thanks Can you throw in a simple animation with that as well please? Not sure what versions it would support just yet but if Archangel is right about converting between version, then it shouldn't matter which version I target

Awesome. Well I'll see when I can get started on this. If someone can provide me with a basic model (something like a map object) in FBX format then that would help me a lot I'll keep this topic updated with my progress!

Yep, if enough people are interested then I'll try developing one

What is it? The FBX to GLM converter will be able to convert the FBX model format to Raven's GLM and GLA formats. FBX is one of the most widely exportable formats from all major modeling programs, and it makes sense to be able to support this format to reach out to as many modelers as possible. In addition, FBX can be converted on the three major operating systems (Window, Linux and Mac), so this can further increase the number of people who can use it! Download link: https://dl.dropboxusercontent.com/u/874909/fbx2ghoul2.zip Linux and Mac binaries can be created on request! This is what it DOES do: Converts FBX file to GLM. Supports LODs. Supports static meshes. Animations using existing GLA files. DOES NOT: Export custom skeletons Road Map Here's a rough outline of what I plan to do, and in which release/milestone it will be finished in. Milestone 1 - Converts non-animated models to GLM. Milestone 2 - Converts animated-models to GLM. Milestone 3 - Converts animations to GLA. Milestone 4+ - Experimental optimizations of vertex data to potentially improve rendering performance. Also look into reducing animation jitter. Original Post: Aloha. I wanted to gauge how many modellers would be interested in an FBX to GLM converter (and potentially back again)? FBX is one of the most widespread interchange formats for models so all modeling programs should be able to produce FBX files. Autodesk provides a software development kit for the 3 major operating systems and so it is ideal for making a cross platform converter. The dotXSI dev kit is only available for Windows which makes it much harder to make a cross platform solution. Obviously this could (easily?) be extended to produce GLA files as well.

ModView doesn't support loading of MD3 files as far as I know so you would need to add support for that first. Regarding memory usage for vertex animations compared to skeletal, skeletal animation uses far less memory than vertex animations. With skeletal, only the vertices of the base/bind pose need to be in memory plus the skeletal key frames (and an added bonus is that multiple animations can be mixed and blended). With vertex animations, at least two sets of vertices need to be in memory so that the vertices can be interpolated.

It would indeed need code changes.

My vps costs me £2.99/month and would probably be able to host a 16 player server. Add a bit more (say, £6.99) and I'd probably be able to host a 32 player server. Most 12 slot servers I've seen are at least £10/month or more.

It's probably cheaper to buy your own virtual private server (vps) and set up a JKA server on that. I wouldn't be surprised if much of the costs associated with the usual JKA server hosting are usually to do with the hosting company managing the server itself (I.e. setting up the JKA server, adding mods, etc). The downside of buying a vps is that then you have do to all the things the hosting company would have done, plus the general security and housekeeping of the server itself.

I doubt there would have been any updates anyway. It's not something that's usually done.

Are you running the server yourself, or is this on a hosted server?

For dismemberment to always happen I think you need to set g_dismember 100 and cg_dismember 3.

If I recall correctly, using the launcher (JediAcademy.exe) always launches the game in safe mode. Does the problem still exist if you load up MP or SP using jamp.exe or jasp.exe directly?

Ah right. You're using the provided .sln file. It's currently broken so to want to avoid it. Instead you should generate a working one using the .bat file in the root of the OpenJK directory. You'll need to install cmake. Once you've run that, use the .sln file in the build/ directory.

Are you running SP through Visual Studio or are you copying the openjk_sp.x86.exe and rdsp-vanilla_x86.dll files into JKA's GameData folder and running it by double clicking the .exe?

There's some very basic support for JK2 if you build the codeJK2 folder and run SP with start up parameters +set com_jk2 1. However it's very unstable atm and there's a lot of problems.

I'd hazard a guess that your normals are inverted on those sides that are black.