eezstreet

As per the news post on this site, I regret to be the bearer of such an ill-fated release. I'd like to apologize for the dozens (if not hundreds) of people that were displaced by JKG's release fiasco. Allow me to explain. See, we were always developing the mod, but skimped out a little when it came down to the nitty gritty. As a result of a lack of foresight and stress testing measures performed by our staff, TerranGaming was forced to be shut down whenever the floodgates of people came. To make matters worse, the ZIP version of our mod still has yet to become available on Moddb. In hindsight, we probably also should not have had to force our server issues on Cael. We only did so because it was delaying the mod further. The main reason we were delayed was because Kimsufi (our dedicated server provider) refused to give service to our mod team due to nationality (team leader is Swedish, they only accept US, Canada, UK and Ireland). In short, it was a mess. Things were further exacerbated by the fact that trying to move the launcher packages in one quick go caused a bit of chaos in the system, but I am working on controlling that. Let the records show however that I do know PHP, just very little of it. Hopefully you can see past the launch issues and will play with us some more in the future. ...that came out bad. Today I was inspired by a man who told me, "They will not care if it takes forever, or if [the release] is marred by issues. It is the goal and what you make of yourself that matters."

It defines the stack memory (not the heap memory) that the game is allowed to use. This code was commented out in JA, because in JA they use a modified memory system.

Not really. There's /still/ threads on the MB2 forums (lol @@BobaFett..too right) which recommend adding com_hunkmegs to your standard server config..when it doesn't even do anything. Also, the only reason I bring this up is to quell any sort of rumor that this cvar does anything (had it referenced in a recent thread so I figured I might as well throw this out there)

My sources tell me that iojamp is now capable of connecting to a regular JA server with no issue (aside from Ghoul2 console spam). Thanks to @@Scooper for this.

com_hunkmegs doesn't actually do anything. It's a useless cvar in the game. Also, I'm not surprised by the cg_g2marksonallmodels thing. As far as hijacking 4 bytes, it's just a matter of rewriting two instructions in the code via proxy DLL. I'll have to do some tests to confirm that this is where things are actually causing the issues, but I find it retarded (there I said it) that they allocated a different amount of memory in SP than in MP.

...Com_Hunkmegs doesn't actually do anything. That's right, this little red herring of a cvar doesn't actually do anything, despite what others may have told you. It's a myth. Myself and others have determined up and down that by searching the engine, com_hunkmegs doesn't actually have any sort of effect on the game whatsoever. The cvar is initialized, but never used nor called nor needed.

To the creator of the video: TALK LOUDER PLZ that is all.

The exact error is "Ran out of transform space for Ghoul2 Models. Adjust MiniHeapSize in SV_SpawnServer.", and it comes with a handy little suggestion as to how to fix the problem. Unfortunately, Raven copy-pasta'd that text, so it's actually not as friendly as it might come off to be. IDA says this exact text is called in two different functions (base address + 0x004D94B0 / 0x004D9980 / jasp.exe ... get cracking @@Scooper ( )). To make matters worse, they stored the memory storage in bytes (and then multiply by 20 for some reason) in the code. I managed to do a backtrace and found out that the game makes a call to Z_Malloc with an approximate size of 132096 bytes. (Z_Malloc has a different declaration in jasp.exe than in jamp.exe/Q3, more on this in a moment) It can be found in sub_439F00 at [base address +] 0x0043A083 and 0x0043A09F (PUSH instruction and MOV instruction, respectively) Z_Malloc in jasp.exe works like a modified version of Z_TagMalloc with the exception that it has an added third arg which changes the method that it uses to allocate memory in the game (???). The declaration can therefore be made to look like this: void __cdecl *Z_Malloc(int size, int tag, qboolean useModifiedMethod); tl;dr / non-coder version: It can be modified by possibly hijacking 4 bytes in jasp.exe, but could trigger the CD key check (unless done via a proxy DLL). For temporary solutions: try disabling cg_g2marksonallmodels and see if that does anything. Why they decided to name an engine cvar with cg_ in front of it is pretty retarded in all actuality. EDIT: So just for shits and giggles I decided to do a backtrace of the function in MP as well. The reason why this doesn't happen in MP is because they literally doubled the size to allocate for memory between SP and MP..just another example of how things are so badly synced between SP and MP. Also note, 0x004D94B0 / 0x004D9980 can cause infinite recursion / stack overflow under certain circumstances. Beware.

We're not talking about rigging (although that's a bit unclear for some people such as myself but I think such tuts exist) specifically, but rather the making of animations using XSI instead of Dragon. Although there is a way to do it in XSI, a lot of the information behind it is yet unclear.

I think everyone here would benefit from such a rig. Also, I'm unsure if XSI can export to GLA (unless Carcass can?)

Highly sought after by a lot of people that I know of.

sets and setu are not really important unless you're trying to network it. sets makes server data known to the client (such as map, number of players, that kind of thing), setu does the opposite (saber color, hilt, et al)

two bucks says that one of them is inroo

^ or uh, this.

Not totally sure. I think there could be some clues in the game exports: d_JediAI = gi.cvar ( "d_JediAI", "0", CVAR_CHEAT ); <- last arg specifies flags I haven't totally reverse engineered the cvar struct yet, but I do know that the game imports in gi -could- hold some clues as to how to alter the flags of them. I already have the whole of gi worked out. There's no way to modify the flags of a cvar directly through the jagamex86.dll from within Raven's code though. You'd need to do an engine hack (read: jasp.exe) in order to do such a thing. If I'm right though, changing the flags of a cvar would be done exactly the same way as in MP. That's aside from the fact that temporary/custom cvars aren't totally meant to be archived. If you have a specific use for the custom cvar, I might add a sort of plugin to JAMod that would improve custom cvars for you (no guarantees yet though as I haven't even started on that)

You need to set the music configstring in order to make it play the music. trap_SetConfigstring( CS_MUSIC, soundPath ); Best way to check if you're playing music or sound (if you're altering your sound command to play music for each client as well) is to check the beginning of the file name thusly: if(!Q_stricmpn(soundPath, "sound/", 6)) { if(!Q_stricmpn(soundPath, "music/", 6)) {

My idea was not to have an overlay. Rather, it would be a static library that coders could use in their projects and have JKHub integration with some features, like achievements (if you came up with some kind of way of tying them into the page). An overlay would be okay if it had stuff like achievements and chat though.

Or if you're into that web thing, try Mibbit.

What client are you using? How are you connecting using this client?

We were discussing making IRC and JKHub achievements (if they were to exist) into a static library which would be loaded by any other mod that wanted it. But it would need to be approved by Cael first.

Custom cvars do not have the ARCHIVE flag on them, and therefore cannot be written to any sort of config without modifying the SP code

Sounds like you don't have enough memory for whatever you're doing, basically.

Ah. Might not be so bad then. cURL does make the URLs a bit easier then. Then again, I didn't try and deal with HTTP protocol through pure winsock (cURL does this for you iirc), so networking with C isn't exactly my strong suit compared to you. Think it would be viable though?

I'm not sure how C accesses the cookie information (I'm sure cURL has some sort of interface for that, but cbf to look), so you might want to look that up. Regardless, I think it's very viable for JKH to have an API which connects to all the big mods out there to track achievements and chat (at the very least) on the site.

Definitely. I can kinda port the achievement code from GSA since it works pretty well already (minus saving) and probably convince Cael to do some kind of site integration. I don't know how much PHP he knows though (http://jkhub.org/achievement.php?achieve=<id>, with user/pass sent through POST would do the trick) Definitely. I can kinda port the achievement code from GSA since it works pretty well already (minus saving) and probably convince Cael to do some kind of site integration. I don't know how much PHP he knows though (http://jkhub.org/achievement.php?achieve=<id>, with user/pass sent through POST would do the trick)