eezstreet

No. (and it was never intended to be done by then)

No. Running as administrator just gives certain rights to the user that they don't ordinarily have. Think of it as running a command using "sudo" in Ubuntu and you have the general idea.

Anyhow...whats left to complete? We fixed Xbox 360 controller support not that long ago, and Xycaleth is fixing vid_restart

They set ent->s.scale, which isn't the variable used by NPCs and player scale. I couldn't actually find the MP code that handles this, so I can't immediately compare atm.

When targeting the spawner itself, or the NPC generated?

Just checking the code here (Q3_Interface.cpp), the FLOAT type is the only one that has the incrementer built into it. But! The blocks are sent through via direct string means, ergo, the game processes the contents of the set command as a string, so it reads "+1" as a string and chops off the + or - depending. This is specific to floats only. However, it wouldn't be so so difficult for someone to write a formatter or something into this code.

Which SET_ type are you referring to?

The Thermal does no special damage, it's just standard splash damage.

You can't. There's no ICARUS or even gamecode function that codes for this. JKG had to add a function for this in OpenJK.

Why?

So..I've been a bit quiet lately with the code updates. That's because I've shifted my attention over to weapons, and in general I've found weapons to be very frustrating in terms of what can be changed. I've decided to redo the system entirely and build a new weapons system in its place. First, I've changed the weapons.dat to be a .json formatted file. You can change which .json file you want to load for your weapons in your custom game by changing a cvar: g_weaponFile (by default, it's "default.json", how clever). These .json files have a variety of new properties, some of which have been ported from OpenJK (damage was not previously modifiable until OpenJK came along...) I'd like to touch on another subject...I know people will want to probably change weapon behavior for custom games. Perhaps they want to make a Real World custom game, or maybe replace the Flechette with a T21. So I've decided that the best approach here would be to integrate AngelScript into the project. AngelScript looks and feels very similar to C. In essence, your scripts will be almost directly tied to the game's code. If you haven't gotten a chance to pick up coding, this might be your chance to give it a shot, custom game creators. Some functions will be called directly from the code. Here's a test function that I wrote: void DEMP2Test(int numIterations) { // This is the entry point for the code for(int i = 0; i < numIterations; i++) { // Print X messages on the screen, where X is what the code (C++) specifies int random = Q_irand(0,2); // Generate a random number between 0 and 2, inclusive if(random == 0) { Com_Print("I CAN HOLD IT\n"); // Print this in the console } else if(random == 1) { Com_Print("IM RIGHT WITH YOU RED THREE\n"); } else if(random == 2) { Com_Print("RED SIX STANDING BY\n"); } } } For this example, the DEMP2's firing routine will call DEMP2Test (it won't in the final version, but you get the general idea) and print some messages to the console. I'll be providing some sort of documentation on this when it comes closer to release time. Also, here's default.json, so you can get the general idea for the formatting of this file: http://pastebin.com/zQZ8QjLV The JSON file will reference specific functions in AngelScript which will be called. tl;dr - custom games can also modify weapon behavior in a variety of awesome and interesting ways, through the use of scripts created by the CG's author. EDIT: Just to clarify, this isn't a replacement for ICARUS. Rather, it is a complementary scripting language used for specific things in the game's logic (such as weapons, possibly HUD stuff at some point, etc)

I've fixed the positioning of the fists, but the UVs are still messed up and I'm not sure why. I really can't do much more with this until someone more knowledgeable like @@Xycaleth or @@mrwonko can take a look at it. I've also encountered an issue where MD3View will sometimes completely fail to export a MD3, causing it to write to the hard drive over and over until the hard drive runs out of space (!) and the program crashes. I'll examine that in a little bit. I would like to merge MD3View into ModView at some point, and make ModView capable of exporting FBX, MD3, and GLM. In the meantime, I'll be putting the code up on GitHub and working on some other projects until I can get this figured out. Github link: http://github.com/eezstreet/MD3View

Couldn't get it to work how? What were you doing?

Just found out that I have to incorporate a vertex transformation element and an entirely different approach to UVs...good job Autodesk, you're really great at documenting stuff (and "trianglating," whatever that means)

oh.. ..i-i can fix it

Models, of course! And maps! But it is a map! And interviews! but not very many of them

Wow, that's actually kinda badass.

@@DT85 yes probably. a better idea would be your first person hands in FBX format, non animated, single frame as they have very defined texture areas on them and that makes it easy to detect glitches in the UVs if they exist however I also found a good model for testing purposes. It's tris/quads combination, not sure if that's responsible for texture fuckery on it but I NEEDED TO DELIVER A MESSAGE DAMN IT and it only took 4k verts to find the proper receptacle!?

@@DT85: please ensure that the UVs are correct on the model note that positioning is fucked up, as i mentioned this is due to me not parsing the animation yet the UVs ought to be correct however this is the top of the table, occluded by what looks to be one of the legs of the table If the UVs don't match please post a picture of what the top of the table should look like

could you provide a screenshot as to how its supposed to look? also i haven't added anything in terms of animation yet so it's guaranteed to look messed up

JASS doesn't work with OpenJK, to my knowledge..

Yeah, as I understand it most of these limits are also in the game as well (with the exception of -i think- everything being in tris, and obviously the UV method)

I can probably fix the relpath issue now that I think about it. I'll need an FBX, but here are some restrictions: - Cannot use quads, only tris - UVing has to be done either in "ByControlPoint" or "ByPolygonVertex" - TGA/JPG/PNG textures only - One material per object (might be fixable but not sure yet) - Only diffuse material is accepted

(WITH RELATIVE PATHS NOT ABSOLUTE ONES THX)

would be great to get some sample fbxes with textures