Maccer.

It's probably impossible for you to be able to use the CVehicle class object's independently given the object orientated nature of the game without a lot of modifications first. It probably also depends on other objects as well as other virtual interfaces and abstractions such as CEntity and other renderware structures. You can work around this by padding your reference structure with junk till you reach the desired offset. As well as allocating the object, you're going to have to find a way to add the created vehicle to the object pool somehow or stream it if it's not already handled. I'm not sure on the specifics of what actually goes on in the process of streaming and creating. However, I imagine you could use a wide array of methods to create a vehicle, and then when you actually create it, you can cast that memory address to an structure or interface, and then modify what you feel is necessary. Also keep in mind CVehicle is just an abstract class. If you wish to access the base entity and all of its flags and members, then you should use the CVehicleSAInterface class that's found in game_sa\CVehicleSA.h Personally, I recommend just using as much game_sa structures as possible in your source code, again, because of how entangled it is with other base entities. And they'll probably be useful in what ever else you'll be doing later on. Here's an example of structure padding, you can actually find a ton of examples in the MTA source code: Say your CVehicleSAInterface structure only contains this: class CVehicleSAInterface : public ... { /* previous code omitted for demonstration purposes */ unsigned char m_nSpecialColModel; CEntity *pEntityWeAreOnForVisibilityCheck; CFire *m_pFire; float m_fSteerAngle; // +1172 float m_f2ndSteerAngle; // used for steering 2nd set of wheels or elevators etc.. float m_fGasPedal; // 0...1 // +1180 float m_fBrakePedal; // 0...1 /* likewise */ } And you want to control the steering angle! But for what ever reason you don't want to include CEntity, and CFire having no plans on modifying them. (You can probably get away with excluding CFire, but you will definitely have to CEntitySA) Since 32-bit pointers are... 32-bit, and two 32-bit numbers is the equivalent to 64-bits or 8-bytes, you pad your structure with the sizeof ( CEntity * ) + the sizeof ( CFire * ) combined. Thus you can change your code to this: class CVehicleSAInterface /*: public ... */ { /* previous code omitted for demonstration purposes */ unsigned char m_nSpecialColModel; /* padding CEntity and CFire out! */ int pad69 [ 2 ]; /* or you could use any of these: */ /* short pad420 [ 4 ]; char pad666 [ 8 ]; */ float m_fSteerAngle; // +1172 float m_f2ndSteerAngle; // used for steering 2nd set of wheels or elevators etc.. float m_fGasPedal; // 0...1 // +1180 float m_fBrakePedal; // 0...1 /* likewise */ } You can now feel free to do something like this! /* warning, code does not actually reflect the gta-sa memory layout. do not use... or fuck it, why not? */ int * cj_ptr = 0xBADBEEF; /* imaginary offset */ CVehicleSA * cj_current_veh_ptr_offset = cj_ptr + 420; /* muahahaha, i am haxor */ cj_current_veh_ptr_offset->m_fSteerAngle = 180; Err, assuming there's no other interfaces or base classes to worry about and nothing goes wrong with absurd values. But in reality... yeah. Just save yourself the trouble and use all of the game_sa interfaces, man.

Drop the C# part. There's none of that bullcrap in MTA. Start off with C by the way! It's generally backwards compatible with C++, and it has fewer concepts to learn.

This... has nothing to do with C++, brah. Anyways I support the OOPification of MTA. This is actually what MTA:Orange was supposed to have, too bad you won't see that any time soon though... I'd love to see this integrated into the MTA Lua VM, that would be awesome.

You have so much resources to help, and to put it bluntly, please, RTFM.

o/ (Playa since '06/07)

addEventHandler ( "onClientRender", root, function ( ) setSkyGradient ( math.random ( 0, 255 ), math.random ( 0, 255 ), math.random ( 0, 255 ), math.random ( 0, 255 ), math.random ( 0, 255 ), math.random ( 0, 255 ) ) end )

no real way to prerender bumpmaps, and increasing polygon count to match bumps would lag A LOT What I'm saying is, make the texture itself more reflective and other tweaks to compensate, I'm sure there's some ways you can make it shinier.

Unfortunately shaders on peds were taken out from what I infer were stability reasons. They might re-appear in later versions perhaps but for now you might have to just find a way to pre-render this.

<3

Edit: Ransom I'm sorry I gave out my secret!

deleteResource does in-fact exist for certain 1.1 nightlies. Try: deleteResource ( getResourceName ( exports.mapmanager:getRunningGamemodeMap ( ) ) ) Those string concatenations were not necessary. Please note if you don't have mapmanager running, the call will return nothing without error.

Lordy, what was the memory usage on that thing? Also RenderWare plus GTA's CStreaming is a real bitch to mess with. What I would suggest to you is go back in the SVN a few commits (in 1.1), and get this reverted streamer re-write and work on top of it.

JR10 meant type openports in the MTA Server console. It's a little mini-script that checks for open ports. See what the output gives you.

Huh, since there's so much MTA Redditors why don't you guys go frontpage /r/MultiTheftAuto?

SetPedAnimationProgress or 0x4CEA80 is possibly part of an undocumented virtual table and it is a THISCALL. It can either be something undocumented in IDA at 0x4CE940 or the interface at CAnimBlendAssociationSA The proper way to implement it AFAIK is DWORD DwFunc = 0x4CEA80; DWORD DwThisInterface = 0x8008135; // not a real pointer to any interface or vtbl _asm { // pushing and popping is already handled by the call or externally mov ecx, DwThisInterface push fTime // you're already pretty much pushing a reference in inline asm, not need to push a reference call dwFunc };