Ship Spawning

FriendlyFire

Thanks adoxa! It appears we’re missing an entire block then, as cruise disruptors are mentioned nowhere in the INIs. This might explain why NPCs rarely if ever fire them by default.

FriendlyFire

Updated dump with adoxa’s values and fleshed out all the missing values.

foxUnit01

This is slightly off-topic, but the anti_cruise_missile values are indeed not used in the normal pilots_population.ini, and they don’t seem to actually do much (as in, anything). In vanilla FL, AI only used CDs if their target was cruising - this could be worked around by setting auto_turret to true for the Cruise Disruptor weapons, in which case AI will fire them whenever ready to. In fact, setting any missile-based weapon to auto_turret = true will ignore all missile usage parameters defined under the pilot, instead firing missiles when in the weapon’s range.
Edit: As an aside, setting all missile weapons to auto_turret = true may fix RandomMission NPCs not firing missiles.

FriendlyFire

Well I tried but I’m a bit stuck here, the rest of the Personality struct seems to consist of a lot of boolean values which are hard to track down, plus many constants that I do not know.

There’s so little left to reverse, think about what could be done with this! Could someone help out?

adoxa

See how this works. It’s the complete definition of pub::AI::Personality, attached to preserve tabs and it’s a bit big.

Previous hits = 50.

FriendlyFire

Awesome as usual

FriendlyFire

Seems like the SetPersonalityParams struct is used to initialize the AI properly… And it’s not reversed at all

I’ll try to get on it but I’m not promising anything.

adoxa

enum OP_TYPE;

class BaseOp
{
public:
  BaseOp( OP_TYPE );
  BaseOp( const BaseOp& );

  virtual bool validate();

  OP_TYPE op_type;
  int x08;
};

struct SetPersonalityParams
{
  SetPersonalityParams();
  SetPersonalityParams( const SetPersonalityParams& );

  virtual bool validate();

  BaseOp baseop; // 0
  int state_graph; // -1, used by validate
  void* x10; // -1
  void* x14; // -1
  bool state_id; // true - state_graph_id, false - state_graph
  Personality personality;
};

w0dk4

Nice job on reversing all this!

Now, the next nice thing to have would be to submit waypoints to NPCs

FriendlyFire

Mumbles about not even being allowed to have a go and fail

I kid, nice job adoxa, this’ll help tremendously.

FriendlyFire

Well spawning ships is rock solid now, can spawn any ship with a custom AI at will.

What I’m trying to figure out now are, in order:
-How to stop the NPC from dropping all of its equipment on death
-How to control the NPC
-How to add the NPC to the “normal” NPC list so that it disappears automatically when out of range

I’m pretty sure the 1st point’s key is in the ShipInfo struct, while the second point obviously lies in the reversal of the Op structs.

I wish I knew just how you can find things out so fast, adoxa

Tanjitsu

I wish I knew just how you can find things out so fast, adoxa

He is the one, he can see the code

Why485

Yeah, me too. How is that even possible? Maybe I’m just not knowledgeable enough in the subject matter but I wasn’t aware that you could even pull something so detailed (especially with regard to names of things) from just assembly level de-compilation.

adoxa

Defining those structures was relatively trivial, due to exported constructors. Doing the points above will take a bit more effort, which I’ll not do (not for a while, anyway, by which time I’ll have forgotten). I expect point two can be solved by set_current_directive, so I suppose you want IDirectiveInfo and the remaining Ops?

FriendlyFire

I’m not asking you to do them at all, you’re a busy man with a lot on your plate

What I wondered is whether you could give some insight on how to do what you do. A tutorial if you want, just some tips otherwise. I’d like to stop having to ask you or w0d all the time, but I’ve never gleaned much from disassemblies

adoxa

Well, if you want to give it a go, here’s an example using DirectiveFollowOp.

* Exported function Common.??0DirectiveFollowOp@AI@pub@@QAE@XZ
|
=1<=====
062DAF30 8BC1                   mov     eax, ecx
062DAF32 33C9                   xor     ecx, ecx
062DAF34 C7400404000000         mov     dword[eax+04], 00000004
062DAF3B 894808                 mov     [eax+08], ecx
062DAF3E C7001CE13906           mov     dword[eax], Common.??_7DirectiveFollowOp@AI@pub@@6B@
062DAF44 89480C                 mov     [eax+0C], ecx
062DAF47 C7401000001643         mov     dword[eax+10], 43160000         ; 150
062DAF4E 894814                 mov     [eax+14], ecx
062DAF51 894818                 mov     [eax+18], ecx
062DAF54 89481C                 mov     [eax+1C], ecx
062DAF57 C740200000C843         mov     dword[eax+20], 43C80000         ; 400
062DAF5E C3                     ret

```I have a separate program to demangle names, which gives us the namespace and constructor. [eax] is the virtual function table, [eax+04] & [eax+08] are from BaseOp. Looking at Follow in the mission files and where it reads it in content.dll (6F27400), +0C would be the nickname, but I still don't know what the other values are, apart from being float (probably maximum distance, x,y,z offset and something else). So assuming that, we can say:

namespace pub
{
namespace AI
{
enum OP_TYPE { FollowOp = 4 }; // and the others, of course

class DirectiveFollowOp : public BaseOp // inheritance based on observation
{
public:
  DirectiveFollowOp()/* : BaseOp( FollowOp )*/;
  // some more functions here, should be in the CoreSDK

  virtual bool validate();

  UINT   leader;       // 0
  float  max_distance; // 150
  Vector ofs;          // 0, 0, 0; copy constructor indicates Vector
  float  unknown;      // 400
};

}
}

FriendlyFire

Very nice, that should help a lot!

Can I know what program(s)/steps you use to get the output you’ve shown? I think I read you use Ollydbg to disassemble the DLLs, but how do you get the values like 150 or 400? From the INIs, from a debug process?

w0dk4

0x43C80000 in float is 400

FriendlyFire

Excuse me while I go hang myself for being so blind. -_-

adoxa

The listing was generated by a customised PEReaDeR, which I’ve attached, since I should do a bit more on it before releasing the patch (I haven’t updated my first patches with Freddy’s better code). Use perdr -b common.dll >common.lst for the listing shown. I’ve also included the demangler:

[[url=http://adoxa.110mb.com/tde/]tde] c:/Projects/undec ??0DirectiveFollowOp@AI@pub@@QAE@XZ
public: __thiscall pub::AI::DirectiveFollowOp::DirectiveFollowOp(void)