Messages

[Update:]

Update:

[spoiler=SCRIPTS]
Properties:
Player.SecWorld <-- [Int] Contrary to what the VC:MP Wiki would've alluded to, SecWorld is not unique to a player, all players still have access to objects/pickups that exist in any world. For other players to see what you can see in SecWorld, they merely need to be set to the same SecWorld ID as the object/pickup.

The desync that is possible with SecWorld however can create a unique scenario. If let's say player A loaded a wall in SecWorld for himself, other players are not able to see nor interact with this wall can walk through it no problem but their shots will not register as the shots on player A's screen are interacting with the object that is loaded.

On the other side, player A cannot walk through the object if it has collision but they can actually shoot the other players dead regardless. It will look like he's just shooting the wall but the shots do register out to the other end as no object is on screen for the other player.

Player.FPS <-- [Float] The frame-rate issued by this property has a delayed change of 4 to 12 seconds. Therefore when sampling someone's frame-rate, it is recommended to do an averaging of the results, of which is very accurate to the averaging of real-time FPS sampling.

Player.Speed <-- [Vector] This property definitely doesn't work when the player is in a vehicle, and should not be mistaken as a general property to report the player's displacement

If you were to use Player.Speed to report velocity of a player on foot, then there is an approximate 22 - 24 ms (millisecond) of sampling time. This was done on Squirrel platform, Java scripts may report a different finding.
[/spoiler]

I've realized that my VC:MP Scripting Book is proving difficult to get done in a timely fashion

You stole my idea REEEEE (/s)

Anyways how much pages does the book have?

Lol quite a bit actually, 56 pages to be exact.

I've covered:

• Basic server files and executable setup
• All events and server settings
• Most of the functions, methods and properties (even the ones that were on wiki with no explanation or link) and my personal notes on how they work and what to do and not to do with them
• Was starting up explaining the game files that define objects and the game world (IDE, IPL, TXD, COL, DAT etc.)
• My object and physics findings thus far
• Appendix with Car colour IDs, animation and animation group IDs. To include all reference IDs (so vehicle IDs, player skin IDs, announce text codes etc.)

Even the post Xmair made the other day on how to create plugins, that was originally done for my sake and the Scripting book but I took too long to  publish and he gave up on me and posted here lol

[Properties:]

Update:

[spoiler=SCRIPTS]
Properties:
Player.Frozen <-- [Bool] Sets the player in a frozen state where they cannot move.

This property does not change upon death, and so while the player will have control to respawn, they will spawn frozen. Simply add "player.Frozen = false" into the onPlayerSpawn() event to prevent this issue in your scripts.

Other:
[$FF] and [$80] are text codes you can use to overwrite colours of text in the chat.
Example:

Code Select Expand

::Message("[#ff0000]test[$80]"+ msg);The [$80] portion will negate any colour changes in the msg variable.

Credits to vito for pointing these out to me.
[/spoiler]

[spoiler=MINIMAP]
Note: This needs more validation.

As some of you know, the minimap is based on a 8 x 8 grid array of images that are 128 x 128 pixels. It is unknown to me if this was inherently a GTA Vice City problem or if its VC:MP related, but when you try to get to the map's North and Western edge, the first column and row glitches out. It doesn't show with the normal game as easily because the edges are sea images.

What this causes is a push down of the image grid array of one row and one column of tile width (128 pixels) of the North and West coordinates. And so, in drawing a custom map or in utilizing other maps (GTA:SA for example), you may need to accommodate for this by offsetting the drawn map 128 pixels left and up from its proper alignment.

More investigation needed.
[/spoiler]

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

I hear ya, thank you for that. In the next minor update then or so, we all looking forward to this change

@Stormeus your input please, topic seems buried in time

What you're trying to achieve can be done by creating some left over object pieces, removing the wall on explosion and using object.MoveTo & object.RotateTo on the custom left over object pieces. Or you can use the glass flag property on a custom object and treat it as a wall. It will however break when it is fired with any gun and not just explosives.

About the suggestion, I don't think it is possible as someone else (probably strummus) already explained that the server does not have any physics, only the client does.

To answer the first point, the idea was to let the game handle the physics of the object pieces, as doing object.MoveTo and object.Rotate is a whole lot of work that still won't come out particularly "accurate" to the context of any given scenario of a scene. So for example, the direction of a blast that would push the pieces one way versus another, the floor beneath, all of that I'd have to tediously account for. That window breaking flag is not direction I want to go.

That 2nd point, I'm having a hard time understanding why not. I'm not asking for the server to run the physics, I'm asking for it not to ignore the object properties so say for example an in-game object, explosive barrel, sync issues aside, if I do CreateObject() on its model ID, I'm expecting that object to blow up if I shoot at it, so the only thing the server did, was just to load and move that object into my presence, but the game did the rest of its "natural" work, accounting for the object properties present in the client's object.dat.

Even closer to home, just like how your player runs, shoots and jumps off a roof, its the client's game handling all of that processing, not the server right? Server only syncing the actions. We can teleport players via script all over the map etc. The same of vehicles, both dynamic objects. So if all that's so, why can't objects loaded by script be done in the same fashion, i.e. properly treat it for what it is. I'm having a hard time seeing the impossibility

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?

Thanks for the feedback. I'll soon test that and update

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.

[UPDATE:]

UPDATE:

• Fixed an issue where plugin would not export any rotational values unless the object was set to Quaternion Rotation Mode beforehand in the 3D View Window.

Simply re-download the updated plugin, and overwrite the previous version upon installing in Blender.

[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

[absolutely shocked]

Stormeus, and in extension whoever else makes up the dev team, I think you need an outside perspective.

Now I'm no coder but I started getting real serious about custom 3D model design (building something from scratch) recently along with utilizing my graphic design skill set as it would regards to GUI and map development. My aspiration is to finish my project of building from scratch an entirely new city, new world, new sandbox to play on. Hell the next Vice War in December is a spin-off project of this main one. The drive is there for me to give back to the community to be able to can push this kind of material for themselves, to know what to do as we can all agree this part of the 0.4 update has been half-wasted potential. Not much 3D designers around.

Now I mention this to point out as an outsider coming in with a passion, when I speak to Shadow, SLC, Seby, vito, Doom_Kill3R, Drake and NewK for advice around this, you can sense the level of resentment they have to the dev team. I look at the myriad of contributions SLC made here, idk the history but I was absolutely astonished to find out that he is not apart of the development team, absolutely shocked. The dev body has its reasons I'm sure, always multiple sides to a story but as far as my eyes can see, speaking bluntly here, someone made a stupid decision, straight up. And the worse part is it's like for some reason he's not being heard, he's giving so much and the higher body doesn't care much for it, just challenge and dismiss him to a discouraging degree in my opinion. It is so bizarre to me. Did he do something? I don't know but the community praises his efforts here; his work speaks for itself. Kudos to him for being around so long, for putting up with all that wall action against him.

Then, I look at some projects Shadow has tried and even some advice he's given me and I could pick it up early that Shadow is one of those persons that aspired (if not still aspire) to create some useful mods to VC, things missing in the original game like a GPS system out of the map world. I can't recall if that was a project for him but he seems like the kind of person that would try that kinda thing, add to the capability of VC:MP in some useful and interesting ways and you know what I noticed? He just gets shut down and that's the end of that. The dev team killed his horse and he can't revive it. Doom_Kill3R it's the same thing but from a different angle (I was speaking to him about GUI related stuff), and to this day I haven't seen him say a single thing good about the direction the GUI code opted to take.

Again, multiple sides to a story so I don't want to be closed-minded to hold the wrong conclusion but what I'm picking up here is that in this section of VC:MP, we have passionate creative people having their dreams destroyed because more often that not, the dev team issued a blind eye and deaf ear to the community. So whoever steps up and wants to continue development for VC:MP, forget about busy lives and time constraints, think about the union and relationships we have as a community first.

Whatever happened before shouldn't matter. Start on a clean slate where the developers are hearing the needs of the creators and the creators are appreciating the efforts of the developers. Whatever system you had that threatens this now, get rid of it. The community will get a lot farther than it is right now if we all strive for good relations.

@GangstaRas for coordinates

Code Select Expand

X: -830.4599999999998
Y: 1077.4720000000002

The above procedure gives
51th section not the correct one.

Similarly

Code Select Expand

X: -1145.75
Y: 156.719
Gives 37th section but the actual one is 25th section.

Thanks for the headsup. It would appear that my counting is what screwed it up, the very thing I tried to avoid lol.  Count the spaces, forget what I said about the lines (kept thing in my head that 512/128 = 5 when I just said the map is divided into 8 pieces, so its 4 not 5, brainfart moment, it happens) that caused the issue, If you do that you will get the correct answers for both.

The 37th you got was actually suppose to be 34th (that's what I got), if you move one step left and one step up, you will see that you get the correct position which is the 25th. Similarly, with the 51st image, move one step up and one step left and you should get 42nd image as the correct one. Sorry for the mixup. Updated my original post with the fix

[1st row - 00 to 072nd row - 08 to 153rd row - 16 to 234th row - 24 to 315th row - 32 to 396th row - 40 to 477th row - 48 to 558th row - 56 to 63]

The entirety of the map with all 64 PNGs (00 to 63) equates to a resolution of 1024x1024, that means the map is divided into 8 rows and 8 columns (at 128x128 resolution). So from the top of the map to the bottom:

1st row -  00 to 07
2nd row - 08 to 15
3rd row -  16 to 23
4th row -  24 to 31
5th row -  32 to 39
6th row -  40 to 47
7th row -  48 to 55
8th row -  56 to 63

Now with your image editor of choice (I use GIMP), if you grid the image with rulers into 8 equal parts on the x and the y axis, the full map is now setup to have each of these individual sections. A result like this:



That would give you a general idea of the positioning of where you want to be. Now for the accuracy to get things exact (involves some maths):

The landscape of Vice City is 3900 m x 3900 m (in game units), with the coordinate range setup a specific way for the x and y axis:

X axis = -2350 to 1550
Y axis = -1950 to 1950

Whatever object you look at in Moo Mapper or MEd or KEd, the coordinates of the object will always fall within those X and Y boundaries. Anything that exceeds those boundaries is not on the map, it will be shown in-game but it cannot be accessed by the player. How you would translate this onto the map you're drawing is as follows:

1. Get the coordinate of whatever object you're referencing
- for example sake, let's say the ingame object has a coordinate of 540, 260

2. Calculate the position of the object in percentage
- This is the make or break step that determines whether things will work out moving forward

To calculate the percentage properly, you need to regard the layout of the boundaries. The X axis starts at coordinate -2350, NOT 0. Therefore, you have to calculate that 540 coordinate in relation to -2350, the starting point, and the total range, which is 3900. Forget the ending point of the X axis (1550) for now, it only proves that the total range is 3900.

So, position in percentage (X axis):

[ object coordinate - starting point ] / 3900 x 100%
[ 540 - (-2350) ] / 3900 x 100%
2890 / 3900 x 100%
= 74.10%

You do the same with the Y axis and its respective range and coordinates, so you should get:

[ 260 - (-1950) ] / 3900 x 100%
2210 / 3900 x 100%
= 56.66%


3. Apply these percentages to the pixel coordinates of your image in your image editor
- This is the final step to draw the position accurately onto your radar map

You take the respective X and Y axis percentage value and multiply it against the respective X and Y axis full image resolution, which is 1024 x 1024, NOT the little radar squares from the grid which is 128x128. Don't care about them as yet.

So the position to draw the point is:

74.10% / 100% x 1024 (X axis) = 758.784 = 759   (rounded to the nearest whole number)
56.66% / 100% x 1024 (Y axis) = 580.1984 = 580 (rounded to the nearest whole number)

Remember to round the numbers as there is no decimal pixel

So in your image editor, looking at the status bar to check where your cursor is currently located across the image, you draw your point or representation you'd like of the object on the map at 759 ,580 of the image.

From this coordinate you can also deduce which of the 64 images would likely be the one to edit and replace. This is done by dividing the respective X and Y coordinate by 128 pixels. So with this example you would get:

759 / 128 = 5.93 (X axis = column)
580 / 128 = 4.53 (Y axis = row)

Now with these numbers you need to count correctly. Count the image spaces not the grid lines. You should therefore get that this image lies in the 4th row and is the 5th image.

So, using the table I gave at the start, the 4th row means images 24 to 31 are the options, the 5th image in that row, is image 28, so you would be editing and replacing radar28 from this example.

Hope this helps, and any further questions on the matter, feel free to ask