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 };

Yes I'm sure, at least in 1.1, let me check in 1.0.5, but I don't think anything changed. Edit: Sadly this is only in 1.1, and 1.1 already has partial object sync already. You'll have to use or wait for 1.1, or create a painful work around using those functions.

Thank you. 2 more questions, I do not wanted to create new topic for these: 1; A global variable can be used in both client- and server-side, or only in one side? 2; If I create a variable client-side, it will be created for all clients, who will use this var, or it would be created once and every clients will use it, so they will delete/replace it's value? 1. No, in order for a client or server global variable to be used on the other side, it has to be transmitted or transferred using triggerClientEvent or triggerServerEvent. I believe you can use setElementData, but please don't use that, it's specifically for element data. 2. I don't think you're familiar with the terminology, so a client -- is an individual user, a server is an entity or a user that serves information to these individuals or "clients." So to answer your question, when you create a variable client-side, it will only be used when the individual's script parser executes it. Individuals do not share information among other individuals unless triggerEvent 's are used or again, setElementData.

Use one of the particle objects in this script. It includes the piss.

I'm not quite sure what you want. If you want to see if an object is destroyed, just use getElementHealth ( object ) on the object. If it returns 0 health, it is broken. You can also force break an object by using setElementHealth ( object, 0 ) , or if you want to make it invulnerable, keep on trying to setting the object's health to 1000 either by detecting when it is shot or using onClient(Pre)Render

There's no current way in MTA to disable GTA's automatic removal of an empty weapon, or make it show 0 - 0 at the moment. You could try setting the weapon to a negative ammo value, but I don't think that will work. You could try attaching the weapon model to the player's hand when the gun disappears using this resource's function. https://community.multitheftauto.com/index.php?p= ... ls&id=2540

As the guy above said, you can use textlib, but his manual way is incorrect and lacks some accuracy. The correct way: dxDrawText ( "a", 100 - 1, 100 - 1, 100 - 1, 100 - 1, tocolor ( 0, 0, 0, 255 ) ) -- black dxDrawText ( "a", 100 + 1, 100 - 1, 100 + 1, 100 - 1, tocolor ( 0, 0, 0, 255 ) ) dxDrawText ( "a", 100 - 1, 100 + 1, 100 - 1, 100 + 1, tocolor ( 0, 0, 0, 255 ) ) dxDrawText ( "a", 100 + 1, 100 + 1, 100 + 1, 100 + 1, tocolor ( 0, 0, 0, 255 ) ) dxDrawText ( "a", 100 - 1, 100, 100 - 1, 100, tocolor ( 0, 0, 0, 255 ) ) dxDrawText ( "a", 100 + 1, 100, 100 + 1,100, tocolor ( 0, 0, 0, 255 ) ) dxDrawText ( "a", 100, 100 - 1, 100, 100 - 1, tocolor ( 0, 0, 0, 255 ) ) dxDrawText ( "a", 100, 100 + 1, 100, 100 + 1, tocolor ( 0, 0, 0, 255 ) ) dxDrawText ( "a", 100, 100, 100, 100, tocolor ( 255, 255, 255, 255 ) ) -- white

If this other script is client-side, then yes.

Yes, I need someone to model a trumpet for a little game-mode/script. No the player's not going to be able to play dumb trumpets, I need it for more of a prop.

That is a pretty odd idea, maybe someone could write some monlothic MTA microkernel and server OS. Somebody's going to have to write the network driver, and it won't be me! (Also, how the fuck will you port RakNet over?)

givePlayerMoney only requires ONE argument client-side. Instead of givePlayerMoney ( player, 1 ), do givePlayerMoney ( 1 ).