Project Artemis

[Lazy Bastard]

Yes, computers only do what they are told. But the issue here is that the computer is being told what to do by the game and the homebrew app, at the same time, rapidly.

Let us know when your source is "ready"; it could help the project considerably.

[Gtlcpimp]

Yes, computers only do what they are told. But the issue here is that the computer is being told what to do by the game and the homebrew app, at the same time, rapidly.

Let us know when your source is "ready"; it could help the project considerably.

The reason why I say it's not "ready" at the moment is because it is very very touchy. It requires the .ELF to stay completely on memory when the game is executing (which is easily taken care of by putting it really low or really high in RAM), but for some reason if it crosses a certain general size or a lot of functions it will screw up the in-game debugging abilities. I can get it working nicely for a single game, but when I put in a function or two that allows it to work on multiple games it completely messes up the in-game debugger. I'm still trying to get it to be stable so then the .ELF can have all the stuff in it that it needs and still be fully functional for debug use in-game. I can slap together a quick little source that just prints "Hello" in the middle of the screen and upload that for ya if you want to work on it or take a look at how it works.

[Lazy Bastard]

Sure, please do. And, let me know which game this works for (or I suppose I could modify it to hook the appropriate syscall for whatever game I'm trying to use it for)...

[Gtlcpimp]

Ok, slapped together a quick "Hello World" for ya

http://cheaterslounge.net/downloads/...ce_Release.rar

Just don't forget who made this work! lol

The source and .ELF in the download has been pre-configured to work for SOCOM: Combined Assault (Newest Patch), and SOCOM 3 (Newest Patch). If you don't have either of those games, I'm sure you can redo how it hooks and configure it for another game. I left plenty of comments in it for you to figure out what does what if you get lost.

[misfire]

Good work.

This seems to be a solution for https://artemis.bountysource.com/task/show/2269

Maybe you want to become a developer at BountySource and commit your project to our SVN repo?

[Lazy Bastard]

Yes, you should. There will be bounties (cash rewards) for some of the tasks, as well as credit and recognition for achievements that bring Artemis to fruition (and a name in the credits forever, heh).

I'll test this solution out later today, if I get a chance.

[Gtlcpimp]

I signed up on that bountysource.com place you suggested, however I have never used or seen it before so I'm kind of lost when using it... lol.

[Lazy Bastard]

No problem. You should also join the project itself. Once we re-establish the current set of tasks and the next few layers of tasks beyond those, and set some bounties, you can provide potential solutions for some of the bountied tasks, and win the bounties for those. Providing solutions for the other ones won't net you a buck, but they will add your name to more spots in the Artemis credits

[misfire]

I signed up on that bountysource.com place you suggested, however I have never used or seen it before so I'm kind of lost when using it... lol.

After exploring BountySource a little bit more, I must say that it kind of sucks. Though I like the concept of having bounties, the provided tools are immature and not suitable for efficient collaborative software development.

My dream would be to have a Trac system for our project(s). We're using Trac at work and I really like its ticket features.

[Parasyte]

Yes, computers only do what they are told. But the issue here is that the computer is being told what to do by the game and the homebrew app, at the same time, rapidly.

Actually, the real problem is in hardware. Most programmers are familiar with hardware from a software point-of-view, which is a very inaccurate view, indeed. Hardware (that is, the path of electrons flowing (or not) through conductors) can be put into multiple states; for example, a circuit can represent the binary states 0 or 1, or it can be in a 'tristate' (sometimes called high impedance) which is neither a logical 0 or 1, but can be interpreted as either, based upon the context.

There is also the problem of controlling such strange alien contraptions as "hardware" from within the comforts of our known world of software. Is it always possible to read the state of transistor x? If not, how do you restore it to its original state? Is it always possible to change the state of transistor y? If not, how do you restore it to its original state? What about the transistors you have only indirect access to (if even that...)? Lest we forget we are dealing with hardware containing multiple billions (or even trillions) of transistors!

The answer to these questions is often very difficult to find. At times, impossible. But hey, you do what you can...

[dlsmd]

Gtlcpimp

couldn't u just dump to memory card then dump back to memory to restart the game???

[Parasyte]

I suppose you missed the post directly above; it's not that easy.

[Lazy Bastard]

Plus, a full memory dump of 32MB to MC and back would take quite a minute, even if it were feasible.

[dlsmd]

i was just wondering

[Gtlcpimp]

Gtlcpimp

couldn't u just dump to memory card then dump back to memory to restart the game???

It is possible to perform that task, however it will not work for all games. The module dependencies will stop you when attempting that exact process. Not all games use the exact same modules as you do when you compile your source, so not all games will be compatible. For the games that you can do a live dump with, it will take a while. If you plan on doing a full 32 MB dump to the memory card, then you MUST have a good compression library embedded into your program and you MUST have a blank memory card.