Messages

Bump, new question.

I noticed in wheels.dff that they have multiple models of wheels representing each type that can be used by vehicles in game. Then you just choose which model you want in the XML data.

• Suppose I make some of my own custom wheels that I add to objects.xml, using its custom model ID in the vehicle's XML data will work? If not, how would I go about it?
  
• I would also like to extend the idea to custom body parts of a vehicle (hood, bumpers, spoilers etc.) that I may choose to replace the stock versions.

The end result is to basically have a mod shop similar to what you could do in GTA SA when customizing lowriders. Possible or nah?

The texture name that you assigned to the material in blender does not match the one that you assigned in the TXD file. Sometimes, 3D modeling software generate names for the added textures. Like 3DS Max, which does it in the form of Material ## (<- some digits). That's what the expected name will be and not the file name.

This piece of your advice did the trick. Thank you, cuz I've been looking around for ages before I posted here.

Texture loaded flawlessly, but as you saw in the previous pic, I basically need to setup my double faces now for an open object like this. That's no biggie though. Thanks again 

1) wrong texturing

Is there any specifics about how to texture the model for VC?

[Distance was too high, setting it under 300 solved this issue]

So I've made a custom object from scratch in Blender 2.78c, textures and all. DFF file and the TXD files were made and everything was set correctly in the xml metadata of the xml files. This the concept of the object from Blender:




Note that I'm using textures with some transparency as well if that affects things.



In-game however, I noticed two things happening.

• My textures aren't loading, so you just get this big beige-ish grey object. This is it in-game.
  
  
  
  
• 'Autogenerate' on the collision settings doesn't work either for this object. It's no real issue, I can make the necessary COL file but seeing that it doesn't work for this model is suspicious to me that something might be up Distance was too high, setting it under 300 solved this issue

Any help on what's going on? And how I can map my texture so that it associates with the DFF file properly?

[Part 2]

Part 2

[spoiler=FRAME LIMITER, ON OR OFF?]FRAME RATE

For this I tackled 3 specific frame rates:

• 60 FPS
• 30 FPS
• 20 FPS

[spoiler=READ ME FOR 20 FPS REASON]I included 20 FPS as I did a test couple months back that showed me that 20 FPS is the minimum frame rate you can be at with the GTA world still being in 100% sync. At all other levels below 20 FPS, the game begins to slow down at an exponential rate. I assume this is common knowledge as I see some servers requiring 20 FPS minimum to spawn, but if you never knew, well now you know why. And for the curious:

• 20 FPS and above: full speed
• 15 FPS: 15% slower
• 10 FPS: 73% slower

NOTE: Frame rate does NOT affect the game's clock in the top right for some reason, that remains in perfect sync, it's just the 3D world itself that becomes slower and out of sync. The slowdown of the game world cannot be fixed by bumping up the game speed settings either so no wasting time there. [/spoiler]

Results

Things that were insignificant:

Acceleration and top speed remained pretty much the same and should not be a reason for you to toggle frame limiter on for a racing server. In technicality, my results show that you do lose some speed as you go lower in FPS but the difference between 28.12 seconds for 60 FPS, and 28.30 seconds for 20 FPS from point A to point B is purely academic. 30 FPS fell in between at 28.17 seconds. This also held true when driving in sand. The results were pretty much identical and need not even be mentioned.

Collision force is another one I didn't really notice much change in. It's something that I know affects single player at very high frame rates (100 FPS +), so there perhaps is a difference there but I didn't really notice anything out of the ordinary at 20, 30 and 60 FPS, which would make any difference there an academic one.

Suspension properties didn't show any real observable changes that would make me fuss about it, so that's ruled out of the caring circle as well.


Things that did change:

Braking started to get weaker the lower the frame rate.

• 0.75 seconds at 60 FPS
• 0.81 seconds at 30 FPS
• 0.89 seconds at 20 FPS

It's something you will notice, especially the drop from 60 to 20 but I don't believe it's something to turn frame limiter on for. You have to consider, what is braking for it to be a factor to turn on frame limiter? These braking stats were tested from full speed to an absolute stop. That full length of braking is uncommon for any race you can think of so that's something to consider.

Reversing is another one that changed and is a lot more noticeable than braking was.

• 13.30 seconds at 60 FPS
• 13.06 seconds at 30 FPS
• 12.71 seconds at 20 FPS

The point however from braking also crosses over to this stat as well. What is reversing in a race to be a factor to turn frame limiter on? Certainly not winning most races by driving backwards, therefore I don't see the point for this either.


Handling

There is a difference in handling, a decently sized one at that but it was hard for me to find a way to quantify. At lower frame rates, you tend to oversteer more. At first I was wondering if it was due to differences in precision (the higher the frame rate, the better the sample rate, thus the better your precision is).

What I did to nullify potential errors caused by me was perform a handbrake turn. The handbrake turn was performed in the same position and at the same distance each time. The handbrake and the direction I chose to turn were held until the vehicle came to an absolute stop, then I photo evidenced the differences. I was driving exactly north each time and turned to the right. Sure enough, this method worked to capture what I was feeling driving around.

60 FPS




30 FPS




20 FPS



I didn't measure the magnitude of the angle shift that occurred for each turn but my guesstimate would be that the 60 FPS result was a 92 degree spin, 30 FPS was a 112 degree spin, and the 20 FPS result was a 135 degree spin. Believe me, it was much more of a hassle to try and pull off a U turn like this at 60 FPS than it was at 20 FPS.

So, if you had a race time trial setup where there are many turns and everyone uses the exact same vehicle with the exact same stats, the player with the lowest FPS may likely get the best time recorded. But not all races are like that, plus, I'd argue that the imprecision of lower frame rates may be a factor in nullifying the benefit of a lower frame rate.

Conclusion

So is it worth it to have frame limiter on? In my opinion, no, setting frame limiter is a waste of time. Acceleration, top speed, suspension and collision force aren't affected, braking difference is minimal and reversing is counter-productive for winning a race, period, so its differences hold no weight for it to be cared about. Handling poses the best argument to turn on frame limiter for a racing server, but lower frame rate impedes precision which I believe balances out the stronger steering. But it's up to you to decide from these results whether it matters.[/spoiler]


[spoiler=RAINY WEATHER]

The general theme of this one is that traction is reduced, but not all the effects of the traction setting are reflected. If you recall in the previous post, I stated that lowering the traction value causes increased braking times, understeering and reduced top speeds. The reduced traction from driving in the rain holds true to cause only increased braking times and understeering. Rainy weather in my testing DOES NOT affect top speed performance at all. Not even a little bit.

One major change however was speed in sand. You are noticeably faster in sand in rainy weather than in dry weather (5.48 seconds in rainy weather vs 6.2 seconds in dry weather).

Is that true to real life? Yes, due to wet sand clumping together to better hold its form. This ensures that as you're driving over sand and spinning your wheels, the wheels are actually pushing you forward rather than just making sand fly up and about in the air while it digs a new hole in the ground. So be proud to note that GTA Vice City is decent enough to account for this small detail.
[/spoiler]


[spoiler=Front vs Rear vs All Wheel Drive]

All my tests thus far have been on a rear wheel driven vehicle. Let see what happens when we switch things up using front wheel and all wheel drive.

Front Wheel Drive

No noticeable change in speed or acceleration, however it is noted that the vehicle seems to carry more speed coming out of corners. There's a slight speed improvement when driving on sand (6.14 seconds front wheels vs 6.25 seconds rear wheels).

Handling feels the same if not leaning towards a slight understeer but I'm pretty sure under a blind test you would not really be able to tell you're driving a front wheel drive vehicle by just this or any attributes I've addressed thus far. It does however come out of a drift quicker than rear wheel drive so its not a good setting for drifting vehicles.


All Wheel Drive

No noticeable change in acceleration, but top speed seems to have increased very slightly (28.01 seconds all wheels vs 28.12 seconds rear wheels). Very small improvement in with speed in sand over front wheel drive (6.11 seconds all wheels vs 6.14 seconds front wheel drive),

Handling for the most part is the same as what I've stated for front wheel drive except all wheel drive feels like it comes out of a drift slightly quicker than front wheel drive. Also, all wheel drive definitely does not like to take corners with anything called speed. To clarify, the test was doing 90 degree turns by tapping the handbrake and turning into the road. Rear wheel driving handles it well, front wheel driving handles it fine too but comes out of the corner with less speed loss. All wheel drive is pretty much asking you to stop to take the corner sharply in comparison to front and rear wheel driving.

[/spoiler]


That's gonna do it for Part 2. Doubt this can hold much more in this post with the 20,000 character limit and all.....so I'm separating the golden ratio as Part 3, plus its gonna take a whole lot of trial and error to have that one ready.

Also on the note, I'm not sure on this history of SLC, I'm new here, but I'm not doing this for any special treatment or special access. I have no aspiration for any of that jazz. My two reasons for pushing out help like this.

• Empathy - a lot of the help I'm seeing is advice driven. Nothing particularly wrong with that, it has its place & setting, but to use an analogy:
  
  trying to teach a baby how to walk by speaking to them won't help them get there if they don't understand what you're saying
  
  The baby is the layperson, the walking is the aspiration (to make a server) and the what they're not understanding is foundation behind scripting. It's the story of my dead end scripting life. Too many hows, not enough answers to the "dumb" whys.
  
  So for something like this, I try to do these long, unambiguous, winded, redundant explanations so that especially laypersons will understand without having to skip off the page to figure out what the heck I'm saying. It's what separates those who can make something on their own from those that have to copy everything they see/are instructed to do and hope & pray that it works.
  
  
• I've been apart of VC:MP for 8 years now, might as well add something to help my fellow members of the community

Part 2 to this is gonna address some things in the works. I'm gonna tackle some important areas like:

• whether FPS differences produce any significant changes to care about having frame limiter on vs off
• rainy weather assessment
• golden ratio that will keep vehicle performance the same no matter how you change up your settings
• front wheel vs rear wheel vs all wheel drive differences

I have some insight on the golden ratio aspect right now but I'm not done yet. Basically, as stated before, the dimensions affect the speed of the vehicle, the bigger you set it the slower you'll go. What I was testing is how much you would need to increase acceleration stats to negate the decreased speed and achieve the original performance.

So far, my data points to a ratio of 4 : 3, acceleration : dimension. Apply this ratio in either direction (bigger dimension or smaller) and you should get the same performance out of your vehicle speed wise. This completely ignored the fact that the vehicle handles differently and also after a point in bigger dimensions this ratio will start to taper slightly, so it not perfectly linear, which is to be expected as you have many other conditions that I haven't accounted for yet to give a final conclusive answer. But as a dirty ratio to temporarily work by, it serves its purpose well.

The point where the dimensional changes are too much for acceleration stats alone to handle, I added top speed changes at that point and that seemed to negate the taper. The ratio I got for that was 1.465 : 1, top speed : dimensions. I don't remember at what point in the dimensions that was but I know it was of an impractical size (larger than truck stats) so for all intents, the rough acceleration ratio again should serve well

Also to note, while these changes will give you the same result from point A to point B in a straight-line, the vehicle does behave differently. Smaller dimensions tend to accelerate slower but hit higher top speeds balancing it out, while larger dimensions are the opposite. So that's also something to consider.

[extreme]

This guide is to help anyone that would want to establish customizing vehicle performance to what they see fit without dealing with all the guesswork of what numbers to use. By using this guideline, you will gain an understanding of what effect on the vehicle each setting gravitates towards as you increase or decrease the values you choose to set. My findings are incomplete but since it's in high demand, I decided to fill the void now and update later.

[spoiler=PLEASE READ NOTICE]
All results you're about to see were done:

• At 60 fps constant
• In clear weather conditions
• Tested on a rear-wheel drive vehicle
• Vehicle had equal distribution of brake force between front and rear wheels (unless stated changed)

Also, a good portion of the results isn't scientifically proven (meaning not everything I account for was measured for statistically significant differences). Most of it is just personal observation of the differences I feel in the vehicle. So these areas may hold less weight and it is open for scientific proofing for validation. Anywhere I state numerical results means that I validated it; if it doesn't, it's just observation and personal feeling.

This guide also assumes you know how to edit XML data for custom vehicles. For ease of mind this link here should be able to help you out most of the way on how each setting affects the car's characteristics bodily wise. I'm filling out the performance aspect.

Most values were shifted by a magnitude of 1 in either direction (negative or positive) from its original value unless I state that something took an extreme (note the word choice, not if I say high or low, only extreme) increase/decrease in value to achieve the result (in which case, such values were shifted by a magnitude of 10).

When I say setting values to low, for most values this means using negative numbers. The only exception to the rule are bias settings where those only use positive numbers and have a range of just 0 to 1 and settings that only work with positive ranges (like mass and number of gears).
[/spoiler]



[spoiler=RESULTS]
Flags

1G_BOOST - this flag speeds up the acceleration rate of the first gear. If this setting is disabled, you will hear the vehicle have a delay in sound to when the engine rev kicks in. The car is still moving but the rev is low and tamed. Enabling this setting skips that delay completely and the engine revs with max acceleration from the start

• Disabled - 2.5 seconds to shift out of 1st gear
• Enabled - 2 seconds to shift out of 1st gear

2G_BOOST - this flags does the same as the 1G_BOOST but for 2nd gear. The difference however is much smaller (almost insignificant). Negligible enough to be ignored, however, it might help heavy vehicles greatly in theory (didn't test to check).

• Disabled - 1.65 seconds to shift out of 2nd gear
• Enabled - 1.5 seconds to shift out of 2nd gear

IS_LOW - this flag seems to lower the centre of gravity of the vehicle making it slightly harder for vehicles to roll (was not tested with a van that has more rolling capability so results may vary)

REARWHEEL1ST - this I believe increases the bias of wheel drive power to the rear wheels. The car is notably faster with the setting OFF rather than ON (my guess is the increased power to the rear wheel causes a bottleneck in traction, leading to more wheel spin & burnout but less propulsion of the vehicle)

• Disabled - 6 seconds from point A to point B (in sand)
• Enabled - 6.2 seconds from point A to point B (in sand)

GOODINSAND - namesake, improves handling of the vehicle in sand. No change in general speed, but acceleration from stationary to 2nd gear greatly improved (especially on an incline in sand)


NEUTRALHANDLING - no observable changes (maybe helps bikes instead, never tested)


That covers the flags that I found and/or believed would have some effect on vehicle performance. Now we go into the variable attributes that you can set to any value (sort of).


Mass - PAY ATTENTION FOR THIS ONE. You would think this one should be as straightforward as deceleration was for brakes. You would be horribly wrong. It turns out, this is the most illogical setting of them all. So sit tight while I explain this.

In terms of collision force, this is logical and holds true to reality. The greater the mass, the stronger the force you generate hitting other vehicles and vice versa. Handling is unaffected whether it's high or low mass. We can debate whether this is true to life or not but for me I don't think it matters enough to be an argument considering the rest of settings.

Logical reasoning ends right there my friends.....

This is because the more mass you add, the FASTER your vehicle will go. You essentially become a speed hacking tank driving around. It's sheer madness.

Similarly the lesser the mass, the SLOWER your vehicle will go. You essentially become a snail with the force of paper.

This makes changing the mass of your vehicle very tricky, and is what inspires Part 2 to this guide, where I will calculate all the relationships of the settings to keep performance at a constant.




Dimensions - NEEDS TO BE STRICTLY CONSIDERED. Through my investigation of vehicle models versus the data presented in handling.cfg of the game files, most settings don't add up one bit. Ever notice that outside top speed and maybe acceleration, almost every car in a specific category kinda feels like it handles the same? Despite the reality of vehicle size variations, most vehicle stats are generalized in their dimensions. If you look through the game stats, you'll see predominantly for the x axis (this controls width of the vehicle) that the setting is 2.0 m with little variation outside this (an Infernus is much wider than the tiny Manana car for example but they have the same x axis value in game stats). The y axis (vehicle length from front to back) and z axis (vehicle height) seem to show a lot more variation that more or less reflects truthfully the vehicle's actual model dimensions.

Now what effect does the dimensions have on the vehicle if all other things are equal? It affects WEIGHT and HANDLING. The bigger the vehicle dimensions, the heavier it seems to feel and is noted by a large reduction in speed, lower jumps, stronger collision force, everything you'd expect of a bigger vehicle. Also the bigger the vehicle, the more it feels like a van, or truck - sluggish in turns and has higher chance rolling onto it's roof (probably proportionately changes centre of mass as well to cause this). Inversely, the smaller the dimension, the more the quicker and nimbler the vehicle. Feels like a toy race car the lower you go, and the car becomes lighter, thus higher jumps, decreased collision force etc. (and is able to ragdoll like crazy if you crash in air).


Centre of mass - determines where most of the mass of the vehicle is distributed against the dimensions of the vehicle. Each axis gives a different result.

• X axis - the car will balance on two wheels depending on direction pretty much like this:
  
  
  
  It's impossible to drive in this state, but if set to an appropriate level where all 4 wheels are on the ground, the car will have a tendency to roll when you turn in the opposite direction of centre of mass (so if the centre of mass has a left bias like the picture shown, then if you turn your vehicle right, it will roll over and vice versa). The side of the car that has centre of mass bias makes sharper turns whilst the weaker side understeers and tends to want to lift up should you hit a bump let's say. Vehicle will have the tendency to want to rotate clockwise/anti-clockwise up to a point when in mid-air after a jump depending on the respective side of mass distribution (if the centre of mass is to the left, the vehicle rotates anti-clockwise slightly and vice versa)
• Y axis - This operates similarly to what you would expect of the traction bias but make note that they are NOT equivalent settings. They both cause distinct effects on the vehicle that rightly sets them apart.
  
  When the centre of mass is distributed to the front of the vehicle, the car's traction at the front increases greatly and ultimately causes the vehicle to suffer (too much traction at the front causing rolling resistance when turning under speed). The rolling resistance slows down the vehicle considerably with every turn you make. Turning becomes less nimble and tends to increase understeering. The vehicle also tends to glide very smoothly in a straight line to the direction you're facing when bringing the vehicle to a sudden stop. The vehicle nose dives when jumping and cannot drift whatsoever.
  
  Vehicle is also slightly slower in acceleration:
  
  • 7.1 seconds to 5th gear default centre of mass
  • 7.5 seconds to 5th gear under front-end biased adjustments
  
  When the centre of mass is distributed to the back of the vehicle, acceleration is unaffected and the back-end of the vehicle tends to spin out with every turn you make. Impossible to drive at these levels, but if set appropriately, the vehicle becomes extremely nimble, and the turning is much sharper (it's like driving a Cheetah but nimbler in a good way). Back of the vehicle dips when taking jumps.
  
• Z axis - vehicle tends to roll very easily when set to higher heights. Vehicle also jumps higher but not farther. Other than that, nothing else really feels different. When set to lower heights, the vehicle becomes resistant to those bumps that would lift your wheel from off the ground. Vehicle jumps lower but farther.

Traction - traction is the grip your wheels have on the road. When set to low values, the loss of grip causes:

• Increased braking time
• Understeering
• Reduced top speed

In contrast, increasing the traction value eliminates wheel spins, decreases brake time and leans towards oversteering (but in a very very good way, so good it's like it reduces input lag, making the vehicle feel more responsive to your controls). The increased traction however also causes reduced top speed as the engine power is now the bottleneck (causing rolling resistance).


Traction loss - I'm not sure under what circumstances this setting gets applied but it has a critical function.

If this setting is set too low, the vehicle loses all capability to stop (the perfect body in motion as an example for our physicists here). If you so much as touch the vehicle, giving it a tiny bump with your player, it will slide away forever.

With the setting set high, the vehicle has increased steering agility with an increased susceptibility to want to roll over IF steering is locked (not sure why on that though). Other than that, pretty much mimics the traction high settings.


Traction bias - determines the level of traction distribution between the front and the rear wheel. If the value is set up to 1 (front wheels), the vehicle cannot be driven and the rear wheels spin out. If the value is set to 0 (rear wheels), the vehicle is able to drive and feels like normal but the vehicle cannot turn. Therefore traction bias is a balance of turning ability and acceleration. They have an inversely proportional relationship.



Number of gears - setting this to a lower value does decrease the speed but not as significant as you would expect (29 seconds form point A to point B using a lower value vs 28 seconds at highest settings) . This setting also does not follow completely true to life. I didn't have a speedometer so I have no way of confirming definitively that I was hitting the same maximum velocity, however the difference in vehicle performance seems negligible enough to ignore this setting.

One thing you SHOULD NEVER DO is set the value above 5. This COMPLETELY GLITCHES THE GAME. If you drive a vehicle with 6 gears, it may try to fly and bounce off all manner of debris, 7 gears may bounce around all over the map, 8 gears flat out freezes the game and hangs the PC system. DO NOT USE ANY VALUE ABOVE 5!!!. You have been warned.


Engine type - in reality there are advantages and disadvantages to electric, petrol and diesel engines in terms of performance. GTA Vice City ignores all that jazz so this is a setting you don't need to tamper with, there's no difference in performance between all 3.

What it does is make a visual change in the exhaust smoke (different colour between diesel and petrol, no smoke at all for electric engine).


Acceleration - fairly straightforward setting. The more you give, the faster you will accelerate. However there is a point where traction becomes a bottleneck and you will get no further benefit from going crazy in acceleration. So it is definitely a balancing act to achieve as high of an acceleration as you want (though arguably this balancing act could be cheated with setting the mass higher, seeing how illogical that is right?). Most of the acceleration happens in the first gear. Lower settings just means lower performance, no change to handling.




Brake - what's used to stop the vehicle


Deceleration - pretty obvious really but I tested just to make sure. More you give it, the stronger the brakes, the less you give it the weaker the brakes.

Brake bias - determines the distribution of brake force between the front and the rear wheels.

A value of 0 (rear wheels) makes the vehicle perform very sharp turns when braking. However brake performance to stop the vehicle gets worse. Similarly with a value of 1 (front) the brake performance is as worse as 0 than if the brake force was evenly distributed (0.5). The vehicle refuses to turn and drifts in a straight line and braking and turning with a brake bias of 1.

0.5 gives the best stopping power, and this is to be expected, as it is never a good thing to have brake bias in real life AFAIK.



Suspension - the suspension is what is used to adjust the vehicles height (height of the vehicle body from the axle of the wheels) as well as what eradicates the jerky effects of driving over bumps in the road, keeping the body of the vehicle in a stable parallel position to the ground (shock absorbance properties).


Force level - In extreme cases, the vehicle resists bumps in the road, however, a good strong bump that would normally cause spin-outs can now send you flying. I attribute this to the fact that the vehicle at these very high settings becomes bouncy in a stable way. All in all, the suspension becomes STIFF and should not be mistaken to be used to gain more shock absorbance.

Vehicle height is also affected by this sing (the higher the value, the bigger the gap between the vehicle body and the wheels and vice versa).


Dampening - this is the setting that is for the shock absorbance properties of the suspension. High settings makes bumps a thing of the past, but it is not all happy days doing so. The way a suspension works is that it compresses itself upon hitting a bump, which therefore makes the body of the car remain relatively as leveled as it was to the ground before the bump. It is because of that fact that increasing this dampening value also inhibits jumping capability (your vehicle basically absorbs too much out of any ramp and just tries to head straight, completely leveled). The vehicle body also elevates away from the wheels as well with this setting.

Too low of a value and the vehicle is impossible to drive. The vehicle just bounces around to any and everything. Appropriate settings are therefore recommended when it comes to dampening.


Upper limit - Not a useful setting to change from defaults in my opinion as it causes some strange effects. At high settings, the wheels begin to rotate along the y axis and mimic the cheat "SEAWAYS" when driving on water (the wheels change to that look). Vehicle is also lowered to the ground as a result.

In low settings, the vehicle simulates 100% traction loss, only this time the wheels are glitched into the floor. As stated, best not to trouble this one.


Lower limit - lower settings raises the body of the vehicle significantly. Could be useful if you would want to have a vehicle model similar to monster trucks like this



However note that you if you do not increase the size of the wheels appropriately, low settings will make the body of the vehicle look like its floating in mid-air.

The setting also amplifies dampening in and gives a more realistic result of how the wheels adjust to bumps in real life (that springy look) and makes the car more susceptible to rolling (like a van as the height of the vehicle has been increased tremendously).

In high settings, the vehicle body is on the ground while the wheels are in the air. Therefore high positive values are not good values to use with this setting.


Bias - again, distribution of suspension settings between the front and the rear wheels. A value of 1 keeps the front wheels high but lowers the rear wheels. This introduces vehicle bumper scraping as you drive along. No real observable differences in performance and handling outside this fact however.

A value of 0 does the opposite, it keeps the rear wheels up while the front wheels are lowered, causing the same effect as stated above. One addition however with this setting is that the vehicle now tends to be bouncy with bumps as you hit them, so it's kind of unstable to use this value.


Antidive - this setting prevents the vehicle from leaning in a certain direction when stopping (the inertia effect that tilts the car forward or backward when stopping) and thus keeps the vehicle leveled at all times. The way how the game implements this is like an invisible force that pushes either the front-end or the back-end of the vehicle upwards in the air depending on how you're stopping.

So when stopping from driving forward, the front of the vehicle leans down to the ground. This setting therefore a applies and upward force at the front of the vehicle to cancel that inertia. Likewise, when you're stopping from reversing, the back of the vehicle leans down to the ground, and this function now applies an upward force to the back-end to negate the effect

If you go extremely high on this setting, the vehicle will flip onto its roof like you would flip a remote in your hand everytime you stop. Therefore, appropriate settings are needed for this. If you hit the sweetspot, the car will remain 100% leveled when you stop, however, this has a negative effect on brake time that is of similar magnitude as setting 100% brake bias to a particular direction.

All negative values for this setting seem to have no effect on the vehicle, therefore only use positive values for this attribute.[/spoiler]

Another question that I have (I'm assuming this one is very possible based on what I'm seeing). I would like to also have the ability to tilt vehicles along each axis (x axis rotation would lean the front/back of vehicle up or down, y axis rotation would perform like a barrel roll, z axis is your typical north south east west compass rotation).

This tilt function would operate ONLY if the vehicle is in mid-air. This would be binded to key combinations. There's a way to detect if something is not in contact to the ground correct?

1- Can be achieved using mathematical calculation (calculate number players within the radius of a circle center, apply a force or smth equal to a given calculation)
2- http://wiki.vc-mp.org/wiki/Scripting/Squirrel/Functions/Player.CameraLocked , http://wiki.vc-mp.org/wiki/Scripting/Squirrel/Functions/Player.SetCameraPos , do mathematics to control the camera according to your needs
3- similar to previous, may not be smooth due to the fact that you cannot extrapolate, smoothing algorithms are not efficient since it's a server function
4- keep an array of objects, calculate direction of movement and velocity of movement over time, snap according to a given threshold
5- create an object, track it's shots
6- doable with GUI, perhaps create random black squares/circles continously on the screen at random positions, have a function determine when to start and when to stop, it uses client scripting so it would not hinder server performance
7- make a GUI, unfortunately you cannot rotate 2D sprites/make a set of checkpoints to point you into the right direction



See how the pickups point to a certain direction
8- achievable through many means, .SetImmunity and change handling values for vehicles

Impressive, for the most part this has satisfied me well on what approaches to take but I'll need some clarification on some points:

1 - after the effect of the force is calculated, I'm having trouble picturing how to apply that back to an object in-game. Is there like a force function to feed all the data to or I'd have to just cleverly consider and manipulate an object's rotation and position properties? Also in your opinion would these force calculations cause issues to server performance if say it was a run under the chaos of 30+ players?

6 - this one is as Sebastian says. I'm more looking to have an effect that warps the screen as a means of confusion, not necessarily have spawning sprites blocking a view if I'm understanding you well

Rest is depending on vcmp devs, if they wanna make a function for turning free camera on.

I see. Thanks for this, but then now that makes me ask how do they make these functions that are available to us in the first place? Like a general idea of the process

8- A vehicle can't be invisible but intangible.

Code Select Expand

vehicle.IsGhost = true;A player can't be intangible but immortal and invisible.

Code Select Expand

player.Immunity = 31;
player.SetAlpha( 0, 0 );

Good looking out Xmair, this is exactly what I needed. I appreciate it

Your postive feedback is greatly appreciated.

This isn't eBay mate.

The question I pose is serious, so I'd ask kindly to keep it serious mate

I wanted some advice on this from the more experienced scripters of the community cuz I have many ideas but not much practical knowledge in the field. I don't want to waste time on a project that's virtually impossible. As such, I would like to know how possible these ideas are from any perspective (i.e. possible through scripting or some custom dll, a 3D model that I'll have to make or idk, forgive my ignorance). Also, please think very cleverly before saying any idea is impossible.

So how possible is it to:

• Have an animated force field of sorts like a shockwave that can affect other players
• Have a camera with a set angle range of view per axis (like being unable to look up in the sky but still free to rotate all around you)
• Free view in a vehicle similar to spectating
• Snap objects perfectly together when mapping (for like roads for example)
• Have a custom hitmarker or dummy or whatever it is you would use to register that you're pointing at something that can be shot at
• Making my own custom distortion effects (like the effect on screen when sending Phil to the hospital)
• Have a compass of sorts pointing to a checkpoint
• Make a player and vehicle intangible and/or invisible

Your postive feedback is greatly appreciated.

Thank you all for the feedback, we've now since resolved the report thanks to this

Ok so Im presented with a report for a server to solve. The accused has random kicks that are not due to any scripting or person i.e. the server just says "Player has left the server (kicked)" no further reason presented. The accused is saying that this is a result of a server deadlock issue and is presented with the message "crashed with deadcode" or something to that effect. I have no console errors to present unfortunately. So Im just asking devs what are some possibilties you can think of to cause a deadcode/server deadlock in VCMP?

UPDATE:

I added information now most of the commands and tags and remade everything into a PDF document. I'll publish that once I get around making a cover page I like.

A new approach I'm going to take is that for now I won't post one big PDF file with everything, I'm going to break it into 3 files (i.e. the stuff i wrote in that doc, the ID index sheets and the scripting guide) so that the sections are a bit easier to assess.

With that said do these tags in server.conf still do something? Cuz if they do, I dont notice their functions.

[spoiler]<FrameLimiter>
<SyncFrameLimiter>
<FastSwitch>[/spoiler]