Old AI Project

[Hooman]

Here's an old AI project I worked on a while back. It hasn't seen development for a while so I thought I'd just post it as is. Hopefully it'll help other people. It uses CommandPackets to send commands directly to the game engine for units. If you want to understand the code, you'll probably need to be a somewhat advanced programmer. It does some hacking into the game to accomplish what it does.

As a general note. If you can't figure out how to compile it on your own, you probably don't know enough to be mucking with it. There are also some serious considerations you need to stop and think about before using code from this project.


Anyways, if you're into AI, this DLL demonstrates how to actually DO research at a lab, rather than just fake it with time triggers. It also has a robo miner properly build a mine without using groups (none of that cheap ConVec offset hack), build units at a vehicle factory (again without using groups, so you have exact control over this without too much hassle), and also gets Cargo Trucks to harvest without using groups (so a human player doesn't lose control over them). This was all done for the human player in this DLL, so I could actually see what was going on when I was testing the code. This could also be a nice way of starting a game with some initial setup where you are already harvesting ore when you start.

Have fun with.

Go here.

[Leviathan]

I look forward to taking a look at it and learning AI coding

Just reminded me to ask a question to Eddy-B - Are u using this method for your missions? I no you started using the main method for researsh but did you change to make the AI 'DO' the researsh for your latest coding? I rember saying as long as it works... How have you settleted to do it?

[Eddy-B]

I never changed the AI to actually DO the research (yet!) .. i might do it later on. I've mentioned already (in IRC) to Hooman i know it can be done, but i never tested it yet. My mis1 doesnt have ai-research, and mis2 has a couple of timers in it now, but i don't set Tech levels to Complete, i just start building a certain type of unit after some time.. i know it's cheap, but it works, and does it the same way those op2 coders did, i guess.

The way hooman did it with classes is the right way to do it; my code is even uglier, since i still haven't put everything into nice classes yet. And i do really have to do that, since my own code starts confusing me  <_<


Hooman: was it smart to post this on an open forum?  i thought u wanted to keep your "cheap hacks" off-limit ? - as i did too

 

[Hooman]

Smart? Debateable.

It's something you probably have to have some idea what you're doing to really use. Anyways, I'ev been sitting on this code for probably about half a year, and it's certainly useful, but I just haven't been making use of it. I figured I'd let other people play with it a bit.

As for how I've done it.... I don't quite recommend using the code in it's current form. The idea is definately good, and allows you to do a lot of extra stuff, or stuff we could do before, but with more precision now. However, the way it's done lacks something to be desired. This method could easily fail and make a level DLL unloadable (or more likely crash) in a future version of Windows. It makes a lot of assumptions that you're probably not supposed to make. I would recommend only using this technique through a shared library (DLL) so that if compatibility with future versions of Windows becomes an issues, we can fix the library and the levels will still work. There would be no requirement to recompile old levels, or even have their source to fix the problem. The source for the shared library would have to be available for recompile though.

Anyways, that's why I've been pushing the alternate OP2 interface idea. It would allow this to be done safer, and would also make it easier to use for people without much coding experience. Of course such a library would actually have to be written and everyone who uses this method has to agree to do it through the library. Getting people to work on this library and all agree to a certain design is not likely an easy task, so I don't really see this happening anytime soon. Plus, since this code is released, I'm kinda half expecting people to run off and use it in their own levels, which could turn into a disaster. That and there would be less incentive to develop such a library. So yeah, it many ways, releasing this code probably isn't such a hot idea. But then, that's why I'm attaching this warning to it. If you're going to use it, you should be aware that your level may some day become completely useless.

Of course, not releasing the code also makes it somewhat useless. I don't see myself having time to develop the code for a while. It's probably better for people to make levels that will eventually break rather than not having them at all. But then, this also might move development away from things that won't break to things that will. Now, that's all assuming this method will eventually break. I don't think that's very likely though. Changes that would break it would probably create many compatibility issues with other programs that run under Windows (although a small percentage of the total), so I doubt Microsoft would do anything to really kill the idea.


Anyways, hopefully the idea will get more development, and maybe people will see the need for a shared library. Until then, I don't really recommend using this method in released code. If fact, if you do use this method in any code, make sure to include a warning with anything associated with it. Not just in the source, but something a user of the DLL can see. If you don't understand this warning here completely (including all the technical details as to why it could fail) don't use this method.

Anyways, with that in mind, have fun poking around. Don't expect too much help as I kinda discourge using this technique in it's current form. And for those who are curious, I believe I included a compiled DLL along with the source, so you won't need a compiler to take a peek at what it does.
 

[HaXtOr]

There are missing defs in the sdk still
mainly

struct OP2 CommandPacket
{
};

[Hooman]

So you're right.... I forgot this was taken out of the shared files when they were released and that's where I had it declared for my project. Well, here it is.

Code: [Select]

// CommandPackets seem to have a set maximum of 0x74 bytes
// Note: The compiler must be told to pack this structure since the 
//   short dataLength would otherwise have 2 padding bytes after
//   it which would mess up the rest of the structure.
#pragma pack(push, 1)
struct OP2 CommandPacket 
{
	int type;    // Type of command - see secret list :)
	short dataLength;  // Length of dataBuff
	int timeStamp;  	// Game Tick (only seems to be used for network traffic)
	int unknown;  	// **TODO** figure this out (only used for network traffic?)
	char dataBuff[0x66];	// Dependent on message type
};
#pragma pack(pop)

Note the use of the #pragma. This is very important since the default behavior of the compiler is to align data types of a certain size on a boundary of that size. This would change the memory layout of the structure since there is a short followed by an int declaration. Remember, the memeory layout of this structure has to match what Outpost2.exe expects, not what your compiler thinks would make member access more efficient.
 

[Eddy-B]

I've compiled a library with some of the functions that we've cooked up so far.
I haven't tested all the functions myself yet, but it seems to be working well!

Enjoy  

[EDIT] Removed attachment; see new post below (open in new window) for the current version using IUnit instead

[Eddy-B]

I've used OP2Unit as the main class name for the extended units, but i don't like the name; it's too much of a hassle to type the OP2 everytime i use it. So, i'm open to sugguestions as to what to rename it to.  Since i'm not gonna be the only one using it, and it may (or may not) be included into the new SDK package  :whistle:  

[zigzagjoe]

EUnit?

[BlackBox]

or maybe Unit2? or IUnit?

Oh btw, I want to give a comment on Hooman's project. You'll need NASM to compile it (http://nasm.sourceforge.net/)

Go in MSVC, to the options screen, and add nasm to your "executables path". That way it can find nasm.

[Hooman]

I think I was using something like IUnit for Internal Unit. I was declaring the variables to match the memory layout of what OP2 uses. I was also thinking some virtual functions can be declared to match the virtual function table as well. Any non virtual functions could then just be added with no problems.

[zigzagjoe]

i was thinking E as in Extended. this extends the original unit funcs dosen't it?

[Eddy-B]

Yes it does...
I was also thinking about I for Internal Unit.
I'll rename it to IUnit then.. it sure types a hell of a lot faster  

[Eddy-B]

I'll be updating this library to include some more interresting and VERY useful functions later. Once i'm sure they'll execute near 100% bugfree, i'll release them. By that time i'll open a new topic in this coding forum. Also; since i cannot upload more than 1 file per post, i'll host those libraries (on Punboy's server), and just link to them from the forum.