DefiniteIntegral

You could just use a normal vehicle, and create your own moveObject type function for moving it. It is possible to use setElementPosition on a frozen vehicle I think.... So just freeze your vehicle to stop it falling and move it along a linear path.

I am not certain, but I think turn velocity is measured in radians per second. Can someone confirm this? Drift is about a bit more than turn velocity. You should take rotation, velocity and speed into account also. Trigonometry, vectors and dot products are your friend. Getting a really accurate measurement of drift in MTA might be difficult though, since I don't think there is a way to get the coordinates of the center of the front and back axles. So yeah a good drift measurement is difficult if you don't know some math. If you want an simple one you should be able to do that pretty easily. Just set some parameters for min and max speed and turn velocity, and come up with an arbitrary score. eg minspeed = 0.1 maxspeed = 1.5 minturnspeed = math.rad(1) maxturnspeed = math.rad(45) maxscore = 10.0 -- Score when drifting at maximum speed and turn velocity function someFunction(vehicle) local vx, vy, vz = getElementVelocity(vehicle) local rx, ry, rz = getVehicleRotation(vehicle) local rvx, rvy, rvz = getVehicleTurnVelocity(vehicle) local speed = math.sqrt(vx*vx + vy*vy + vz*vz) local score = 0 local onGround = isVehicleOnGround(vehicle) -- this wont work for monster truck local upright =((rx >= 0 and rx <= 90) or (rx >= 270 and rx <= 360)) and ((ry >= 0 and ry <= 90) or (ry >= 270 and ry <= 360)) -- Don't score upside down vehicle -- only score if on ground and upright if onGround == true and upright == true then -- only score if above minimum speed and turn speed limits -- Only take vehicles Z rotation into account since it is vehicle relative if speed >= minspeed and rvz >= minturnspeed then -- cap speeds at maximum. This allows scoring above max speed, capped at max rate. if speed > maxspeed then speed = maxspeed end if turnspeed > maxturnspeed then turnspeed = maxturnspeed end -- add score local speedRatio = (speed - minspeed) / (maxspeed - minspeed) -- Get speed and turn speed ratio local turnSpeedRatio = (rvz - minturnspeed) / (maxturnspeed - minturnspeed) local scoreScalar = speedRatio * turnSpeedRatio -- Multiply ratios to find combined ratio. score = maxscore * scoreScalar -- Scale max score by combined speed ratio end end return score end .. or something like that. I just came up with that off the top of my head, there are probably mistakes. As for your marker issue... you could use the server events onMarkerHit and onMarkerLeave to start/stop a timer to accumulate score. Or, you could just have an infinitely repeating timer so drifting can be scored constantly.

Awesome

Why include a y rotation? You only need X and Z when you are transforming relative to GTA world space, since the world coordinates have constant orientation. Even if you are transforming relative to a vehicles orientation Y rotation still isn't necessary since it only controls the vehicles roll. I am not sure about ped orientations.

Please tell me that DP3 isn't going to return to a system whereby it is impossible to play LAN games without a serial. I am dreaming of an optionally non-authenticating DP3 server...

Thanks for that. I put some very basic info in the wiki. It is just a plain text description though, I am no wiki editor..

setVehicleAdjustableProperty : I noticed this blank entry in the wiki a couple of days ago. I also notice it can be called from DP2, although I have no idea what the property names are. Before I go getting my hopes up as to what sort of properties may be adjustable... does anyone have any information on this function?

Wait. Does that mean MTA is not a server-authoritative system? Since that's pretty much what I have been assuming this whole time. In that case, the lag bugs in the present version were introduced by me attempting to operate under that assumption. I can fix it easily now. Edit: Updated. It should work now, hopefully.

Thanks. Too bad it still barely works with anything above mild lag. If only MTA exposed an interface for modifying vehicle parameters in GTA directly, this entire mod would become completely unnecessary, and the lag issues resulting from my 'brute force' velocity modification would disappear. Of course I know that will never happen. Sigh... I can dream, though.

Edit : Update released. Hopefully this fixes things...

Yeah, I have experienced this as well. Firstly, it takes the server quite a while to load the maps. I suspect this has something to do with the length of the server-side script, as the problem continued to get worse as the script gained length. The script is now much longer than the original race server-side script. However even with that, it should still load after a while. However, I have also experienced the perpetual black screen problem. I am not sure how to fix it though... as no errors come up in the server logs. Usually all I need to do in this case is have the client experiencing black screen to disconnect from the server, then reconnect. Upon reconnecting it just seems to magically work straight away. To be fair, however, I also get this problem using the normal race mod, not just boost. Do you have any server-side errors come up on connect that you can post here? That would help me immensely. I am not actively working on this mod presently (I have moved on to Half Life 2 editing...), but I will try to fix any bugs that pop up. Actually thinking about it, I do have one suspicion about the cause, I shall have to look into it. I think perhaps in trying to remove server side warnings (because they annoy me), I might have introduced a spawning-related bug. If you don't mind, could you try sending me one of your map files? I would like to test it out myself to see if that helps me figure out the problem. Even just if you throw together a demo map, or whatever. You can send it to [email protected] Edit: Fix uploaded.

The reason for the long description was to outline changes made to the race mod. These changes were the main point to this release. I don't think these maps are anything special. For example they are ridiculously easy. They are largely just demonstrations of crazy stuff that can be done. I made them and the race modifications for fun... there is no 'worth' to be had from the start.

You could try having a look at setElementDimension and setElementInterior http://development.mtasa.com/index.php? ... tDimension http://development.mtasa.com/index.php? ... ntInterior I haven't used interiors so that's about the best I can do to help you.

It isn't actually moving along the x-axis. The effect you describe comes from the edge of the model moving away as a result of the rotation. Just play with the numbers a bit to compensate for the apparent drift. road = createObject ( 18450, -992.48059082031, 340.8141784668, 2.2976553440094 ) road2 = createObject ( 18450, -912.5, 340.8141784668, 2.2976553440094 ) function roadup() if road then local posx, posy, posz = getElementPosition(road) moveObject ( road, 8000, posx + 2, posy, posz + 10, 0, 15, 0 ) end end addCommandHandler ("roadup", roadup ) function roaddown() if road then local posx, posy, posz = getElementPosition(road) moveObject ( road, 8000, posx - 2, posy, posz - 10, 0, -15, 0 ) end end addCommandHandler ("roaddown", roaddown ) That is a pretty close estimate. Could still be made a bit nicer though.

Ah yes indeed. I must have been blind to miss that That's what I get for being too lazy to read the wiki most of the time. I was rather expecting something like rotateObject. That fit better with my perception of naming convention in MTA.

Rotating an object smoothly will be a different matter since you will have to handle the entire rotation phase yourself, as far as I know there is no automatic rotation command similar to moveObject. You will instead need one function to trigger the 'activation' of the bridge, and use a repeating timer call to another function to rotate the bridge in the specified direction one small modification at a time. The smaller and more frequent the increment of change each time, the more smooth looking the outcome will be. This means smoother rotations require smaller a smaller timer delay between each call. There is a limiting factor however, that the minimum timer delay is 50 ms. You could use commands instead of markers, of course the functions construction would need to change slightly. In its current form I don't know whether simply changing it to a command handler would work. Personally I don't like commands for interactions of this kind ... it just seems so anti-intuitive. Everyone knows what a marker is and could work out the raising/lowering mechanism themselves, whereas no one will know the command the operate the bridge. I suppose it really depends on what you actually want to use it for.

Heh don't worry, I do it too... I was just being facetious. jkub: Ok I will actually test it and see what the problem is and get back to you Edit: jkub: I have fixed the code, go back and copy it again from the last page. I updated my previous post instead of cluttering up this page with a duplicate script. Sorry it was my fault, I forgot to name one of the variables correctly. I also added the onResourceStart call in case you hadn't done that yourself. I tested it this time to make sure it works.

The format of outputChatBox is (message, element, r, g, b, colorcoded) So you were trying to display the message to the element '255' which obviously isn't going to work. I normally just do outputChatBox("message") for server-wide notices, which sends the message to the root element. If you just wanted to tell the player who activated the lift, just use outputChatBox("Going up", hitPlayer) It will be in white text anyway I think, so no need to worry about the 255, 255, 255. If you wanted colorization, then use outputChatBox("Going up", hitPlayer, 255, 255, 255, true) As for a two way elevator.. try adding element data to both markers. eg upMarker = nil downMarker = nil platform = nil platformInUse = false -- elevator setup function. call this once. function setupElevator() if not platform and not upMarker and not downMarker then -- create platform platform = createObject( 5154, -1157.0510253906, 140.57569885254, -2.1713070869466 ) -- create markers upMarker = createMarker( -1157.0510253906, 140.57569885254, 1.25, "corona", 2, 0, 255, 0, 175 ) downMarker = createMarker( -1157.0510253906, 140.57569885254, 13.25, "corona", 2, 0, 255, 0, 175 ) -- set direction of marker mechanism with setElementData setElementData(upMarker, 'direction', 'up') setElementData(downMarker, 'direction', 'down') end end function MarkerHit ( hitPlayer, matchingDimension ) if getElementType(hitPlayer)=="player" then local direction = getElementData(source, "direction") -- only activate if platform is not currently in use if platformInUse == false and direction then if direction == 'up' then -- move platform up moveObject ( platform, 10000, -1157.0510253906, 140.57569885254, 10 ) -- set platorm in use status to true, and set timer to free the mechanism platformInUse = true setTimer(unlockPlatformMechanism, 10000, 1) -- inform the player outputChatBox("Going up", hitPlayer) elseif direction == 'down' then -- move platform down moveObject ( platform, 10000, -1157.0510253906, 140.57569885254, -2.1713070869466 ) platformInUse = true setTimer(unlockPlatformMechanism, 10000, 1) outputChatBox("Going down", hitPlayer) end end end end addEventHandler("onMarkerHit", getRootElement (), MarkerHit) function unlockPlatformMechanism() -- just set use flag platformInUse = false end function onResourceStart( resourcename ) setupElevator() -- do whatever other setup stuff for this map end addEventHandler ( "onResourceStart", getResourceRootElement(getThisResource()), onResourceStart ) I have tested this code, it works.

I would be interested in feedback from anyone who has tried this gamemode. Like bugs to report, or complaining about me making checkpoints less versatile. Or how maps on regular SA terrain are boring I added a lot more information regarding bug fixes and changes into the opening post as well, in case anyone is curious as to what I have actually done.

"cylinder" types only seem to recognize the hit if your feet are touching the base of the cylinder. Because cylinders snap to terrain level, at those coordinates it snaps to ocean level. If you lowered the platform to -3.25, the top surface would be just barely under water. In that setting, the platform works. At all above ocean level, it doesnt work. One method is by changing the type to "checkpoint". However this has the problem that even once the platform raises, the checkpoint graphic still sticks through the platform, even though you cant interact with it. You can fix it if you change it to type "corona" and set the Z coord at 1.25 instead of -1. It seems to work totally fine that way. Coronas do not snap to terrain level, and detect all hits.

Are you using GTA SA version 1.0? Are you running GTA SA in any compatibility mode? What operating system are you using?

There is this thing: Its called reading the thread Try scrolling up

Nice Does that mean creating col shapes for markers is basically a waste of time then? Unless.. is OnMarkerHit is a server-side only event? In which case clients would still need col shapes to detect the hit.. ?

Perhaps you mean onClientColShapeHit ? Of course you need to create a coltube or something and add the event handler for this to work. It is my understanding that markers themselves are just graphics with no collision data. Can someone confirm this?

Might be that you already knew that, but just to be sure. Yeah, I decided to use a return type that is more generic. As in, it is easy to use a list of player pointers to do various tasks, like fetch and display names or perform other operations, but a list of names is pretty limiting in what you can do without additional work. I sure am not silly enough to try outputting an element pointer directly to a display function requiring string input Anyway, by now robhol should have enough information to set up his player scan just about any way he wants.. Sorry if my lingo is a bit off, I am accustomed to C/C++. I still think in terms of pointers / references.. I don't know how to 'talk lua'