So you have further checks for finding nearby peds. Those. if the ped is not found, it returns to this label. And so a delay of 0 seconds can sooner or later turn into a huge period of time during which models can be unloaded by another script.
So I repeat for the umpteenth time: the approach “it doesn’t crash for me, so it’s normal” is wrong. It may not cause problems for you simply because of a combination of circumstances. The other player will have different circumstances. So all this needs to be taken into account. And constantly improve your scripts.
Rather, I dreamed, because these are the basic rules for writing scripts. There can't be "if" without "else_jump", just like vice versa. And inside this construction there are always conditional opcodes, and not ordinary command ones.
It's almost nice, but this is where the extra "if and" came from somewhere. There is only one condition further, so there should be a single "if". And, accordingly, “else_jump” is missing after the condition. But in general, the conditions are basically wrong and superfluous, so it's better to delete both lines altogether. And a little higher, on the contrary, is extra "else_jump" stuck for no reason. Well, another tip: upload models only when you have already found the “killer” and are ready to work with him. Because otherwise there will again be a pause of indefinite length between the moment the model is loaded and the moment when the killer is found and you will perform operations with him (issue weapons). And the pauses between loading and using, as you remember, are the risk that during this time the model can be unloaded by some other script. So it's better to schedule the script in such a way that there are no pauses at all between loading the model and using it.
Despite the difficulties this year, try to remember at least 10 things that happened in 2020 for which you are grateful. A proven Buddhist way to help you get distracted if there is too much negativity.
People here are posting various assumptions that I agree with to varying degrees, but you shouldn't completely deny the actual possible connection of these files with GTA 6.
The game could well have been in development at the time RDR2 was released. Parallel development is a very common thing in big studios. You don't need to go far with all sorts of TLOU2 and Cyberpunk 2077 - the same RDR2 has started to be developed right after the first RDR, i.e. in parallel with GTA5, and quite possibly parallel with GTA 6. As for the residual files or code in the builds of different games from one studio on the same engine, this is also not a new thing. Again - no need to go far: Max Payne 3 had so much "leftover trash" from GTA that the modders they are still organizing a local bacchanalia there.
Therefore, I do not understand those who, in all seriousness, are skeptical about the news (I approve of the rofl).
It's a very strange decision to spawn robbers in the passenger seats of the car they want to rob, but okay. The main problem that still remains in your scripts is that you load models, and then you wait a lot of time before spawning them, and you don’t even check if they are loaded at that moment. During these 30 seconds, some other standard or custom script may accidentally unload these models. You need to load/check models right before spawn, not a lot of time before.
Here. This trick with 16@ is already much better. It remains to check the workload of the models every time before spawning - and it will be almost perfect.
Dude, use the same nickname as your profile here in authors, case-sensitive. So far, this is the only way to get into the "author's". Later they promised to add a tick "I am the author".
A bug that, even after changing the author columns by the checker, does not display the mod in the author list. At the moment, the site has a not entirely successful system, due to which the mod gets into the "author" only if the list of authors contains the nickname of the uploader. It's not a great option. The administration said that adding a checkmark "I am the author" when uploading a file is in the plans, but until then this feature must be taken into account.
The mod is cool, but did not receive due attention due to the fact that your nickname used on the site was not in the list of authors. You need to either change the nickname on the site, or specify the current one in the authors so that the mods get into the "author" and get more attention.
Wow! Really cool and well thought out! Only apparently because of a bug it did not get into the "author's mods". Indicate in the authors the same nickname as your profile here. Until the problem is fixed - this is the only way to get into the "author's".
When compiling, your global variables are reset by ID, starting from the beginning. Those. you begin to influence the global variables of the main, that's all. And from here - bugs and problems in the future. But the worst thing is that these problems will be saved in the save file, because. all global variables are stored there. Those. and after deleting your script, people will still have these problems if they managed to make a save with your script. That's why everyone is "afraid" of global variables in CLEO.
By the way, there is an easier mission with a helicopter at the airport. You can start with it and just train the nerves of the players Although... in that mission, people had a snag only because of the uncomfortable keyboard layout (not everyone immediately guessed how to change it), and in GTA IV, the default layout is already normal.
Well, at least some argument, already pleases. But nit-picking, of course, is so-so ... oh, it turned out that there is only one of them!
Working with sound in it is just “wow” - the only, as I understand it, claim? Well, there are no perfect things, especially if we are talking about works made for fun, and not for big studio money. The author squeezed the maximum out of his possibilities.
But because of the not quite perfect sound, write "feces"? Some kindergarten. For voiceovers, the quality is quite good. Plus, in the appendage is an adequate translation. I have already written above where the "enthusiasm" comes from. If you personally are not interested in voiceovers - pass by, don't stink. For such comments are feces.
Sorry for the late reply - the comment system is not very convenient. In general, as stated in the video - the chance of releasing the full version is extremely low, because. initially it was part of the global Lost City mod and was sharpened strictly for it. Then that mod died for natural reasons (did not reflect my current capabilities and ambitions) and that shooting system along with it. BUT! 1) A similar mod was made by ThirteenAG, like this is the latest version. This is not exactly what I planned to do, but it is also quite good for those years. 2) I'm working on a new animation system for my big project, where there will be a normal modern system of movement and interaction with weapons (I hope everything works out). So there is still a chance of some releases in this direction from me, but I can’t promise (maybe the result will also be an indivisible thing that cannot be adequately cut off from the mod - I don’t know how it will turn out yet).
Do you know what voiceover is and how it differs from dubbing? And what is it for? If you don't need it, then speak for yourself, and this voice acting is currently the best that exists in the real world, and not the fantasies of Internet aesthetes. And what "interesting ideas" are we talking about? An example is possible? In my opinion, an attempt to make a normal two-voice voiceover with some kind of emotionality (do not imagine that it is not here) and a normal translation is already an interesting idea, hence the hype you mentioned. If you think it's unoriginal, "secondary" and "mediocre" are examples of the best voice acting in the studio.
Of course, there is not much that can compare with the original English, but by saying that this Russian voice acting is “feces”, can you specify what this “feces” consists of? Or show an example where "no feces"? Or is it chatter into the void?
For now, write to the authors just "egor230", tk. the system does not yet track the author's files perfectly, and it does not associate the current "Egor Shcherbanov (egor230)" with your nickname, as a result of which it does not write the file to the copyright list. And a lot of people filtering only author files are missing out on work.
Rockstars used to "support" the community by sharing info (with the same MTA developers, for example), as well as all sorts of publications. Rage didn't find GTA III - a lot of water has flowed under the bridge (but you can ask the olds, I think at least some of them remember that incident), but I found it See the article on the port of the GTA 1 map on Rage... About GTA 3 Rage was similar. Sometimes they even noted purely fun projects... But Take2 doesn't care about that. With regards to the GTA SA port on UE4 - again: it's hard to say for sure without knowing the situation from the inside, but perhaps it has something to do with the UE4 license, which creates conflicts of rights. Still, this is not for you to flip cards inside the projects of one company. Plus, UE4 is a competitor. We cannot allow anything from the GTA world to look better on it than on Take2 engines (fans previously ported SA to Rage, and Take2 didn't care).
Rockstar don't care about envelopes, especially from old RW-GTA. And sometimes they even support it, like they did with GTA III Rage.
But Take2, Rokstarov's "mother", only cares about profit. And for that profit, some envelopes are dangerous. Therefore, they blocked the port "Liberty City in GTA V", as well as the port of the RDR card for the same GTA 5. It is difficult to say for sure, not knowing for sure the situation "from the inside", but, perhaps, Take2 did not want those mods to somehow influence on the sale of the reissue of GTA4 and the release of RDR2. Plus, those ports were on GTA 5, and for it Take2 has its own plans for now (now the whole island will be added to Online).
In the case of Vice City 2, we are talking about not the last part of GTA 4, to which the map is ported from an even older part of GTA. And even if the action of GTA 6 takes place in Vice City, this alignment is unlikely to have any effect on its sales.
There is nothing particularly critical, but pay attention to the following points: 1) There is no need to write "if and" before the opcodes of loading / unloading models. These are not conditions, you don't need to write "if" here. This superfluous construction may lead to an error another time. 2) No need to write "else_jump" after Don'tConditional opcodes, by the type of receiving a random number. This is not a condition, so you don't need to write "else_jump" here. This superfluous construction may lead to an error another time. 3) Study tutorials on streams. Now it turns out that you load models, wait a long time, create one actor, wait a while, create another, then wait again, create another, etc. and at the very end, after all the created actors, you unload the models. And immediately download them again, because the script is restarted. The current script may generate an error if it interacts with some other script or mission, where one of the models you have used is loading and unloading. you make huge pauses and don't check the load of the models in the process.
There is nothing particularly critical, but pay attention to the following points: 1) There is no need to write "if and" before the opcodes of loading / unloading models. These are not conditions, you don't need to write "if" here. This superfluous construction may lead to an error another time. 2) No need to write "else_jump" after Don'tConditional opcodes, by the type of receiving a random number. This is not a condition, so you don't need to write "else_jump" here. This superfluous construction may lead to an error another time. 3) Study tutorials on streams. Now it turns out that you load models, wait a long time, create one actor, wait a while, create another, then wait again, create another, etc. and at the very end, after all the created actors, you unload the models. And immediately download them again, because the script is restarted. The current script may generate an error if it interacts with some other script or mission, where one of the models you have used is loading and unloading. you make huge pauses and don't check the load of the models in the process.
There is nothing particularly critical, but pay attention to the following points: 1) There is no need to write "if and" before the opcodes of loading / unloading models. These are not conditions, you don't need to write "if" here. This superfluous construction may lead to an error another time. 2) No need to write "else_jump" after Don'tConditional opcodes, by the type of receiving a random number. This is not a condition, so you don't need to write "else_jump" here. This superfluous construction may lead to an error another time. 3) Study tutorials on streams. Now it turns out that you load models, wait a long time, create one actor, wait a while, create another, then wait again, create another, etc. and at the very end, after all the created actors, you unload the models. And immediately download them again, because the script is restarted. The current script may generate an error if it interacts with some other script or mission, where one of the models you have used is loading and unloading. you make huge pauses and don't check the load of the models in the process.
There is nothing particularly critical, but pay attention to the following points: 1) There is no need to write "if and" before the opcodes of loading / unloading models. These are not conditions, you don't need to write "if" here. This superfluous construction may lead to an error another time. 2) No need to write "else_jump" after Don'tConditional opcodes, by the type of receiving a random number. This is not a condition, so you don't need to write "else_jump" here. This superfluous construction may lead to an error another time. 3) Study tutorials on streams. Now it turns out that you load models, wait a long time, create one actor, wait a while, create another, then wait again, create another, etc. and at the very end, after all the created actors, you unload the models. And immediately download them again, because the script is restarted. The current script may generate an error if it interacts with some other script or mission, where one of the models you have used is loading and unloading. you make huge pauses and don't check the load of the models in the process.
I am not talking about that. The "delete script" advice is a good example of how such errors in scripts negatively affect the game in the long run. That the save is already irrevocably broken. And without deleting the script, it will be the same, and in some cases even worse.
There are no critical errors, but I will note something for the future: 1) "multithreading" can of course be reduced, since many things are repeated in labels (you can “jump” to a label that will be common to all). 2) Freeing memory at the end of the script (in case of death of the player or actor) is not necessary, since You still wrote all the actors into the same variable 4 @, and the opcode for searching for a random actor does not mark "non-deletion", which means that the actor will move away himself when he moves away from him or in case of death. 3) There is also no loading of the weapon model before issuing, by the way. Not critical, but sometimes it can also add problems. 4) About Don'tConditional opcodes (in this case - 04C4) in the center of the block of conditions - I already wrote earlier. https://i.gyazo.com/0707804ce20f01643193720451767655.png The block of conditions should contain only conditional opcodes (opcodes that check something, and do not perform any actions)
I have no goal to somehow spoil your mood or discourage others from downloading your mods. On the contrary. In my opinion, the sooner you start avoiding basic mistakes, the less chances people will associate your work with something of poor quality or even dangerous. Well, your own scripting will bring more buzz
People then put on some other mods, get crashes and blame these other mods for them. Or, in principle, they do not understand where these departures and other problems arise from. the problem is really insidious and difficult to predict. If you don’t believe me, do the experiment yourself. Create a pickup truck and save the game. Delete the script. Load this save. The pickup will stay where it is. Well, and purely logically - you understand that the place in the save file is not rubber, at some point the limit will be exceeded. And what will happen next - crashes or other errors - is already difficult to predict. But they will definitely be, the game has practically no protection against such errors. Some people generally create viruses based on the problem of lack of protection against such errors, this is a big problem in the game. I do not write under your every script, mind you. I understand that no one immediately becomes a professional scriptwriter. Even I, after 12 years of studying scripting, periodically discover something new for myself. The problem is that Rockstar didn't provide us modmakers with full documentation, which is why we have been studying the game on our own for many years. But there is much we do not know yet. That is why it is important to observe at least those nuances that are already known. Because there will still be mistakes. But this way there will be at least fewer of them.
People then put on some other mods, get crashes and blame these other mods for them. Or, in principle, they do not understand where these departures and other problems arise from. the problem is really insidious and difficult to predict. If you don’t believe me, do the experiment yourself. Create a pickup truck and save the game. Delete the script. Load this save. The pickup will stay where it is. Well, and purely logically - you understand that the place in the save file is not rubber, at some point the limit will be exceeded. And what will happen next - crashes or other errors - is already difficult to predict. But they will definitely be, the game has practically no protection against such errors. Some people generally create viruses based on the problem of lack of protection against such errors, this is a big problem in the game. I do not write under your every script, mind you. I understand that no one immediately becomes a professional scriptwriter. Even I, after 12 years of studying scripting, periodically discover something new for myself. The problem is that Rockstar didn't provide us modmakers with full documentation, which is why we have been studying the game on our own for many years. But there is much we do not know yet. That is why it is important to observe at least those nuances that are already known. Because there will still be mistakes. But this way there will be at least fewer of them.
People then put on some other mods, get crashes and blame these other mods for them. Or, in principle, they do not understand where these departures and other problems arise from. the problem is really insidious and difficult to predict. If you don’t believe me, do the experiment yourself. Create a pickup truck and save the game. Delete the script. Load this save. The pickup will stay where it is. Well, and purely logically - you understand that the place in the save file is not rubber, at some point the limit will be exceeded. And what will happen next - crashes or other errors - is already difficult to predict. But they will definitely be, the game has practically no protection against such errors. Some people generally create viruses based on the problem of lack of protection against such errors, this is a big problem in the game. I do not write under your every script, mind you. I understand that no one immediately becomes a professional scriptwriter. Even I, after 12 years of studying scripting, periodically discover something new for myself. The problem is that Rockstar didn't provide us modmakers with full documentation, which is why we have been studying the game on our own for many years. But there is much we do not know yet. That is why it is important to observe at least those nuances that are already known. Because there will still be mistakes. But this way there will be at least fewer of them.
People then put on some other mods, get crashes and blame these other mods for them. Or, in principle, they do not understand where these departures and other problems arise from. the problem is really insidious and difficult to predict. If you don’t believe me, do the experiment yourself. Create a pickup truck and save the game. Delete the script. Load this save. The pickup will stay where it is. Well, and purely logically - you understand that the place in the save file is not rubber, at some point the limit will be exceeded. And what will happen next - crashes or other errors - is already difficult to predict. But they will definitely be, the game has practically no protection against such errors. Some people generally create viruses based on the problem of lack of protection against such errors, this is a big problem in the game. I do not write under your every script, mind you. I understand that no one immediately becomes a professional scriptwriter. Even I, after 12 years of studying scripting, periodically discover something new for myself. The problem is that Rockstar didn't provide us modmakers with full documentation, which is why we have been studying the game on our own for many years. But there is much we do not know yet. That is why it is important to observe at least those nuances that are already known. Because there will still be mistakes. But this way there will be at least fewer of them.
The site really lacks the "I'm the author" checkbox. The mod uploaded the account egor230, and the "author" is Egor Shcherbanov, which is why the site does not rate this file as "author", and it receives less attention from users.
So you have further checks for finding nearby peds. Those. if the ped is not found, it returns to this label. And so a delay of 0 seconds can sooner or later turn into a huge period of time during which models can be unloaded by another script.
So I repeat for the umpteenth time: the approach “it doesn’t crash for me, so it’s normal” is wrong. It may not cause problems for you simply because of a combination of circumstances. The other player will have different circumstances. So all this needs to be taken into account. And constantly improve your scripts.
And a little higher, on the contrary, is
Well, another tip: upload models only when you have already found the “killer” and are ready to work with him. Because otherwise there will again be a pause of indefinite length between the moment the model is loaded and the moment when the killer is found and you will perform operations with him (issue weapons). And the pauses between loading and using, as you remember, are the risk that during this time the model can be unloaded by some other script. So it's better to schedule the script in such a way that there are no pauses at all between loading the model and using it.
Down with the unjust regime!
Anritool 202i
The game could well have been in development at the time RDR2 was released. Parallel development is a very common thing in big studios. You don't need to go far with all sorts of TLOU2 and Cyberpunk 2077 - the same RDR2 has started to be developed
As for the residual files or code in the builds of different games from one studio on the same engine, this is also not a new thing. Again - no need to go far: Max Payne 3 had so much "leftover trash" from GTA that the modders
Therefore, I do not understand those who, in all seriousness, are skeptical about the news (I approve of the rofl).
The main problem that still remains in your scripts is that you load models, and then you wait a lot of time before spawning them, and you don’t even check if they are loaded at that moment. During these 30 seconds, some other standard or custom script may accidentally unload these models.
You need to load/check models right before spawn, not a lot of time before.
So far, this is the only way to get into the "author's". Later they promised to add a tick "I am the author".
Until the problem is fixed - this is the only way to get into the "author's".
(using global variables)
And from here - bugs and problems in the future. But the worst thing is that these problems will be saved in the save file, because. all global variables are stored there. Those. and after deleting your script, people will still have these problems if they managed to make a save with your script.
That's why everyone is "afraid" of global variables in CLEO.
(using global variables)
(using global variables)
Although... in that mission, people had a snag only because of the uncomfortable keyboard layout (not everyone immediately guessed how to change it), and in GTA IV, the default layout is already normal.
Working with sound in it is just “wow” - the only, as I understand it, claim? Well, there are no perfect things, especially if we are talking about works made for fun, and not for big studio money. The author squeezed the maximum out of his possibilities.
But because of the not quite perfect sound, write "feces"? Some kindergarten.
For voiceovers, the quality is quite good. Plus, in the appendage is an adequate translation. I have already written above where the "enthusiasm" comes from. If you personally are not interested in voiceovers - pass by, don't stink. For such comments are feces.
1) A similar mod was made by ThirteenAG, like this is the latest version. This is not exactly what I planned to do, but it is also quite good for those years.
2) I'm working on a new animation system for my big project, where there will be a normal modern system of movement and interaction with weapons (I hope everything works out). So there is still a chance of some releases in this direction from me, but I can’t promise (maybe the result will also be an indivisible thing that cannot be adequately cut off from the mod - I don’t know how it will turn out yet).
If you don't need it, then speak for yourself, and this voice acting is currently the best that exists in the real world, and not the fantasies of Internet aesthetes.
And what "interesting ideas" are we talking about? An example is possible? In my opinion, an attempt to make a normal two-voice voiceover with some kind of emotionality (do not imagine that it is not here) and a normal translation is already an interesting idea, hence the hype you mentioned. If you think it's unoriginal, "secondary" and "mediocre" are examples of the best voice acting in the studio.
Rage didn't find GTA III - a lot of water has flowed under the bridge (but you can ask the olds, I think at least some of them remember that incident), but I found it
But Take2 doesn't care about that.
With regards to the GTA SA port on UE4 - again: it's hard to say for sure without knowing the situation from the inside, but perhaps it has something to do with the UE4 license, which creates conflicts of rights. Still, this is not for you to flip cards inside the projects of one company.
Plus, UE4 is a competitor. We cannot allow anything from the GTA world to look better on it than on Take2 engines (fans previously ported SA to Rage, and Take2 didn't care).
But Take2, Rokstarov's "mother", only cares about profit. And for that profit, some envelopes are dangerous. Therefore, they blocked the port "Liberty City in GTA V", as well as the port of the RDR card for the same GTA 5. It is difficult to say for sure, not knowing for sure the situation "from the inside", but, perhaps, Take2 did not want those mods to somehow influence on the sale of the reissue of GTA4 and the release of RDR2. Plus, those ports were on GTA 5, and for it Take2 has its own plans for now (now the whole island will be added to Online).
In the case of Vice City 2, we are talking about not the last part of GTA 4, to which the map is ported from an even older part of GTA. And even if the action of GTA 6 takes place in Vice City, this alignment is unlikely to have any effect on its sales.
1) There is no need to write "if and" before the opcodes of loading / unloading models. These are not conditions, you don't need to write "if" here. This superfluous construction may lead to an error another time.
2) No need to write "else_jump" after Don'tConditional opcodes, by the type of receiving a random number. This is not a condition, so you don't need to write "else_jump" here. This superfluous construction may lead to an error another time.
3) Study tutorials on streams. Now it turns out that you load models, wait a long time, create one actor, wait a while, create another, then wait again, create another, etc. and at the very end, after all the created actors, you unload the models. And immediately download them again, because the script is restarted.
The current script may generate an error if it interacts with some other script or mission, where one of the models you have used is loading and unloading. you make huge pauses and don't check the load of the models in the process.
1) There is no need to write "if and" before the opcodes of loading / unloading models. These are not conditions, you don't need to write "if" here. This superfluous construction may lead to an error another time.
2) No need to write "else_jump" after Don'tConditional opcodes, by the type of receiving a random number. This is not a condition, so you don't need to write "else_jump" here. This superfluous construction may lead to an error another time.
3) Study tutorials on streams. Now it turns out that you load models, wait a long time, create one actor, wait a while, create another, then wait again, create another, etc. and at the very end, after all the created actors, you unload the models. And immediately download them again, because the script is restarted.
The current script may generate an error if it interacts with some other script or mission, where one of the models you have used is loading and unloading. you make huge pauses and don't check the load of the models in the process.
1) There is no need to write "if and" before the opcodes of loading / unloading models. These are not conditions, you don't need to write "if" here. This superfluous construction may lead to an error another time.
2) No need to write "else_jump" after Don'tConditional opcodes, by the type of receiving a random number. This is not a condition, so you don't need to write "else_jump" here. This superfluous construction may lead to an error another time.
3) Study tutorials on streams. Now it turns out that you load models, wait a long time, create one actor, wait a while, create another, then wait again, create another, etc. and at the very end, after all the created actors, you unload the models. And immediately download them again, because the script is restarted.
The current script may generate an error if it interacts with some other script or mission, where one of the models you have used is loading and unloading. you make huge pauses and don't check the load of the models in the process.
1) There is no need to write "if and" before the opcodes of loading / unloading models. These are not conditions, you don't need to write "if" here. This superfluous construction may lead to an error another time.
2) No need to write "else_jump" after Don'tConditional opcodes, by the type of receiving a random number. This is not a condition, so you don't need to write "else_jump" here. This superfluous construction may lead to an error another time.
3) Study tutorials on streams. Now it turns out that you load models, wait a long time, create one actor, wait a while, create another, then wait again, create another, etc. and at the very end, after all the created actors, you unload the models. And immediately download them again, because the script is restarted.
The current script may generate an error if it interacts with some other script or mission, where one of the models you have used is loading and unloading. you make huge pauses and don't check the load of the models in the process.
And without deleting the script, it will be the same, and in some cases even worse.
1) "multithreading" can of course be reduced, since many things are repeated in labels (you can “jump” to a label that will be common to all).
2) Freeing memory at the end of the script (in case of death of the player or actor) is not necessary, since You still wrote all the actors into the same variable 4 @, and the opcode for searching for a random actor does not mark "non-deletion", which means that the actor will move away himself when he moves away from him or in case of death.
3) There is also no loading of the weapon model before issuing, by the way. Not critical, but sometimes it can also add problems.
4) About Don'tConditional opcodes (in this case - 04C4) in the center of the block of conditions - I already wrote earlier.
The block of conditions should contain only conditional opcodes (opcodes that check something, and do not perform any actions)
Well, your own scripting will bring more buzz
If you don’t believe me, do the experiment yourself. Create a pickup truck and save the game. Delete the script. Load this save. The pickup will stay where it is. Well, and purely logically - you understand that the place in the save file is not rubber, at some point the limit will be exceeded. And what will happen next - crashes or other errors - is already difficult to predict. But they will definitely be, the game has practically no protection against such errors.
Some people generally create viruses based on the problem of lack of protection against such errors, this is a big problem in the game.
I do not write under your every script, mind you. I understand that no one immediately becomes a professional scriptwriter. Even I, after 12 years of studying scripting, periodically discover something new for myself. The problem is that Rockstar didn't provide us modmakers with full documentation, which is why we have been studying the game on our own for many years. But there is much we do not know yet. That is why it is important to observe at least those nuances that are already known. Because there will still be mistakes. But this way there will be at least fewer of them.
If you don’t believe me, do the experiment yourself. Create a pickup truck and save the game. Delete the script. Load this save. The pickup will stay where it is. Well, and purely logically - you understand that the place in the save file is not rubber, at some point the limit will be exceeded. And what will happen next - crashes or other errors - is already difficult to predict. But they will definitely be, the game has practically no protection against such errors.
Some people generally create viruses based on the problem of lack of protection against such errors, this is a big problem in the game.
I do not write under your every script, mind you. I understand that no one immediately becomes a professional scriptwriter. Even I, after 12 years of studying scripting, periodically discover something new for myself. The problem is that Rockstar didn't provide us modmakers with full documentation, which is why we have been studying the game on our own for many years. But there is much we do not know yet. That is why it is important to observe at least those nuances that are already known. Because there will still be mistakes. But this way there will be at least fewer of them.
If you don’t believe me, do the experiment yourself. Create a pickup truck and save the game. Delete the script. Load this save. The pickup will stay where it is. Well, and purely logically - you understand that the place in the save file is not rubber, at some point the limit will be exceeded. And what will happen next - crashes or other errors - is already difficult to predict. But they will definitely be, the game has practically no protection against such errors.
Some people generally create viruses based on the problem of lack of protection against such errors, this is a big problem in the game.
I do not write under your every script, mind you. I understand that no one immediately becomes a professional scriptwriter. Even I, after 12 years of studying scripting, periodically discover something new for myself. The problem is that Rockstar didn't provide us modmakers with full documentation, which is why we have been studying the game on our own for many years. But there is much we do not know yet. That is why it is important to observe at least those nuances that are already known. Because there will still be mistakes. But this way there will be at least fewer of them.
If you don’t believe me, do the experiment yourself. Create a pickup truck and save the game. Delete the script. Load this save. The pickup will stay where it is. Well, and purely logically - you understand that the place in the save file is not rubber, at some point the limit will be exceeded. And what will happen next - crashes or other errors - is already difficult to predict. But they will definitely be, the game has practically no protection against such errors.
Some people generally create viruses based on the problem of lack of protection against such errors, this is a big problem in the game.
I do not write under your every script, mind you. I understand that no one immediately becomes a professional scriptwriter. Even I, after 12 years of studying scripting, periodically discover something new for myself. The problem is that Rockstar didn't provide us modmakers with full documentation, which is why we have been studying the game on our own for many years. But there is much we do not know yet. That is why it is important to observe at least those nuances that are already known. Because there will still be mistakes. But this way there will be at least fewer of them.
The mod uploaded the account egor230, and the "author" is Egor Shcherbanov, which is why the site does not rate this file as "author", and it receives less attention from users.