eezstreet

1. upperevents is for anything involving torso animations, lowerevents is for anything involving legs. BOTH_ animations trigger both of them, and FACE_ triggers neither one of them 2. it uses map units. 52 map units (iirc) = 1 meter

It's hardcoded in a table.

Allow me to fill in the gaps.

/r_we is your best friend.

cal de cartofi

so many TFU requests it's like people think it's good or something As for what I would like to see..how about some more varied people from the cantina in A New Hope? Swear I haven't seen models for like half the people in there.

D3D can't be used with JA; Quake 3 and its derivatives all use OpenGL. I think what's more likely the case is that your video card's drivers dropped support for the old and deprecated functions used by Q3 games. Sounds like a serious issue.

^ this, but with a menu on the top which has searching, tag selection, and stuffs. Basically instead of the albums, you have screenshots of skins, and you get a pretty fast view of the selection.

mrwonko seems like he's looking into the screenshot stuff. He's currently working on his own version of a JA SP proxy DLL which should help you out. Any plans for JK2 stuff?

The "savegame" ui script appears unchanged between JK2 and JKA. Perhaps it's ui_gameDesc that's causing problems.

That doesn't really matter though, because the tags would be kinda generic. Anybody can look at a skin and say "oh, that's a Trooper skin", "oh, that's a gothic skin", or "oh, that's a mando skin". So the staff could add the tags as they feel most appropriate.

I've been mulling over a good idea for a while. You know how Steam has an API for achievements, leaderboards and such? We could do that with JKHub as well too. That would attract a hell of a lot more traffic to the site (people ingame see "JKHub API..wuts this? account be cool" etc), and it would also change the community greatly, by inspiring people to go outside their comfort zone and play mods that they've never tried, and expand the replay value of games greatly. Some key features which would be great, and how: - Achievements. They would be inspirational for people to play other mods. Plus, mods have already been trying to implement achievements already (see: MB2, GSA) and they just aren't coherent a lot of the time. It would also expand replay value. - Install Help for big mods. Think the JKG launcher, but on a larger sense. With more server power. - Leaderboards. This would help determine stuff that's really important to people - Clan support. Tie in your clans with the JKHub bar with ease - Inter-mod-chat via IRC. Ingame IRC client, complete with a stellar interface, which ties into your JKHub account for the nick. Basically, this would be a static .lib that coders would import into their mods and use as needed. Could even be implemented into some SP mods manually. Course, you'd have to approve the mods, Cael. Don't want messes everywhere.

You know what I bet people are tired of? Looking for a really good skin to use for themselves, or for others. Well, the JKHub skin selection is nothing to laugh at right now - just merely 300 ish files, but I suspect that the skin prospect could be much higher. I think JKHub needs to really press for more skins, as it has only about 1/10th as many as JKFiles. Although most skins on JKFiles suck, I do feel that there could be some ground to make there. Whenever JKHub comes across a large foray of skins, there needs to be some standards set in place which can make skin browsing that much easier. For starters, no more giant lists with teeny little icons and only one category. No. Bad donkeh. Instead, we should have a better tagging system for skins, which can convey the general style of the skin: "Goth, Cowboy, Trooper", what have you, as well as perhaps some other things too. The author of the skin specifies the tags. Secondly, what we need is a search bar which will search for the tags. Also, the list would have to be converted to a gallery, which makes use of javascript of some sort, and has larger picture of each skin. Think the iPod touch album menu (when in landscape view), but with pictures of people's skins. That would make browsing sooooo much easier, because now you don't have to click each skin to see if you like it. All you need to do is scroll past the skin to see if its good. What do you guys think?

It's caused by some guy who purchased a dedicated DDoS service. There's no fixing that without nuking someone's internet service.

Not meaning to double post, but word on the street is that iojamp has native support for Linux clients as well. No more WINE required to run JA.

please name a scripting language that isn't better than ICARUS.

The numbers could be affected by (mostly) MB2's DDOS issue, since very few people play MB2 anymore after that.

It seems they nerfed it in the engine though. The code for the electrobinoculars in jagamex86.dll is more or less exactly the same as the code in jk2gamex86.dll.

Sorry, but I'm not sure about your problem, as I don't use WINE/Linux/Ubuntu As far as installing mods go, it should be the same as Windows, since WINE supports all of the windows batch script stuff just fine. Though, I wouldn't use the crack that the people at WINE provide if you're going to play JKG, since JKG doesn't like cracks. Updating to 1.01 should be the same as well. EDIT: err, I guess you might be wondering how to install these mods then.. For skins, etc. all you need to do is put them in the base folder. For mods that come with a folder full of PK3s (and perhaps a .bat file), you need to put the PK3s in gamedata as specified (for example, if there's a base folder, put all of the ones in the base folder \in\ the base folder, and if there's another folder, copy the whole folder to gamedata) and then run the .bat. Updating is simple. Just run the executable.

The datapad code for the inventory from JK2 still exists in full. Most of the inventory items work as well, except for the light amplification goggles (which may have been broken due to shaders? not really sure) and the bacta (which they mysteriously decided to start treating like a medpack for some reason. possibly to be used in the Hoth mission with all the bactas in it)

Because then clients with low FPS would crash. And I also don't like having hitches on every server frame.

Lost track of the conversation there XD But yeah, Scooper's exporter is still pretty important. It's certainly another step forward for figuring out all the complexities of Ghoul 2.

NOTE: If you don't care much about technical stuff in JKA, best to turn back now, as I will use quite a bit of coder buzzwords here that I don't want to explain at the time of this post. Okay, so we all know that getstatus and getchallenge are a huge issue. No doubt. But what could we possibly do to solve this? Well, I have been mulling over a possible solution now, but I have found some new motivations to support talking about it. The solution? A second port. Traditionally speaking, RTSes and even FPSes have been using UDP as well as TCP for ages. I'm not sure why Quake 3 doesn't do it, but basically the idea is that you use the TCP port to handle getstatus and getchallenge, so that the UDP port (the game) goes unhindered. You'd want to check the last used getstatus request, and simply not send anything back (kinda like how flood protect works in JKA). Downside? It breaks your server's support for the master server. Sorry. Also, it prevents any clients using base JKA from using your mod. Bad. Also breaks all trackers. This also has the side benefit of allowing for Peer to Peer Lockstep. Another of JKA's major flaws is that it handles missiles and crowd NPCs (even effects!) under the same respect as a general entity such as a player. That's fine and all, but that has some really bad effects if you want to make a bunch of missiles on screen at once. This could likely fix the issues with the Flechette lagging the game so badly on some servers. No real downside of peer to peer lockstep, other than perhaps people's clients not being able to handle all the awesome graphics at once XD This brings me to my second point: a second entitystate/playerstate. With the guidance of @@Scooper, I have been working on a system of a second playerstate/entitystate combo which removes the limitation of what values are in ent->s and ent->client->ps. I added some new areas to those: ent->x and ent->client->ns, which do just about the same thing and can be accessed through pmove. The only thing I have left to do is get them organized into the client snapshot and get everything all predicted and lerped properly. They're kinda sticky at the moment, because the server runs at 25 FPS while the client runs at about ~60-90, so obviously some things which are meant to look smooth will look a bit chunky. That is, until the snapshot system is all figured out. So far, I managed to port this system to JKG, and I will be using it for the saber system as well as moving some values which were previously kept in the userint crap (ironsights and sprint stuff mostly) into it. There's only one downside to this though: people running on base can't connect to your server, even if they have the mod in question. No can do. The UI does some sort of networking before the mod even gets loaded, so you'll wind up with an error about illegible messages or some such.

Never established contact with LA due to their cryptic contact info. Disney might be easier to contact however.