The_GTA

You're welcome! ?

Hello MisaFix, did you know that you have to check inside of a client-side onClientRender event handler using the isElementInWater function for the game frame that the player has entered the water? This way you can simulate an onClientPlayerEnterWater event and execute code for it. Can you show us your code so this question can be discussed?

Hello DRW, I think that talking about values and ideals like you do is necessary in today's times. ?

Hello lionek98, I think you are looking for the setPedDoingGangDriveby function. A gang driveby is the act of sticking out your weapon while in-vehicle in GTA SA. This can be enabled for any ped or player that is sitting in vehicles. You should take a look at the wiki page for an example script. If you want to see how it works then I recommend you to take a look at the "realdriveby" MTA community resource.

I cannot answer your question because I don't know the full configuration of your server.

Have you tried adding the following code to your script? addEventHandler("onClientResourceStart", resourceRoot, function () for _, component in ipairs( components ) do setPlayerHudComponentVisible( component, false ) end end) This will hide the HUD components by default when the resource has started.

Hello Lisandu, could you please show us the script that you have found and put into your resource? It is important to be thorough if you want to get help on the forums. To execute logic during certain gameplay or server scenarios I recommend the use of MTA event handlers, for example when a player joins or (re-)spawns. It depends on whether you want to execute code client-side or server-side. Also you have to be aware of other resources which run at the same time and might interfere with your resource, for example other resource showing the HUD at a moment you don't want it to.

Hello ChathuraLK, have you tried looking up information about Luac files on the internet? I think it is very important that you know. ?

Hmm. Maybe the combination of render-states is wrong after all. How about this? technique energyField { pass P0 { ZEnable = true; ZWriteEnable = true; ZFunc = NEVER; VertexShader = compile vs_3_0 VertexShaderFunction(); PixelShader = compile ps_3_0 PixelShaderFunction(); } }

You are rendering two passes, one without depth and one with depth. By disabling depth in the first pass you should be drawing nothing at the position of your sphere. Try merging both of the passes like this: ... PS_OUT PixelShaderFunction(PSInput PS) { PS_OUT psout; // Get TexCoord float2 position = PS.TexCoord; float timer = gTime; // correction position.xy = position.yx; float3 lineColor1 = float3( 2.3, 0.5, .5 ); float3 lineColor2 = float3( 0.3, 0.5, 2.5 ); // main effect float3 finalColor = float3(0,0,0); float t = sin( timer ) * 0.5 + 0.5; float pulse = lerp( 0.10, 0.20, t); finalColor += drawLines( position, float3( 1.0, 20.0, 30.0), lineColor1, lineColor2, timer ) * pulse; finalColor += drawLines( position, float3( 1.0, 2.0, 4.0), lineColor1, lineColor2, timer ); psout.color = float4(finalColor.rgb,1); psout.depth = 0; return psout; } //------------------------------------------------------------------------------------------ // Techniques //------------------------------------------------------------------------------------------ technique energyField { pass P0 { ZEnable = false; VertexShader = compile vs_3_0 VertexShaderFunction(); PixelShader = compile ps_3_0 PixelShaderFunction(); } } ...

What do you define as server delay?

Have you tried assigning the shader that I adjusted for you to the object? What is the effect?

Why didn't you start out with a clean HLSL pixel shader file? I don't even understand what weird ... things you wrote in that HLSL file. Did you have a HLSL file prior to this mess or did you just take this from the MTA wiki? You really should not have taken anything without me telling you to. texture m_TextureColor; SamplerState g_samPoint { Filter = MIN_MAG_MIP_POINT; AddressU = Wrap; AddressV = Wrap; }; struct VS_IN { float4 position : POSITION; float2 texcoord : TEXCOORD; }; struct VS_OUT { float4 position : SV_POSITION; float2 texcoord : TEXCOORD0; }; struct PS_OUT { float4 color : COLOR0; float depth : DEPTH0; }; VS_OUT VS(VS_IN input) { VS_OUT output = (VS_OUT)0; output.position = input.position; output.texcoord = input.texcoord; return output; } PS_OUT PS(VS_OUT input) { PS_OUT output = (PS_OUT)0; // Now that output.depth is defined with SV_Depth, and you have depth-write enabled, // this should write to the depth buffer. output.depth = 0; return output; } technique depthh { pass P0 { VertexShader = compile vs_3_0 VS(); PixelShader = compile ps_3_0 PS(); } } You still have to add things like the color output as well as the render-state adjustment to the pass.

Take a look at https://docs.microsoft.com/de-de/windows/win32/direct3d9/effect-states There you can find the RenderState property "ZEnable". Try to set ZEnable = FALSE; for your pass inside of your technique to disable depth testing. If you want to know how to write to the depth in a pixel shader take a look at this: c# - HLSL modify depth in pixel shader - Stack Overflow

Have you tried using an onClientVehicleDamage event handler? I am not entirely sure how to implement it as code either because I am not sure how the "theAttacker" parameter is provided to the event handler, but the idea is the following: check inside of the event handler for any player's vehicle that got damaged and see if theAttacker is the vehicle of a different player who is at the same time the driver. if true then use the setPlayerWantedLevel function to assign a new wanted level The clientside skeleton could look like this: addEventHandler("onClientVehicleDamage", root, function(theAttacker) local damVehDriver = getVehicleOccupant(source, 0) if not (damVehDriver == localPlayer) then return end if not (getElementType(theAttacker) == "vehicle") then return end local vehOwner = getVehicleOccupant(theAttacker, 0) if not (vehOwner) or (vehOwner == localPlayer) then return end -- TODO: send an event to the server to notify that vehOwner has attacked -- the vehicle of localPlayer. The server should decide what to do in this situation -- for example call the setPlayerWantedLevel function. end ); Then you need a server-side custom event handler in which you receive both the player whose vehicle was damaged (A) and the driver of the attacking vehicle (B). You should perform some security checks like the player A being a cop and B not being a cop, etc. Then you should call the setPlayerWantedLevel function on B if the condition is met.

Hello Krokara, nice to see that you got that spherical 3D object into the game! You have made a nice looking effect with it, too. If you want to have a 3D object be always visible to the camera then I recommend you to set the depth value of each pixel inside of an assigned HLSL pixel shader to a very small value (close to 0 like 0.001). Also disable depth testing for all those pixels. Then your object is guaranteed to be in front of any other 3D object because it will be treated as closest 3D data to the game camera. Hope this helps!

Code templates are the most powerful tools for generalizing problem solutions. Instead of writing a version of your code for each type or combination of fixed parameters, you can create a template that would then generate a substituted final type or function body based on provided parameters (types, values, etc). The most powerful example of template design in a programming language can be found in C++. By making use of the one-definition-rule (ODR) as well as the compile-time fixation of all types the compiler can generate the most optimized version of the template substitution. By making use of numerous compile-time logic execution features the C++ developer can re-use the best and most-proofed code in an ideal frequency. Suffice to say templates are a must-have feature in every programming language. The intermediate programming language that will host all programming languages in my upcoming machine-code compiler will be COS which stands for Compiler-Objects-Syntax. The language aims to be as reasonably close to known programming languages as possible. That is why I have chosen to adapt the C++ template grammar into COS. But since the C++ grammar is an impossible-pick for the dynamic nature of COS some changes have to be made in comparison to C++. I promise you the changes are not that big and easy to adapt to, once you understand why. Let me start off by describing the way C++ handles template instantiation. In C++ every type, function or variable location has a location describable by a specifier path. Thus the compiler can look-up the meaning of each specifier or even operation during lexing just by inspecting the entire program object graph (in the Eir lexer this would be implemented by the StepCustomIndirection in connection with access to the indexable global program graph). When deciding whether or not the template instantiation on a simple-specifier is possible the C++ lexer has to first inspect the specifier declaration. variant <int, float> anyval; Here the "variant" specifier has to be of template type or else the above program is grammatically ill-formed. This argument can be easily made because types are not runtime objects inside of C++. The C++ situation becomes more complicated when template instantiation of dependants is performed inside of templates themselves. By allowing types to be passed as template parameters the language does also allow template instantiation of templates that reside inside said template parameters (TP). This introduces the need for a disambiguating "template" keyword at dependent look-up. While it may come-off as annoying to C++ developers - especially considering that they know about the presence of said template in the TP and the language teaching them about the mantra "knowledge is king" - it is understandably necessary. // Example of code where the "template" keyword is required for disambiguation. struct template_container { template <int T> struct sub_template { inline sub_template( int V ) {} static const int VALUE = 0; }; }; struct not_a_template_container { static const int sub_template = 1; }; template <typename T> struct template_user { static void func( void ) { // In the next line the keyword "template" is required for the C++ lexer to be able to create a deterministic // language object graph. Then the use of T defined as "template_container" struct is possible. // Otherwise - say if we remove the "template" keyword - then the use of "not_a_template_container" is possible. // If we had no "template" keyword then the C++ lexer would have no way of creating one definitive template // object graph because the right choice of template parameter T would conflict either of the possible graphs. // This is why the mandatory "template" keyword in COS is just an extension of already known C++ syntax. // https://stackoverflow.com/questions/7304699/what-are-all-the-syntax-problems-introduced-by-the-usage-of-angle-brackets-in-c auto value = T::template sub_template <1> ( 0 ); //auto value = T::sub_template <1> ( 0 ); } }; void func( void ) { template_user <template_container>::func(); //template_user <not_a_template_container>::func(); } Now we switch our view to the COS design of template instantiation. In COS everything is a runtime-object that is transformable during runtime. Thus types and functions are not bound to one known location, standing in stark contrast to C++. To diminish this obscurity I have decided to expand the use of the "template" keyword to all forms of template instantiations including the simple-specifier case (my big wish is that C++ does add this grammar rule too because it would not hurt and it would increase compatibility to COS). template variant <int, float> anyval; The expansion claim comes from the fact that the anonymous dependent template instantiation grammar of C++ intersects in compatibility with the COS grammar. Due to the "template" keyword already being used in the similar context it is profound to believe that developers easily adapt to it. The impossible-pick is unfortunate but all means have been considered in design. COS does aim to be more explicit thus strongly-readable and this can be considered a benefit. Since templates are objects in COS you can assign them to variables of type any, allowing dynamic template instantiation with COS grammar. Ultimatively there is a big gain in forcing this kind of template instantiation disambiguation inside of COS. Weird logical problems about program ambiguity in C++ such as the following can be avoided. // Example of code that changes meaning depending on the definition of the "myStruct" specifier. const int myParameter = 2; int myValue = 3; #if 1 int myStruct = 1; #else template <int T> struct myStruct { myStruct( int V ){}; }; #endif int main( int argc, char *argv[] ) { auto value = myStruct <myParameter> ( myValue ); return 0; } This should cover the rationale behind the COS template grammar in contrast to C++. I recommend you to follow-up this article with a dive into the issues of the C++ template instantiation grammar. https://stackoverflow.com/questions/7304699/what-are-all-the-syntax-problems-introduced-by-the-usage-of-angle-brackets-in-c --- I am currently in the process of expanding the Eir lexer. There have been scientific issues greater than previously expected. Expect another update at the end of December!

What do you mean by "No"? If you want me to help you find the problem then you have to explain more.

Are you sure that only police cars have the vehicle plate text set to "police" text? Please verify by looking at the text in-game or using scripting API. Have you made a distinction between police vehicles and other vehicles in your respawn configuration? I suggest you to try disabling respawning of all other vehicles and then try enabling respawning for just the police vehicles. Maybe you will find the error in your code this way.

You can find TXD files inside of the models folder of your GTA SA game. I recommend you to use IMG Tool version 2 or IMG Factory 1.0 to look into files that end with ".img". They contain many GTA SA game files, including TXD files.

Hello amirmahdi, if a player is assigned to a team then a hidden "team" reference is set to the requested team object. The element hierarchy is not changed. Players are not children of team elements. The setElementVisibleTo function does not change the visibility of the player because it is not a child of the team element. Instead you can use the getPlayersInTeam function in connection with a for-loop to call the setElementVisibleTo function on all players... ... setElementVisibleTo(blipes,getRootElement(),false) -- this for _,p in ipairs(getPlayersInTeam(getTeamFromName("Police"))) do setElementVisibleTo(blipes,p,true) -- This end end ... Hope this helps!

Get yourself an idea how to solve the problem by these posts: https://forum.multitheftauto.com/topic/132891-important-helprespawn-vehicle/?do=findComment&comment=1004223 https://forum.multitheftauto.com/topic/132891-important-helprespawn-vehicle/?do=findComment&comment=1004224 Fixing a vehicle involves a call to fixVehicle or any other combination of vehicle state resetting functions. Consult the wiki for details on how to fix a vehicle and then combine the fixing of a vehicle with the things I suggested you earlier. If English is not a language you can understand then please feel free to switch to a language section that fits you best. While the reply speed may not be as fast as me, I am pretty sure that we have competent people who can support you natively because the boards would not exist in the first place if it were not true.

Please understand that we are offering Linux support on a best-effort basis. This error is showing exactly the reason as to why. Linux is a wicked ecosystem and some users might have so wild system configurations that even the clean set-up approach as practiced by Audifire above is not working. That is why I recommend Linux server owners to try installing the MTA server on a clean install of their operating system distribution first. We are not a Linux support board! Then we could give additional guidance based on the remaining difficulties and whether we want to support that OS variant in the first place.

stop the blip timer once the vehicle is fixed so it does not trigger clean up any blip that was created for the vehicle

Hello amirmahdi, I assume that every player can have a blip attached to it which is stored in the "jobs:police" element data slot of the player element. I can see that it is a server-side script because you are using the setElementVisibleTo function. By "gone" you mean that the player has left the server, right? For any kind of "gone" relationship where an element is being destroyed and you have to clean up any associated that with the to-be-destroyed element, you should use the "onElementDestroy" server-side event handler. For example, you can clean up the blip like this: addEventHandler("onElementDestroy", root, function() if (getElementType(source) == "player") then local wanted_blip = getElementData(source, "jobs:police"); if (wanted_blip) then destroyElement(wanted_blip); removeElementData(source, "jobs:police"); end end end ); Please make sure that you are not creating a second blip and overwritting the "jobs:police" element data with the element still present in your code. After all, you are not checking whether "jobs:police" element data is already set with a blip before creating and assigning a new one. Doing this the wrong way would create multiple blips that overlap the original one and you would not be able to easily destroy these extra and unnecessary ones. Good luck! ?