Ok, Is it possible to save in multiplayer with a cog like in a MMORPG? The cog can work like this when player with name XXXX joins load player with XXX weaps, items, .... at XXX.

Is it able?

------------------
SpriteMod (JO 2003) Roger Wilco Skin

[This message has been edited by G-Man (edited September 01, 2004).]

http://forums.massassi.net/html/Forum4/HTML/004246.html

Basically...no. Between levels yes, but not after the game closes.

See my post in that thread about a bat loader file. While, you wouldn't be able to save what weapons etc they'd have, you could keep the same players. As well, if you really wanted, before exiting a game, you could sell all of your items back to the vendor, the 'DM' of sorts would take down how much money you've got, and give that all to you via DM tools when the game restarts next time. This would allow you to buy back all of your weapons. The same could be said for experience points.

JediKirby

------------------
jEDIkIRBY - Putting the Romance back into Necromancer.
Proud Leader of the Minnessassian Council

Live on, Adam.

Actually, I've got an idea about this. Something I hope to do in the Shadorun RPG I'm making. Use an external program, load up that computer's sets of character info. Choose a character, then start JK, leaving the program to run in the backgound...

It'll then place into various memory addresses the appropriate bins and values.
The program watches JK's memory locations, and updates character info with the new info. On exit of level or JK, it saves that info to a file.

The idea partially came from Kirby's mention of a bat loader, but mainly from the operation of game cheat programs like ActionReplay and GameShark. They work by finding the memory address of various things, weapons, health, whatever, and then modifying those addresses. Something similar should be possible for JK, though it'll take a good bit of work.

Too bad JK is a locked box, and simply can't be cracked in this method. Anything that could crack it would technically be against the ULC.

JediKirby

------------------
jEDIkIRBY - Putting the Romance back into Necromancer.
Proud Leader of the Minnessassian Council

Live on, Adam.

Uhm, actually, I believe that's wrong Kirby. Since it wouldn't actually modify the exe or JK in any way, it would be legal. There's nothing against running another program that uses the same memory addresses.

And there would be nothing to prevent such a program from working, as far as I'm aware. Just have the program access the same memory addresses that JK is using at that time.

------------------
_ _ _____________ _ _
Wolf Moon
Cast Your Spell On Me
Beware
The Woods At Night
The Wolf Has Come

When JK first came out I wrote a couple "trainer" programs that kept me at full ammo, life, shields, etc. before I figured out you could do it through .cog or items.dat.

It's definately possible, and not even that hard to find memory addresses. The hard part would be the program knowing when to save data and when to load, assuming this'll be automatic and not assisted by the end user.

QM

P.S. - As far as legality goes, you can modify active memory all you want, you just can't screw with jk.exe (aka hex editing) or try to reverse engineer, decompile or disassemble jk.exe. Even then, calling it "illegal" would be far from the truth.

I've considered using a dll injector (those lovely counter-strike OGC hacks use this method) to force a new graphics engine onto JK, but never really got around to wasting the time to do so. I'm sorta attached to JK's eccentricities and would have to do some serious research to do such a thing. Modifying a 3D engine at runtime isn't exactly child's play...

[This message has been edited by Quib Mask (edited September 03, 2004).]

Yeah, Kirb, you can always modifiy any program if you know the memory addresses. The hard part is to write a program that finds them at runtime, since these locations differ at every start of the target program.
About legality...it's a philosophical question. JK exe is JK exe, whether it is in memory or on cd does not matter. In some countries, though, it is legal to make any copies of binary code and modify it in any way as long as it is not persistent. In these countries, Quib Masks trainer tools are legal.

------------------
"Häb Pfrässe, süsch chlepfts!" - The coolest language in the world (besides Cherokee)

I've never heard of a country where it's ever been deemed "illegal" to make any, as you so elegantly put it, non-persistent changes. Show me evidence otherwise, I wouldn't mind being proven wrong. Uhm, don't take that as an attack, it's all sincere and meant to be read as though it lacks sarcasm (because it does).

Anyway, legality isn't an issue, I'd like to see someone come up with a program that intelligently saves and loads data. In a couple weeks, when I get my program machine dusted off and running again, I'll consider taking a stab at it if no one else has.

QM

Hmm, time to add my two cents...

I agree that if we do not modify the EXE, it is not against the license.

I have considered "wrapping" the EXE with a program that hooks into it via Windows functions. I have successfully done this before with other Windows programs. The first obstacle is that JK seems to start a separate thread for the in-game "window", but somehow disables Windows messages from getting to the thread. One reason for wrapping was to find a way to have more hotkeys.

Email me if you have interest in my idea.

Well, if all of this is possible, I might suddenly have to get a bit more involved with JK editing.

Tell me this, if a program like this COULD be made, would there be a way to link PCs via a peer2peer network with those programs, thus syncing JK?

JediKirby

Awesome. If this isn't to hard, I could REALLY use this. I just want to be able to dump some stats to a txt file and read those stats later when the game reloads.

Would it be possible to write changes to a multiplayer character file in game? Like update the force powers in the selection screen basically.

zagibu, you're right, the exe would be loaded into memory. However you wouldn't have to edit that. That's only done for speed. The exe is assigned memory addresses to store the values of it's variables. There's no legality issue in editing those memory addresses. They aren't a part of the exe, com or dll's. They are completely seperate.

As for the memory address changing, well, the starting address, probably, but generally programs are assigned memory in blocks, so it'd probably just be a matter of finding the starting memory address, and then moving forward to the other appropriate information. One of the main problems might be syncing the appropriate data. Though if you just modified the inventory bins memory addresses, it probably wouldn't be a problem.

I'd be very interersted in seeing the source to that trainer QuibMask, if it weren't a problem. I'm sure many here probably would, actually.

Unfortunately, I don't have the source (or even the program) anymore. I did that, uhhh, like 7 years ago, which was 2 computers ago. =/ I checked my ftp's to see if I had it uploaded anywhere but couldn't find it.

Finding offsets really isn't hard though. Like I said, if I have some free time in a couple weeks I may take a shot at this.

QM

Quib do you think it would be possible to write to the .mpc files? I just opened one of them up and they appear to be in a format of gibberish to me so I'm not sure if thats possible or not. But if that were possible you wouldn't even really need to worry about writing back to memory.

Scorch, really not what the main discussion is about. Generally, we're meaning things like inventory bins, for items, weapons, etc. MPC is easily edited. It's simple text. Saber textures, skin model, rank level, and then level of each of the force powers, if I remember correctly. (I'm not bothering to look at one to write this).

I think the main saving/loading operation most of us would be interested in are the inventory bins, as they generally hold all the pertinent information. (Actually, Scorcho, that'd probably include your force power ideas.. as I believe JK loads from the MPC into the inventory bins the force stars...) I may take a try at it, if I get some time.

The mpc file just seems like the logical place to put it. The player has to load one anyway so there wouldn't be any need to detect when they were trying to/needed to load old saved values. If you used a txt file, you'd have to grab the character name or something to load the correct values. I was just thinking...why not use the system thats already there?

You might be able to change the items.dat maximum value from 4 for the force powers to something that more suited your needs as well. I haven't experimented with that.

You're right about the mpc file being just a list of values for JK. I was looking at MotS mpc files, which are in fact gibberish! Doh...might be a little harder to do for MotS. Mpc is easily edited like you said...but not in game and not for the purpose of containing a saved game.

If the MPC files can load values other than just the force power bins (they give a bin reference before the value they receive) then a program could read active memory and write it to the files easily. If they can only load force power bin values, then you'd need the external program to write the other values into active memory upon load, but the MPC file could still be used for force power bins.

I haven't had MotS installed in like 5 years and don't care what their MPC file format looks like. JK's is cake (it's in plain text like was mentioned before). I'd GUESS the MotS MPC files are simply storing the values in hex rather than as a "visible" number to save a tiny bit of space, but that's just a wild guess (yes, I said guess twice, three times now; just wanted to make sure you knew I was guessing oh! 4 times).

QM

sounds complicated.....

Its a bit off topic but I'm always somewhat surprised that people who own MotS don't edit for it, prefering to stick with the more popular JK. To me it just seems to be a more powerful platform. I went over it for SetThingParent() I think! (I got both games in a combo pack off ebay for like $25 back in 98)

Anyway, back on topic. I'm only pressing the mpc because like I said, it just seems logical to load values with a system thats already there. But its most likely limited to the force bins that are set in stone in the game. Invalid values would probably be reset automatically.

It would be kind of cool if you dumped the values to a txt file with the same name as the character and then loaded those values based on the character name. For instance you have a character named 'bob' and he has a mpc file named bob.mpc...but he has an accompanying .txt file that values are saved an loaded from.

Some one mentioned not knowing how to detect when to save or load. Why not let mod authors handle that in a simple way? Just designate one unused bin as the switch bin. When the value is 0, the program takes no action. When the value is 1 it loads values from a matching txt file into memory. When the value is 2, it copies the values from memory to the txt file. Either action would also reset the bin in memory to 0.

Those were just a few of my thoughts. I only have a rudimentary understanding of this based on stuff I learned in intro C++ a couple years ago...so I may very well be talking out of my rear.

can you make this cog?

The idea of a bin to save/load is a really good idea; I'm not TOO big on it being cog controlled (so that saving/loading would work without any mod/special level) but it's definately a good solution to an otherwise painful problem.

I found some offset reading code, but it's (I think) older C++ meant for a console application (ugly DOS-style window, performs loops well, but can't really be converted into a windowed type). If I can make it less messy I'll see about posting it here soon.

QM

P.S. - G-Man, the cog would be a joke to write; it's the external helper program were brainstorming on.

I'm not sure why you aren't big on it being cog controlled...I had assumed that it would be required to have a mod counterpart to make this work properly.

Or were you aiming more for a generic format that would work with everything out there by just grabbing all the bins and saving them? So you could just save all of your storm trooper rifle ammo in a regular JK game for instance, but also save all of your money and weapons in a game of JKRPG?

If you grab all the bins, from 1-199 or whatever the max was and just reload them...I would think you might get into a little trouble anyway since some of the bins are used for game specific values like the CTF flag robot for instance. Even if you skip bins like that, there's still mod incompatibilies. I think the vast majority of them would have no trouble whatsoever, but some would have big problems. I've used a bin to store a thingcount before, destroying certain things based on its value...and I'm sure I'm not the only one who has used bins for a global count. The load process could forseeably cause problems there with existing mods is all I'm saying.

A simple .ini file that the program reads upon starting could tell it what bins to save/load and mods could supply a customized .ini along with their .gob. Just an idea. Personally, I'm all about far-reaching compatibility; having it work with basic JK, no cogs required would be my ideal version of the program.

QM

Heh. You're right. I'm thinking to narrow mindedly these days...if you're writing the program, ovbiously you could leave give it some options like that.

Curious, would it be at all hard to adapt this program to MotS...you know, after you finish the JK version?

Any updates on this?

I've been looking through some stuff, and found some code. The code's for Visual Basic... I'll try to convert it to Visual C++, lol. There's still plenty of work to be done, but I've found some nice sources which should be helpful.
As for QuibMask, well, I think he fell off face of the planet for a while.

This idea would have a revolutionary effect on what people could do with JK and MotS (pleasse, I hope whatever you guys come up with is MotS compatible, so I can use it on my game )

No longer would people be terrified of the level Thing Count limiting the size and scope of their level idea. If you were considering a massive level or a whole episode of levels, the player could simply save their stats, and any inventory items they had collected for missions, and go on to any other level the game allowed. You could even design games where you can go 'back' to a previous level to revisit a certain location, once you had discovered items in another level. We wouldn't ever have to fork out to buy SWGALAXIES or SWKOTORII (of course I will, but ...) The end of linear plots.

In fact, you could design a level, and post up a list of any new items or objectives (can they be saved also?) you have included - and other people could choose to include events in their level that use those items. There would be a real incentive to use this savecharacter concept.

Would it be a good idea to stick this topic as a permanent very interesting project? I think everyone else would be interested in the progress you make.

You know that cog values are stored between level changes, right? So parts of what you described are already possible.

Ok, for those interested, I did some testing. I used a generic game hacker, as I'm still looking at source to try and figure out how to write something similar for JK. Anyways, I started JK, and hosted a MP game in Canyon Oasis (I find using the host thing useful for testing purposes...). I started searching for a memory address. In this case, I chose raildets, since they were the first available item. I managed to isolate two memory addresses. Using these, I was able to "freeze" and edit the value for raildets. Doing so gave me infinite raildets at the number I chose. So, it works in MP. The reason for this is, as was assumed, inventory bins are all local, and aren't checked against one another by JK (something of an assumption still, but almost certain). This could have other impacts than the one's mentioned here. Some people have been wanting to get the actual time into the game. A program like this could insert the minutes, seconds, hours, into three bins to give the real time, ingame. Holding settings chosen by a host within an episode in MP could be another (such as for JKA). Or saving characters for RPG mods/levels.
(In SP this generally wouldn't be needed, because of the fact that SP will save bin values from level to level within an episode. However, for things such as getting the appropriate time, it may still be useful for SP editors)

For those interested in some of the more techincal parts of the test, here we go.
I got two memory addresses. There is something more than what it seems here.

8C4E90 - This seems to be the actual raildet bin. I imagine this is the offset from the start of the Jedi Knight process. (As I said, I was using a generic game hacker)

(Minor Note: Apparently JK runs two seperate threads at any one time. DCEiWin or something, and Jedi Knight itself. I have no idea what that's about...)

553E30 - It's related to the first. In normal JK gameplay, it remains synced with 8C4E90.

Notes:
When both value's are frozen, when the display is first updated (by pressing ESC and resume, for example), it displays raildets as being 24 (the number I arbitrarily chose to set them to).

However, after one raildet is fired, the number becomes, and STAYS, 23. This only occurs however, if both addresses are synced to the SAME value. (If anyone's got any ideas on this unusual occurence, please feel free to speak up. I can only guess it's supposed to be some shorthand for the display to not require the display system to check the inventory bins or something...)

In cases where this value is NOT frozen, or is frozen to a value different from 8C4E90, the display will upon firing, subtract one (in this case, to 23), and then return to the current number of raildets (24, in this case). Doing so rather quickly. Apparently, since there's a change inv code, it changes the display, but then it checks the inventory for display purposes, and resets it to 24.

Further experimentation shows that 553E30 is a variable set up for regulating the display. It stays synced with the inventory bin of the current weapon's ammo is in normal JK playing.

I've also found that each inventory bin is apparently 24-bits, or 3 bytes (rather unusual, actually). This means they are capable of holding values up to 16,777,216 (unsigned). Further tests on their nature will be done later tonight.

For instance, if they are initially assigned a floating point value, will the always hold values as floating point number then? If initially assigned integral values, will they be restricted to integers from there out? Can they hold signed data? And whether they will go to the maximum possible 3-byte unsigned value.

At least with this info, I believe I can isolate the initial offset of inventory bins in memory, relative to the start location of the process memory allocation.