Some Ideas for 30-Apr-2008 Release     (Moderator: ZeqMacaw) Previous Topic | Next Topic
Page 1 of 1
 Author 
 Post 
ZeqMacaw
Site Admin
Post 17-Jan-2008 19:32        

Violet = idea
Orange = under construction
Yellow = implemented and tested

Team Chat:
Yesterday, I changed the jk-extension.dll to show the "Send to team:" prompt second rather than first, due to many people requesting it. I decided it would be better to keep the first prompt "Send to all:" because that is what unmodified JK does.

New Cog Verbs and Checksum:
When Sige added new cog verbs, we found out that a jk.exe using them would checksum if the other player were using an unpatched jk.exe. This eventually led to my implementing the -z command-line param. Today, I realized a potential cause* for it, and solved the problem. This means, the next release will not have the -z anymore; a patched JK can play with an unpatched JK, even with new cog verbs. (Of course, the unpatched JK won't be able to use the new cog verbs, but that's the player's problem.)

* New Cog Verbs Checksum Error Cause:
There are several places in the code that cog verbs are added to an internal list, presumably assigning an index number to each verb as it is added. I was adding new cog verbs at the same place that Sige had done it, which happened to be after the first set of original verbs. Thus, to stop the checksum problem, I added the new verbs after all of the original verbs were added.

PlayerAction and Hotkey cog messages:
I have not finished these, but they are still near the top of my todo list. There are some tricky steps that need working out for disabling any keys pressed.

Checksum and Cheating:
With my knowledge of the checksum system's coding, I will be making a better one for JK. This will mean that players can avoid (cog, items.dat, etc.) cheats by having all players use a patched jk.exe. (A player using an unpatched jk.exe or an old patched version will get a checksum error.)

JK-Extension.dll changing to JK.dll:
I think changing the jk-extension.dll file name to jk.dll will make it easier to keep the jk.exe and the jk.dll files together, as well as making it easier to talk about. I need to test to make sure the new file name does not cause any naming conflicts with the jk.exe file.



Last edited by ZeqMacaw on 22-Apr-2008 21:47; edited 4 times in total
Post 17-Jan-2008 22:31        

Sounds good! I'll be curious to see the new anti-cheating as well; JK's overly lenient checksum system allows for some neat potential that was unfortunately never positively exploited (only negatively).

Hm... I don't suppose -z could disable these new anti-cheating improvements in case someone wanted to make use of the more lenient old rules?

Getting the new verbs to work side-by-side with the old executables when playing is fantastic. I'd still like to request a verb that simply shows whether the new COG verbs are enabled or not (maybe hijacking SithMode()?).

QM
ZeqMacaw
Site Admin
Post 18-Jan-2008 01:23        

Yes, I plan on putting in a verb that will give some indication whether the new verbs are enabled. It will probably be some type of version number. So, in cog, it would look something like:

version = GetJkVersion();
if (version >= 1.01)
{
   // New verbs are available.
}
else
{
   // Can only use original verbs.
}


Notice I didn't use, if (GetJkVersion() >= 1.01). In unpatched JK, that line would be ignored (because the verb in the line would not exist for that JK), and the first block would be executed. Actually, JK might ignore the whole cog, because without the 'if' statement, the 'else' would cause a syntax error. I will have to test.

Post 23-Jan-2008 14:23        

ZeqMacaw wrote:

New Cog Verbs and Checksum:
When Sige added new cog verbs, we found out that a jk.exe using them would checksum if the other player were using an unpatched jk.exe. This eventually led to my implementing the -z command-line param. Today, I realized a potential cause* for it, and solved the problem. This means, the next release will not have the -z anymore; a patched JK can play with an unpatched JK, even with new cog verbs. (Of course, the unpatched JK won't be able to use the new cog verbs, but that's the player's problem.)

* New Cog Verbs Checksum Error Cause:
There are several places in the code that cog verbs are added to an internal list, presumably assigning an index number to each verb as it is added. I was adding new cog verbs at the same place that Sige had done it, which happened to be after the first set of original verbs. Thus, to stop the checksum problem, I added the new verbs after all of the original verbs were added.

ME LIKE ;]
ZeqMacaw
Site Admin
Post 25-Mar-2008 11:37        

I plan to release the next JK Unofficial Patch on April 30, 2008.

This next release (and future releases) will only be available via JKLauncher. Why? Because so many people messed up installing the older patches, even when the included txt file clearly stated how to patch JK properly. Also, with JKLauncher, there will be options to automatically check for, and to automatically install, new patch releases.

(NOTE: The next release of JKLauncher will also be on April 30.)

Post 26-Mar-2008 19:58        

Did the whole dual weapon/one key thing ever get back-ported to JK?
Post 26-Mar-2008 23:45        

Not via an executable patch, but it can be done without one.

The main problem is the ammo display which hopefully Zeq can add a COG verb to allow us to explicitly set the ammo bin for the display.

QM
ZeqMacaw
Site Admin
Post 27-Mar-2008 13:16        

Indeed, Quib Mask is correct; the multiple weapons with one hotkey can (probably*) be done in JK without a patch. (I don't like the way MotS did it; it is just another hard-coded feature.)

Yes, I am looking into making some cog verbs to handle the ammo display. I will probably make verbs that get and set which ammo bins go with which weapons, which would not break the default hard-coded behavior that older cogs would expect.


* The main issue with implementing multiple weapons on one "select" hotkey (i.e. one of the number hotkeys, by default) in JK would be finding some way to detect the press of a "select" hotkey multiple times. For example, pressing the "2" hotkey (i.e. bryar) after already having bryar selected does not send the "selected" message again.


Post 27-Mar-2008 16:37        

The way I've used for multiple weapons on a hotkey is to use, for example, weapon 2's hotkey to equip a weapon on, let's say, bin 116; then if you hit 2 again, equip weapon 117, then if 2 again, weapon 116. The trick is to never actually equip the weapon bin for that specific hotkey.

Then you need some tricky coding in the autoselect section (or weapon bins 2, 116 and 117) to handle pressing the next/prev weapon hotkeys.

For example code, my Tool Kit's weapon 6 hotkey uses this to let you select weapon 116, then weapon 6 (pressing 6 again once on weapon 6 won't go back to weapon 116 however) and weapon 10 (a modified lightsaber) cycles between 3 stances when you keep pressing the weapon 10 hotkey (0).

QM
Post 27-Mar-2008 20:05        

K, that leads me to another question then. Has the hotkey limit been cracked? It's been awhile since I edited JK, but wasn't there a max of 3 new ones vs MotS which had unlimited slots?
ZeqMacaw
Site Admin
Post 27-Mar-2008 21:31        

Interesting stuff, Quib Mask. Thanks for the info.

Tazz, no one has broken the hotkey limit in JK, and I have tried several times. There are many places in the exe that need to be changed, and I have not found them all. By the way, MotS does have a limited amount of additional hotkeys it can handle; it can handle more than JK's 3 additional ones -- something like 12 more.

For now, I expect the new hotkey and playeraction event messages to help work around hotkey limits.

Post 28-Mar-2008 14:25        

Interesting stuff, I look forward to April 30, and hope that after JKLauncher patches my JK to the latest release, I can find some games going on in JKLauncher too.

Yeah, the old package that the JK UP came in was confusing, this is gonna be much easier for people.
*** Post commands are unavailable for guests. ***