The_GTA

Move the world camera for a few frames until loaded, as explained by me above. Given the details you have provided, I unfortunately cannot help you with that NaN inquiry. It sounds very unordinary.

I am deeply sorry marcelluss but you have to take my word for it. This involves creating an entirely new thing not yet present inside of MTA. If you are not the one to follow my instructions then please do wait for anyone else to follow you up on it.

Actually, you are providing a good assertion here. Instead of the 3D variant you can instead just use the dxDrawMaterialPrimitive function which is the 2D variant. And in that case you can entirely skip the shader part, directly passing the image as material parameter. You can also skip the Direct3D 9 specific projection stuff I posted above. But you do have to perform the steps up to the screen-space matrix rotation, then just pass the vertices to the 2D draw-call. Do you think you'd be up to the task? EDIT: on a second note, I think I found a fundamental flaw with this approach: the projection that is necessary for your animation to work is not applied. So I have to fix my approach a little. Sorry about that.

Have you considered that the getGroundPosition function does return the highest z-coordinate below the coordinate that you pass to it? You could run into a problem, for instance, if your editObject's position is below all the GTA SA game collision. What do you mean about "working well", by the way? Am I wrong to assume that you are experiencing getGroundPosition returning false? Or are you dissatisfied about the quality of the function result?

Can you show us the script that has to be fixed?

Hello iwalidza, it could be that the position does not have their collision loaded yet, thus not allowing a ground-position query to function. In that case you should move the camera close to your point of request, wait for a frame until the game has loaded the surrounding area and then use that request in further code. there are area on the map of which the ground position might not be of interest. In that case you could try checking against the water-surface instead or try to query the position of a possibly-defined roof.

Hello iwalidza, it looks like the color behind this transparent shape is being discarded because the geometry you are drawing is saving depth information into the depth buffer. You are encountering the classic Direct3D 9 alpha-sort problem. In the Direct3D 9 implementation it is impossible to specify a custom render-target format in combination of a custom blend operation so it is not a good idea to implement a fix for this situation, given the performance implications and requirements. You are better off rethinking your visual design, maybe sticking to a completely opaque render instead. Good luck!

In that case let me provide a template to you. I hope that it can be of help to you as a starting point. Also I am unaware of your language and why you are not trying the language specific subforum that fits you best, anyway. struct VSInput { float3 Position : POSITION; float4 Diffuse : COLOR0; float2 TexCoord : TEXCOORD0; }; struct VSOutput { float4 Position : POSITION0; float2 TexCoord : TEXCOORD0; float4 Diffuse : COLOR0; }; VSOutput VS( VSInput vin ) { VSOutput vout; vout.Color = vin.Color; vout.Position = vin.Position; vout.TexCoord = vin.TexCoord; return vout; } float4 PS( VSOutput pin ) : COLOR0 { float brightness = ( pin.Diffuse.r + pin.Diffuse.g + pin.Diffuse.b ) / 3; float4 color_out; color_out.r = brightness; color_out.g = brightness; color_out.b = brightness; color_out.a = pin.Diffuse.a; return color_out; } // TODO: put the technique along with it's passes here. You still have to finish up that HLSL code above, with the general gist being implemented already (untested). Then you still have to put into motion the Lua side of things where you attach shaders using the engineApplyShaderToWorldTexture function. This is how the world works, friend. Education is very important.

Hello marcelluss, I recommend you to implement an aftershadow to put emphasis on the rotational transition. To achieve this effect you should remember a set of drawing parameters for the rectangle in the time between now and not too distant into the past. The time can be either modelled by the passed-frame count or any time function inside MTA. Then you will have to draw N amount of rectangles instead of a single one. The older the rectangle is the less alpha level it should be rendered with (multiply the original alpha with a new factor). To get the basic rotation working you need to use the dxDrawMaterialPrimitive3D function in connection with a HLSL pixel shader. First you determine the center point of the rectangle on the screen to draw. Based on that you apply a "3D" matrix in screen-space coordinates around the previously calculated center point and set a decent rotation to it. Also we define an arbitrary distance D in pixels that the image should be away from the camera (minimum is half of the biggest side length of the rectangle). Calculate the 4 rectangle corner points (RCP) of the 3D screen space rotation, finally to calculate the virtual distance VD of each point to the virtual camera (taking D into account), calculating the fraction PS = VD/D and dividing the X,Y coordinates by PS to modell a frustum-based projection ... (you can look further down a post to see a method using dxDrawMaterialPrimitive) Next we assume that there is no 3D world space software-side vertex clipping being performed by either MTA or the used drawing code (see Remarks). Push the rectangle as draw-call with coordinate z=0 to the Direct3D 9 rasterizer. Inside of the vertex shader we have to multiply the inverse of the D3D9 projection matrix with the received position coordinate (to nullify the multiplication that D3D9 performs by-spec for each vertex). Thus we have received the screen-space coordinates as pushed into the Lua MTA draw-call. Then we do apply the screen-space Direct3D 9 rasterization cross-hair to it, inside of the same vertex shader, as demonstrated by the following image: Inside of the pixel shader we set the depth of the vertex to 0. We also disable the depth-test comparison by setting the ZFunc to Never while having depth enabled (maybe optional). And that should be it. Hopefully this is of help to you. Good luck! ?

Hello iwalidza, I have already answered you in your other topic where you have posed the same question. It is up to you where to continue this inquiry.

Please don't worry. It does only appear obvious because you have become smarter now. ?

This looks like the original 3D rendering has been given a very bright green tint. Imagine that a so-called "pixel shader" is setting the final color of each pixel that was calculated for each triangle of a 3D model. Then you can change this color by multiplying it into a very bright green color range. The simplest way to achieve this is to calculate the brightness of the pixel and then translate that into the green channel, leaving red and blue at zero. brightness [example def.] = ( red + green + blue ) / 3 green = brightness, red = 0, blue = 0 It is really worth it to learn HLSL! This visual mathematics language will open your mind about the computational powers of the GPU. Are you really sure that you do not want to try your own hand at it? In that case I will give an example.

Hello iwalidza, this "building system" appears to be a database of 3D objects as well as their 3D attachment-points. There are mathematics involved to calculate the orientation and positioning of items. I suggest that you start envisioning what points there are, in what relation they are in GTA SA local model space of each object and how to use the vector and rotation mathematics to get the desired result. You will need to use a line-of-sight check along with evaluation of the target location surrounding to check what attachment point to select based on the available ones of the current construction. I believe that you also cannot go without a Lua information structure about the current structures, their attachment-points and what attachment-points are already taken by which item. You need to have a good perception of the visual space to understand. But you can get to it iteratively by doing it in the following steps: accumulate a set of assets to use for your building system register the assets in your custom database, along with the attachment points and their supported attachments write MTA test commands to spawn fixed constructions with attachments at predetermined locations think of an algorithm to select the most-desired attachment-point previously unused for the object currently-to-be-attached by the requested user mouse ray extend the system to be click based building block just like in the video Since this seems like a lot of work to do, do not expect a premade system being handed to you that fits all your desires. But I am sure that, if given enough motivation, it is possible to pull off inside MTA. Good luck! ?

Hello Neffax, somewhere inside of your resource you have overwritten the global variable "localPlayer", that is usually pointing to the client player element, with the Lua string "player".

Hello Fory, your code does contain some variable flaws as @NeXuS™ has already mentioned. From what I gather you are messing up parameter associations for both remote event handlers "getHere" and "gotoPlayer". The actual function signature for both event handlers should be as follows: ... function getHere(showingPlayer) thePlayer = source ... end ... function gotoPlayer(showingPlayer) thePlayer = source ... end

Hello eoL|Shady, I find it hard to understand the error situation that you describe because I am lacking insight into the actual implementation. The httpSetResponseHeader function is used to set meta-data that is transfered before the content of a HTTP request. You can essentially write anything there as long as it follows the specs, which means that as long as the key matches any official property then the value must be formatted according to the RFCs. What you are describing appears to be a HTTP communications problem for website establishment in general. Did you know that browsers could reject the entire page if one component fails to load? But it is hard for me to give you an accurate assessment without having the details.

could you tell us an example server that has this "Accessories panel"? And how would you access it? are you owning such a server with an Accessories panel? any pictures or videos that show this script in action?

The breakable-property of objects does not appear to be synchronized by the MTA server based on the Lua functions. In that case you should try manually triggering a remote clientside event handler with the object as source parameter which would set your object unbreakable on each connected client. You should do that for each connected and each connecting client.

You might be using the wrong terminology here. Did you know what "frozen" and "breakable" are two different things? I think you mean "breakable" instead of "frozen". To set an object unbreakable, you should try using the setObjectBreakable function.

Hello TorNix~|nR, could you explain the problem that you are facing? I would like to know why you need to freeze an object. Is there something wrong with how the object is interacting with game world entity collisions? By default GTA SA objects are not moving unless they are touched by other entities.

I like the idea that MTA would not greatly disturb the sync actions performed by your own Lua logic. The position syncing is the most primitive approximation being performed but I guess you'd want to do that anyway. Due to the network delays no sync action can perfectly describe where the ped element should be. But having the freedom to find best practices in "high level actions" is certainly a great idea.

Hello DanylGamer, the MTA API does not manually expose the GTA SA collision system. Also the GTA SA collision mathematics have many flaws which make high-precision collision demands a no-show. Anyway, if you are still looking for an approximation, albeit a very rough one, then you can try utilizing GTA SA game objects for your collision purposes. The best implemented mathematical physics object is the vehicle. You can try changing it's model and playing around with so-called "vehicle handling" parameters to affect mass, turnMass, etc. It is possible to use Lua to implement your own mathematics into the game. By manually loading game COL files, IDE files and IPL files you can get layout of all collision vertices as welll as the positions of those 3D coordinate systems inside the global world coordinate system. Then you can perform 3D collision mathematics (warning: this is not intersection mathematics) to check where your beachball can go. I recommend you to use a 3D triangle-triangle collision modelling where each triangle consists of vertices v1, v2, v3, the triangle being offset into a local coordinate system/matrix, that local coordinate system being accelerated by vector "vel" for velocity (frame-difference in position) and a current position "pos" vector. Have fun!

You have posted links to your personal computer so anyone other than you is unable to view them. Could you upload them to a web-based file-host and give us a link to a shared web location instead?

On the moddb description pane it clearly says the following: Your question draws contradictory implications. Also there is no more download for Windows XP on the official MTA web page. Are you sure there is no other problem related to launching your MTA client?

You are right in that assessment. The ped does teleport around. You have to still call setPedControlState on every client to synchronize the ped actions/animations. I just did a test with a friend of mine on my server. I was of the impression that this behaviour was changed but nah. ^^ Wrong impression given my reading too many incomplete MTA wiki docs. I have amended the wiki documentation of setPedControlState to reflect this observation.