Topics

[All experimental data presented was observed on the 0.4.6 update for VC:MP. Future updates may change some or all of these limitations and/or nuances.]

I've realized that my VC:MP Scripting Book is proving difficult to get done in a timely fashion, so I will share as much of the information that I have in this post for others to utilize.

I would also encourage that those of you willing to share your experiences, reply below to make this post a general thread of findings and limitations that are either in the scripting or the game engine itself as it pertains to handling custom 3D models, 2DFX and so on.

All experimental data presented was observed on the 0.4.6 update for VC:MP. Future updates may change some or all of these limitations and/or nuances.

With that said, let's begin:


[spoiler=SCRIPTS]
In my book on all of this, I would manually test every function/property stated to be available and even unavailable. This test was not exhaustive however, and so there is more data to be gathered. Most of these functions/properties have sufficient documentation and will not be mentioned here. Only undocumented behaviour about a function or property will stated here.

Methods:
Player.AddSpeed( velocity ) <-- [Vector] Accelerates a player towards the velocity coordinate set. Player MUST have an initial Z axis acceleration, i.e. they must already be in the air for the command to work as intended. If they are on the ground, then two commands must be compounded onto each other. One to get the player off the ground (a Z axis propulsion), then the other to move the player to your desired coordinate. Failure to do this will result in no movement (if there isn't a Z axis coordinate change in your values) or the Z axis coordinate alone will play out from your values.


Player.SetDrunkLevel( visuals, handling ) <-- [Int] Sets player in a drunken state. The player does not exit the drunken state when they die. It will appear as if they did because you visually do not see the state after death, but upon subsequent use of the command a second time, you will notice no response. Therefore, currently, it is good practice to remove the drunken state on player death manually "Player.SetDrunkLevel(0,0)" to not have this bug present itself when you run the command again.

Properties:
Player.AimDir <-- [Euler] Gets the angle of the player's aim from their last shot. AimDir does not use the X axis value (it is always between 0 and 180 degrees expressed in radians).

The Y axis value denotes the look up/down angle of the player in-game and has a range of -90 to 45 degrees expressed in radians.
The Z axis is used to denote the direction in the world the player is aiming with a range of -90 to 90 degrees. It has the following quadrant setup:

First Quadrant -->	North to West = 0 to 90 degrees expressed in radians
Second Quadrant -->	West to South = 90 to 0 degrees expressed in radians
Third Quadrant -->	South to East = 0 to -90 degrees expressed in radians
Fourth Quadrant -->	East to North = -90 to 0 degrees expressed in radians

Player.Angle <-- [Euler] Gets the current Z axis rotation of the player. It has a range of -180 degrees to 180 degrees expressed in radians. North is angle 0 degrees expressed in radians.
[/spoiler]

[spoiler=2DFX]
Lights:
Up to 48 lights will work as intended within the 300 m radius of the player. Work as intended means corona, light effect and casted light shadow will be displayed.

You can however have up to 56 lights being displayed within the 300 m radius of the player, however, the light shadow will only work for the first 48 lights.

The maximum range of the light's effect is 25 m for the player/pedestrians and 50 m for vehicles regardless setting. A tapering point of 22 m and 45 m respectively was observed.

The shadow light texture has a maximum range of 45 m along the ground and will begin to taper at around 35 m. The shadow light texture seems to disappear if the light source is 15m+ above the ground surface.

The corona of the light can be seen for the full 300 m range with a taper at around 280 m, typical of any object.
[/spoiler]

[spoiler=OBJECTS]
Currently, VC:MP cannot fully distinguish a unique object by its ID or name once loaded in game memory. The only distinction its able to make is through the differing file sizes of the DFF file. Not even if you place the objects in separate 7z file packages will help. Let's say you have an object where only a minor texture change differentiates the two. If you load the object whether by XML or script, it will display whichever object comes first in the object.xml listing. The workaround for this I have found are one of two ways:

• Export the DFF object using another plugin. This usually results in differing DFF sizes which will make things distinguishable by the game.
• Modify the DFF in such a way that the file size will not be the same between objects, such as deleting/adding some vertices/polygons.

[/spoiler]

[spoiler=PHYSICS]
There is A LOT about this topic that's left to be figured out and so what I have to say is nowhere near exhaustive. These are just some of my current findings around the subject as of writing. This section is crucial for anyone wanting to create a simulated experience (e.g. simulator-type racer game-mode).

Gravity:
The gravity of GTA Vice City is about 20.044 m/s². This was the deducted answer from experimenting with free-falling objects that are not subjected to air resistance (yes GTA Vice City has air resistance, so a normal free-fall won't get you this result, I'll tell you how when I get to that topic). This gravitational pull corresponds with the 0.008 default arbitrary value of the SetGravity function.

To achieve the real-world gravitational pull in-game, you must change this value to 0.003918. The SetGravity function for the most part is linear to achieve any gravitational pull you desire, but in truth, it is more accurate to say that it is probably pseudolinear. This may be due to floating-point limitations and/or frame rate limitations as the actual value needed to be 0.003914188785. The values highlighted in blue do not register; the red value appears to be the limit i.e. the least significant value that registers. While this is true, in practice I have found that 0.003915, 6 or 7 do not give any truly appreciable change in gravity.

And so, 0.003918 is used purely out of accuracy (it is +0.4% off the mark vs -0.11% off the mark with 0.003914).

Air Resistance:
I am not quite done with this topic. The physics here is a little beyond me to get things lined up to how it works in-game but I will explain what I did figure out nonetheless.

Air resistance is on every dynamic object of the game i.e. the player and vehicles. At first in doing the free-falling test, I was solely testing for the gravity. If there is no air resistance, no property of the object matters (weight, dimensions, shape etc.) when it comes to the time taken for an object to fall from a set distance. In testing out different objects, I noticed that they were falling at different rates, making my gravity testing useless at first. I then had my eureka moment and changed a vehicle's dimensions such that it was all 0 m or very close to it for each dimensional axes. In doing this I was able to capture the gravitational pull accurately from a 10,000 m free-fall (45.2 seconds at 1 g (0.003918) of gravity if you want to try it yourself). So the goal was now to figure out what are the settings of the air resistance to be able to accurately predict the falling rate of any object (and to even deduce what the player's weight is as well).

This is where I got stuck but I do have some notable findings:

• Air resistance in-game is only dependent on the X and Z dimensional values. The Y value will not change the result of the free-fall time
• The heavier the object, the longer it takes to hit terminal velocity and the faster that terminal velocity will be. Inversely, the lighter the object, the quicker it hits terminal velocity and the slower that terminal velocity will be

It is unlikely that the game is actively calculating what the velocity of an object should be as it is falling, so therefore, it must be grabbing onto known constant values that affect air resistance, those probably being the weight of the object, the gravity and the dimensions of the object and come up with a value beforehand. This information may then be applied to a formula that represents the curvature of the deceleration of the object as it hits terminal velocity due to air resistance.

It is likely that that formula is V_T = tanh(g * t /V_T)

• V_T - terminal velocity
• tanh - hyperbolic tangent function
• g - gravity
• t - elapsed time

This formula however has absolutely no variable that makes each object's free-fall speed different. And so while this will generate the quickest curve suitable for in-game real-time processing, another formula for V_T is needed. I hypothesized that that formula would be this:

V_T = sqrt(2 * m * g / [p * A * C_d])

• V_T - terminal velocity
• m - mass of the object
• g - gravity
• p - density of the air
• A - cross sectional area of the object (probably X axis * Z axis / 2)
• C_d - drag coefficient of the object

We could hypothesize that for the density of the air, the constant the game could be using is 1.2-1.225 kg/m³, this however still makes the drag coefficient a mystery. All calculations for the drag coefficient that I'm able to find revolves around transposing this second formula for terminal velocity, which means this hypothesis is starting to look shakey.

From data gathered through testing, there are some other relationships that I was able to establish that might provide some clues:

• For every 8x increase in weight, there's a 2x increase in terminal velocity
• For every 4x decrease in dimensional values, there's a 2x increase in terminal velocity

[/spoiler]

It's as the title says, unless I missed something, I would like the capability to properly load dynamic objects via the script.

Currently, AFAIK if you use CreateObject(), you lose all the physically interactive settings set forth in XML, and thereby have yourself a static object. Idk if it applies for every dynamic setting but my interest lies in the physics aspect.

What do I hope to accomplish? Bringing destructive physics to VC:MP to do stuff like this:

https://youtu.be/r9DcsuOPVf8?t=00m10s

But I need the control from the available functions for this. So, is it doable?

Dusting off this area of VC:MP as I have some use cases for it.

A problem I'm noticing is that once you interact with a custom object with physics data, it just falls through the map and I don't really know why. Any fix to this? Happens whether it's vanilla map or custom map. Also happens when you place another physically active object beneath it to potentially collide with (in the hope of a physically active-passive object interaction).


Another thing I noticed, was that whether I spawned a custom object with physics data via script or a VC object via script, it loses its interaction capabilities. Maybe I'm doing something wrong? I used object ID 349 to check.

[Blender XML Exporter]

Blender XML Exporter

For those of you looking to develop custom maps for VC:MP, the scale of islands and cities, I've made the process a little easier if you're using Blender. With this rudimentary plugin, you can now directly export the XML mapping data of all objects within your scene in Blender.

So for example:



This scene of an island has almost 2,300 objects, as denoted in the top-right. Quite the hell to record all these coordinates manually. With this plugin, it will generate the xml data of all these objects' coordinates and axes rotations and compile it into one XML file that you put into your maps folder for your server. For the curious, the result of this export looks like this:


Installation:


Download the attached plugin then open Blender. In Blender, go to File > User Preferences (Ctrl + Alt + U) and click on the 'Addons' tab where you will see a button at the bottom of the window that says "Install Addon from file". From there, search for the directory you downloaded this plugin to, and click the python script to install.

Ensure that you enable the plugin by typing 'output' in the search bar at the top left under the 'Addons' tab. The plugin should show up named as "VC:MP Output to XML". Simply click the checkbox to enable. You should see a tick within the box if all is successful.

To use the function, in the open scene, hit Spacebar to bring up the universal searcher and type in 'output' where you should see "Export: Output to XML". Click on this and output to the directory you see fit. The XML file will be called "map.xml" once exported.


Features:

• Exports coordinates directly from Blender's scene coordinates (ensure that you are within VC:MP limits when creating your scenes)
  
  • X - -2350 to 1550
  • Y - -1950 to 1950
• Automatically exports the quaternion rotation data needed by XML mapping (work in Euler angles in Blender and don't worry about it, if you don't understand what I'm saying here, don't worry about it )
• Ensures that multiple copies of the same object are given the same ID number (essential for massive exports like these)

Limitations:

• Currently only exports meshes. You can edit the plugin to add support to export other object types; a UI based system in Blender to easily change these settings have not been made yet.
• No assigning of object IDs per object. So you will have to use the old fashion way of opening the XML document, finding a particular ID value and do Replace All, so that it matches with your ID setup in your objects.xml

Compatibility

Tested on Blender 2.79. Should work for any of the 2.7 versions, unsure if it would work with Blender 2.80 beta.

Credits:

Thanks to Thijn for creating the plugin to help me out. Grateful for his contribution. Thanks to Drake and Thomas for active support in helping me make changes and necessary fixes to the plugin to ensure maximum capability and compatibility with VC:MP.

Fun Fact:

Not sure if it's documented anywhere but VC:MP does have an object limit with XML objects as well. Through our testing, you can go as high as approximately 13,222 objects

As I aspire to create a new map from scratch, it would be good for me to get an understanding of 2dfx but of the limited illustrations of work I've seen here, I don't see anything regarding how to even mess with it, what am I looking for in whichever files and how to add it to custom objects etc. To those that know about 2dfx, could you please explain to me how to get started?

Newbie scripter here and coder in general so bare with me.

I've been perusing through the wiki and also here on functions I'd want to use for a server I'm trying to make. I'm however greeted with the 'does not exist' error message to practically everything. Example this:

Code Select Expand

mySprite <- null;
 
function Script::ScriptLoad()
{
     mySprite = GUISprite("Filename.png", VectorScreen(x, y));
}
Tried it, put it in client main.nut script in script folder, errors out that Script does not exist. Or say I do something like this:

Code Select Expand

CreateCheckpoint( null, 0, false, player.Pos, RGB(255, 0, 255), 2);
Put it in server-side script. The function doesn't exist.

I was under the impression that everything in the wiki or what's being said here is as easy as type the example and you're done, you should get something in-game. This is providing that you've harnessed all the plugins and declared their use in server.cfg. But these errors are throwing me off.

Is there something wrong on my end? Libraries not working or something? Or is it expected of me to define these functions. And if its expected of me to do such, how do these functions work with all these arguments in the syntax yet nothing in the function to process and if I'm to do that, why the wiki there saying those cuz basically you're free to make it any shit you like out of those function names, arguments and all and....yeah confused

[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?

[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]

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.

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?

This is part of my work I was talking about in SLC's video tutorial for scripting topic. What I have so far is a basic run-through of the capabilities of Squirrel language and a detailed description in layman's terms of:

• The ideal layout of files and folders
• Files necessary for a server
• Brief review of the importance of:
  
  • server.cfg
  • server.conf
  • server.exe
  • main.nut
  • plugin DLLs
• Detailed review of the each setting from the templates of server.cfg, server.conf and main.nut (the ones I don't have any experience in are labelled TBD/TBFD i.e. to be deduced/to be fully deduced)

Some of these things I have no info on I see them on the wiki has so I'll fill it in from there once I get to it. I plan to include a scripting guide that will incorporate my experiences with functions not detailed in the wiki currently (or outdated depending on where you search) and the info on the ones that are on the wiki.

Also I'll have an index on the IDs (with their pics ofcourse) of vehicles, objects, pickups and the skins and eventually compile this file into a PDF file with the bookmarks but for now, in this word document you can easily navigate to each heading in the navigation pane.

Anyone willing to read it and help out the cause please do as I wouldn't want to officially publish something full of wrong info and 98% of this so far is totally from my experience and understanding.

Download Link:
http://www.2shared.com/file/0G3mwI1K/Concise_Review_of_VCMP_Scripti.html

I have a strange idea with this one, in fact maybe it's not even practical but it's worth gathering some opinions. Do you guys think it's possible to make like a movie mode where a client to the server could capture something based on pretty much how replays work (tracking user input and the IDs of cars and skin classes of everything around him) and whatever we record we could either spit this file back to the user or let the server also store a copy since files of these nature should be very small.

The other thing is implementing something similar to what GTA5 (but by no means on the same level), making the mode sort of like a separate world for participants with camera control for the Editor. I may be misguided here but I read something about the world settings that if you set it to a particular number it influences what is visible to everyone versus what is visible to a common group versus what is visible to an individual only. Is that correct? Would be great for pulling off something like this as well as other multimode events for servers without being disturbed from the things around them.

The idea is that certain vehicle IDs receive less damage from weapons than others. the first approach I did was to increase vehicle.Health past 1000 but that didn't work, looks like 1000 is the max allowed. My next thought would be to manipulate what I found to be a damage multipler for weapons on cars. Each weapon seems to do 3x the damage it would do hitting another player. Is it possible to manipulate this in script and individualize it to the vehicle ID i want? If not, I'm open to suggestions on how I would go about coding this idea.

I have already read the previous report on it http://forum.vc-mp.org/?topic=202.msg1048#msg1048http://forum.vc-mp.org/?topic=202.msg1048#msg1048 but unfortunately he had a VCMP error message. I'm having the "The application was unable to start correctly" message instead as Thijn differentiated in that previous topic. I've tried just about everything to solve this, I made sure Visual C++ 2013 32 and 64 bit were installed, that didn't help so I continued installing earlier versions until I was all the way back to 2005's set, still nothing. I'm just about ready to screw up my .NET Framework because idk what this program needs right about now.

I'm on Windows 8.1 64 bit.

I wrote this code to fix a bug I found in server.conf where after a certain value input for ammo for each spawnwep per respective skin, it didn't represent it well (like putting in 500 for ammo amount gives back 244 ammo in the game, 9999 gave back 100 and something if I remember correctly).

Code Select Expand

function onPlayerSpawn (player)
{
        //Ammo Correction for President's Skin; working but bugged
if (skin == 56)
{
player.GiveWeapon(18,9999);
}

//Ammo Correction for Vice's Skin; working but bugged
if (skin == 52)
{
player.GiveWeapon(17,9999);
}

//Ammo Correction for Security Skins; working but bugged
if (skin == 102 || 104 || 130 || 21 || 67)
{
player.GiveWeapon(21,9999);
player.GiveWeapon(25,9999);
player.GiveWeapon(26,9999);
}

//Ammo Correction for Police Skins; working but bugged
if (skin == 1 || 2 || 3 || 68)
{
player.GiveWeapon(18,9999);
player.GiveWeapon(24,9999);
player.GiveWeapon(26,9999);
}

//Ammo Correction for Terrorist's Skins; working but bugged
if (skin == 11 || 48 || 51 || 87 || 90 || 95 || 96 || 146 || 147 || 153)
{
player.GiveWeapon(20,9999);
player.GiveWeapon(22,9999);
player.GiveWeapon(32,9999);
}
}
This code I have works in that the weapons are given and the correct ammo is too but the bug I found was that the Python, Tec9, M4 and M60 is being distributed to every skin. Irrespective of whatever spawnwep I have set whether in the script or in server.conf, the respective weapon slots are overwritten (so like for President's skin which is to be only the Golf Club and Python, it is now Golf Club (stays as no weapon clashes this), Python, Tec9, M4 and M60)

So any suggestions to fix this up? I'm thinking its maybe too many OR operators but I don't want to go the lengthy route if there's something easier that could be done here.

So I was studying the code of other scripts and I managed to figure out some things today regarding printing out stuff in the console when the script is loaded. But when I try to get something printed ingame, the headaches are back.

I'm trying to print this simple line:

Code Select Expand

function onPlayerJoin( player )
{
MessagePlayer("Welcome to the server!");
}
But all I get is an error saying its the wrong number of parameters.

Please Note: I'm 100% fresh to the scripting world and generally fresh to the programming world (C++ that is) so to some things I may say like I know it, I assure you, guidance may be needed everywhere so please bare with me.

Okay so I saw a post by Stormeus explaining that C++ is usable due to plugin SDKs available so that you can make your own plugin. From my presumption, it would appear that I'd have to get some IDE type program that is able to compile a dll file with the specified header details and input the C++ function library in it to make it work as a plugin ready for use with server.exe. But if it was that "simple" then where's a sample dll for something like this? Something called c++04rel64.dll or something if I'm having the right idea behind all this? Or is that if I make write a set of functions right now in C++ style and save it as main.nut everything works.

Being a beginner is not bliss. Someone please clarify C++ support and 0.4 and the steps necessary for it to work if any with me please. A lot of the processes behind getting into scripting isn't really in layman's terms.

The idea here is to split the entirety of gta vc map into 5 different sets, 4 of them are chunks of the map and 1 is the entire map itself. The full map one might need a workaround maybe after establishing boundaries (a map on top of a map I presume?) but what about the 4 chunks, is it possible to set multiple boundaries on the map and interchangeably spawn to them?