DYOM IX (Modification for DYOM)

[Halter]

Just now, Toriality said:

That's unfortunate. I really like this feature.

 

Does this also applies to car checkpoint?

Car Checkpoint seems to be very good. It only happens to Actors

[Halter]

DYOM IX 5.5 Beta

For test purposes

Please test new extended limits of routepoints, but not to do every of them to one Actor, cause it can cause a crash in the game. Try it separate them by different Actors

Download

Changelog

Spoiler

• Freeze disabled when setting time
• Added a feature in Settings to make all objects liftable
• Added 31 new Actor animations for vehicles (Better use in Player Animation in Objectives, before anim put Player in a Car)
• Extended routepoints limit to 799
• Added a feature in Settings to make all objects liftable
• Fixed 150 Health bar bug

 

[Guest]

14 minutes ago, Halter said:

 

  Hide contents

• Added 31 new Actor animations for vehicles (Better use in Player Animation in Objectives, before anim put Player in a Car)

 

 

- Can you specify the ID numbers of the animations? I'll test that one out

Edited May 12, 2022 by Horus Publishing

[Guest]

Nvm, tested it out.

 

Basically its a one big mess. Animations work, but if you want to place them - you can't place them by clicking "Space" like it always is for animations, instead you need to click "W" couple of times in order to work. Mission is crashing Fastman (i did exactly like you told - Teleport to Car, and then Player Animation). Idk maybe it should work like that (pressing "W" to accept anims) ?

Edited May 12, 2022 by Horus Publishing

[Halter]

20 minutes ago, Horus Publishing said:

Nvm, tested it out.

 

Basically its a one big mess. Animations work, but if you want to place them - you can't place them by clicking "Space" like it always is for animations, instead you need to click "W" couple of times in order to work. Mission is crashing Fastman (i did exactly like you told - Teleport to Car, and then Player Animation). Idk maybe it should work like that (pressing "W" to accept anims) ?

Dude that's a beta for testing, don't be so cruel. I'll check it out, so also check routepoints which are very important stuff. 

Edited May 12, 2022 by Halter

[Toriality]

I'm busy rn but in a few hours I'll also make some tests, this update seems interesting.

[Toriality]

What does Make object liftable do?

 

EDIT:

 

I wasn't able to test properly. It is crashing a lot, at least in my computer. Even the most basic routepoint testing is causing crashes (sometimes in editing too). Maybe you literally has reach a limit here, or maybe it was a error on the code.

Edited May 12, 2022 by Toriality

[Guest]

12 hours ago, Toriality said:

What does Make object liftable do?

 

 

Maybe something to do with objectives, revolving around lifting objects? Don't know, maybe something else. Btw, do you have the same problem like us, with anims in the car? If not then again its something weird  

Edited May 13, 2022 by Horus Publishing

[Guest]

Have you noticed, that if you'll turn on Objects tab, select any object then you see this?

 

Object & Effects text are broken. Also, @Toriality here's your answer for "Object Liftable": 

It is a new objective, so you can have Forklifts useful now. You just go to Objectives - Add Object (select object you want to lift) and select Lift Object. However, tested it out now and it doesn't seem to affect Forklift in any way - so still its unanswered how this feature really works.

Edited May 13, 2022 by Horus Publishing

[BobTheBot]

11 minutes ago, Horus Publishing said:

Have you noticed, that if you'll turn on Objects tab, select any object then you see this?

 

Object & Effects text are broken. Also, @Toriality here's your answer for "Object Liftable": 

It is a new objective, so you can have Forklifts useful now. You just go to Objectives - Add Object (select object you want to lift) and select Lift Object. However, tested it out now and it doesn't seem to affect Forklift in any way - so still its unanswered how this feature really works.

Maybe it's for missions like Burglary missions where you have to lift up some objects?

[Halter]

So friends, we have come to the point where we really wandered into the limit of everything. So I decided to make DYOM X from scratch, but it will not support missions with DYOM IX, this is due to the fact that, firstly, today's version has a bunch of unnecessary trash, such as a bunch of twitching animations, Hydraulics for cars that no one uses because on laptops, few people have num buttons to control, and there is not much sense from hydraulics. Plus, you have to constantly change the structure of the save and read datfiles, and this takes a certain amount of code in the end. In general, I think that this should be done and I need real testers, in discord, send me friend request (brassiere#9130). I will send versions and we will test. Just pushing all the features that people want is pointless, especially since these people then do not make a single mission with this feature. Therefore, starting from today, the development of DYOM IX has been stopped.

[Kailojado haddines]

1 Feature for the next update:

Follow actor

Edited May 13, 2022 by Kailojado haddines

[BobTheBot]

9 minutes ago, Halter said:

So friends, we have come to the point where we really wandered into the limit of everything. So I decided to make DYOM X from scratch, but it will not support missions with DYOM IX, this is due to the fact that, firstly, today's version has a bunch of unnecessary trash, such as a bunch of twitching animations, Hydraulics for cars that no one uses because on laptops, few people have num buttons to control, and there is not much sense from hydraulics. Plus, you have to constantly change the structure of the save and read datfiles, and this takes a certain amount of code in the end. In general, I think that this should be done and I need real testers, in discord, send me friend request (brassiere#9130). I will send versions and we will test. Just pushing all the features that people want is pointless, especially since these people then do not make a single mission with this feature. Therefore, starting from today, the development of DYOM IX has been stopped.

Can you make a discord server for DYOM X.. The communication will be easier and faster than GTAForums if you had like bugs channel for the bugs people faced during testing.. And if you want to upload beta versions for testing it'll be good to be on that Discord server.. Then launch the official versions here..

 

 

And another question.. Will DYOM X still use FM92 limit adjuster?

Edited May 13, 2022 by BobAyman

[Kailojado haddines]

Lift Object? Wow i like that, just like Robbing uncle sam, we'll be able to make that mission with this feature :LIFT OBJECT: Imagine lifting a submarine lol

16 hours ago, Halter said:

Extended routepoints limit to 799

WHAT?! THANKS!

Edited May 13, 2022 by Kailojado haddines
Change

[bessem ben]

23 minutes ago, Halter said:

So friends, we have come to the point where we really wandered into the limit of everything. So I decided to make DYOM X from scratch, but it will not support missions with DYOM IX, this is due to the fact that, firstly, today's version has a bunch of unnecessary trash, such as a bunch of twitching animations, Hydraulics for cars that no one uses because on laptops, few people have num buttons to control, and there is not much sense from hydraulics. Plus, you have to constantly change the structure of the save and read datfiles, and this takes a certain amount of code in the end. In general, I think that this should be done and I need real testers, in discord, send me friend request (brassiere#9130). I will send versions and we will test. Just pushing all the features that people want is pointless, especially since these people then do not make a single mission with this feature. Therefore, starting from today, the development of DYOM IX has been stopped.

Will you complete the red dyom I make a lot of MISSION using DYOM RED because it's stable

Edited May 13, 2022 by bessem ben

[Toriality]

1 hour ago, Halter said:

So friends, we have come to the point where we really wandered into the limit of everything. So I decided to make DYOM X from scratch, but it will not support missions with DYOM IX, this is due to the fact that, firstly, today's version has a bunch of unnecessary trash, such as a bunch of twitching animations, Hydraulics for cars that no one uses because on laptops, few people have num buttons to control, and there is not much sense from hydraulics. Plus, you have to constantly change the structure of the save and read datfiles, and this takes a certain amount of code in the end. In general, I think that this should be done and I need real testers, in discord, send me friend request (brassiere#9130). I will send versions and we will test. Just pushing all the features that people want is pointless, especially since these people then do not make a single mission with this feature. Therefore, starting from today, the development of DYOM IX has been stopped.

 

I think it's going too fast that's what she said. Haven't said anything about it here because I see people were having fun in this topic, so I didn't want to make any criticism yet, but I wasn't really liking the way we were receiving new versions every week.

 

Obviously, I'm not against in releasing new versions constantly, but most of the times developes do it, it's not for adding feature to their application, but for fixing bugs and minor tweaks.

 

If you want my honest opinion, let's not put the cart before the horse. Do not make DYOM X, also not DYOM IX 5.6, let it be just DYOM IX. You find yourself a good team of testers and other interested people that can be useful, and make a single stable version of DYOM.

 

PatrickW and Dutchy had quality standards and patterns we should either imitate or improve, not ignore it. If we stop and think, even through there lacks some features we really like or need, DYOM 8.1 is a very complete and stable version that doesn't have many bugs. Most of bugs and crashes we encounter is GTA's engine fault, like ball actor bug and crashing interiors.

 

The only bug I know which is intrinsical to DYOM is DYOMtemp bug (maybe you can start there). There is a fairly huge data I've retrieved about this theme, which for now I prefer to share privately, that might help you seeing what changes could be made to improve user experience.

 

I'll send you a friend request so we can discuss better this situation.

 

Edited May 13, 2022 by Toriality

[Halter]

24 minutes ago, Toriality said:

 

I think it's going too fast that's what she said. Haven't said anything about it here because I see people were having fun in this topic, so I didn't want to make any criticism yet, but I wasn't really liking the way we were receiving new versions every week.

 

Obviously, I'm not against in releasing new versions constantly, but most of the times developes do it, it's not for adding feature to their application, but for fixing bugs and minor tweaks.

 

If you want my honest opinion, let's not put the cart before the horse. Do not make DYOM X, also not DYOM IX 5.6, let it be just DYOM IX. You find yourself a good team of testers and other interested people that can be useful, and make a single stable version of DYOM.

 

PatrickW and Dutchy had quality standards and patterns we should either imitate or improve, not ignore it. If we stop and think, even through there lacks some features we really like or need, DYOM 8.1 is a very complete and stable version that doesn't have many bugs. Most of bugs and crashes we encounter is GTA's engine fault, like ball actor bug and crashing interiors.

 

The only bug I know which is intrinsical to DYOM is DYOMtemp bug (maybe you can start there). There is a fairly huge data I've retrieved about this theme, which for now I prefer to share privately, that might help you seeing what changes could be made to improve user experience.

 

I'll send you a friend request so we can discuss better this situation.

 

The problem is that as soon as we exceed the code limit, it automatically entails crashes and problems of various kinds, such as crashes of Actors or, for example, glitches and flickers for those who have a weak computer. Therefore, now the stable version, which can really be version 9, is only RED and nothing else.

 

People think that you can have fun and insert any damn features and an endless in DYOM, and I am especially pleased with people who ask for even more versions in RED considering that after the release of 8.1 and before darkmorgan released something, 7 years passed to understand what can be break the limit and add something. And then it took another year to understand what is possible without the adjuster limit, removing unnecessary things and inserting more functions. I don’t know if there is any point in DYOM IX, because in fact it already breaks the rule and destroys one of the main features of DYOM, called Storyline.  Other people compare LDYOM with IX, given that, firstly, I do not have the source code, and secondly, DYOM uses ten-year-old technology

[Guest]

I also agree with what @Halter said, people don't do much missions with DYOM IX, there's literally no point updating if people really don't use it. It's not even advertised on main DYOM website (atleast DYOM Red should be, because its more stable & for regular DYOM'ers that dont use limiters) but i dont think thats going to happen anytime soon. Also - Halter and especially my channel in the comments is getting BOMBARDED with requests, to add more, more, more features, keep explaining to people: There are limits - but they don't listen. Hopefully we can get to that point that DYOM Red will be made official DYOM 9.0 version, and in peace we can test DYOM IX beta's

Edited May 13, 2022 by Horus Publishing

[Toriality]

37 minutes ago, Halter said:

The problem is that as soon as we exceed the code limit, it automatically entails crashes and problems of various kinds, such as crashes of Actors or, for example, glitches and flickers for those who have a weak computer. Therefore, now the stable version, which can really be version 9, is only RED and nothing else.

 

People think that you can have fun and insert any damn features and an endless in DYOM, and I am especially pleased with people who ask for even more versions in RED considering that after the release of 8.1 and before darkmorgan released something, 7 years passed to understand what can be break the limit and add something. And then it took another year to understand what is possible without the adjuster limit, removing unnecessary things and inserting more functions. I don’t know if there is any point in DYOM IX, because in fact it already breaks the rule and destroys one of the main features of DYOM, called Storyline.  Other people compare LDYOM with IX, given that, firstly, I do not have the source code, and secondly, DYOM uses ten-year-old technology

Let's focus on REd then. My point is, whatever is better for DYOM, we should go for it. Doesn't matter if it is IX or REd.

 

People will aways make feature requests and suggestions, that's how they "participate" on the development, but it's your job to filter which features are worth implementing and which are not.

 

But most importantly than implementing new functionalities, is improving existing ones, fixing bugs and making optimizations.

 

Is it possible to optimize DYOM without it's source code?

 

About the limits, how CLEO scripts inpact them? Would it be possible to separate parts of the project into script files?

 

If we look at DYOM#, it loads all the objects without affecting the .SCM code limits, because it uses cleo. (as far as i know)

 

If what I said above is true, what if you delete all the lines of code regarding IDs (for peds, animations, objects, pickups, cars, everything) and put then into separated .cs files?

 

- Would it give more space on the .SCM code for other features?

- Would it even be possible? (Deleting DYOM 8.1-related code without its source code)

Edited May 13, 2022 by Toriality

[Halter]

11 minutes ago, Toriality said:

Let's focus on REd then. My point is, whatever is better for DYOM, we should go for it. Doesn't matter if it is IX or REd.

 

People will aways make feature requests and suggestions, that's how they "participate" on the development, but it's your job to filter which features are worth implementing and which are not.

 

But most importantly than implementing new functionalities, is improving existing ones, fixing bugs and making optimizations.

 

Is it possible to optimize DYOM without it's source code?

 

About the limits, how CLEO scripts inpact them? Would it be possible to separate parts of the project into script files?

 

If we look at DYOM#, it loads all the objects without (as far as I know) affecting the .SCM code limits, because it uses cleo.

 

If what I said above is true, what if you delete all the lines of code regarding IDs (for peds, animations, objects, pickups, cars, everything) and put then into separated .cs files?

 

- Would it give more space on the .SCM code for other features?

- Would it even be possible? (Deleting DYOM 8.1-related code without its source code)

Splitting into separate scripts will not be the best thing, because it can destroy the integrity of the DYOM. It's like cutting your stomach out and making it work from the outside, yes, of course, this happens, but you won't be able to walk with such crap. The essence of DYOM has always been and will be in the integrity of the entire code. Removing cars IDs and actors will not give anything, because these are just numbers, and numbers do not affect the code, it affects the code by changing the value of the variable, which is then used. Animations have names and are all unique, which is why adding animations takes a lot of code. I can't add new features to DYOM because then I would have to make a new data file format that you have already seen many times in DYOM IX. And it takes some place in the code. Tell you a secret? Do you know how I was able to insert the code for the spook-o-meter and the turret, only because I deleted a piece of DYOM mission reading made before version 6. By the way, 6, 7 and 8 versions have the same data file format

[bessem ben]

@HalterI advise you to add new things and delete unimportant things in dyom red such as chekpoint that you talked about, you can do many things with it

[Halter]

3 minutes ago, bessem ben said:

@HalterI advise you to add new things and delete unimportant things in dyom red such as chekpoint that you talked about, you can do many things with it

Adding that checkpoint does not affect the datafile format because I found a tricky way to read it, but it only works for simple Objectives like removing weapons, Actors and Vehicles have memory and in order to add new functions you need to expand the memory, that is, by creating a new type datafiles. That feature was added only because of the simple Objectives and in general it did not affect the datafiles, and only because of this.

[bessem ben]

@HalterYou make a checkpoint when you don't touch it first you lose like a race in red means it can't be added

Edited May 13, 2022 by bessem ben

[Halter]

 

 

This update was supposed to come out because the Must Be in Checkpoint for Actors was very buggy, so I fixed it and added some more interesting stuff

 

 

First of all, the ability to make all objects liftable has been added, for this you need to press Enter next to the object

 

 

Also, a feature has been added for Objective-Objects so that the Player need to pick up this object

________________________________________________________________________________________________

 

 

Other minor improvements in the changelog. To update the version, download it from the first page

[Toriality]

3 hours ago, Halter said:

Splitting into separate scripts will not be the best thing, because it can destroy the integrity of the DYOM. It's like cutting your stomach out and making it work from the outside, yes, of course, this happens, but you won't be able to walk with such crap. The essence of DYOM has always been and will be in the integrity of the entire code. Removing cars IDs and actors will not give anything, because these are just numbers, and numbers do not affect the code, it affects the code by changing the value of the variable, which is then used. Animations have names and are all unique, which is why adding animations takes a lot of code. I can't add new features to DYOM because then I would have to make a new data file format that you have already seen many times in DYOM IX. And it takes some place in the code. Tell you a secret? Do you know how I was able to insert the code for the spook-o-meter and the turret, only because I deleted a piece of DYOM mission reading made before version 6. By the way, 6, 7 and 8 versions have the same data file format

I was looking for an solution to this, I'm not a very experienced programmer, specially when it comes to game development. I talked with Junior_Djjr to find some answers, he said the following:

 

\\-----------------(by Junior_Djjr)-----------//

Quote

The problem is that as soon as we exceed the code limit, it automatically entails crashes and problems of various kinds, such as crashes of Actors or, for example, glitches and flickers for those who have a weak computer."

This is bullsh*t, this is what guys say when they can't explain the cause of a crash (crash is an error, not lack of hardware power).

These limits basically do not exist, what exists are pre-defined limits, for example you can only create 140 peds, 110 vehicles, 350 objects etc. Then you use limit adjuster mods such as Open Limit Adjuster and/or fastman92 limit adjuster to increase them.

 

Worried about causing lag on weak PCs? The game was created in 2004, everything is optimized for low-end, and this game is huge, anything you do (like create a new person, run AI conditions on a person etc) is a drop of water in a pool, you have no idea how much processing the game does on each frame, and even more, DYOM runs in a game without NPC, that leaves a huge amount of hardware.

If something caused a bug or lag, it's a code error, we can't blame the game for that.

 

Quote

"Splitting into separate scripts will not be the best thing, because it can destroy the integrity of the DYOM."

But it is necessary that this be destroyed, this system was created at the time of CLEO 3, we live in a new universe.

 

With the use of .asi, mainly plugin-sdk, you have full control of the game, since around 2017 this project became so absurd that creating a .asi mod today is practically like creating an extension for an open source game, it is simply incredible.

We should use .asi with plugin-sdk to perform hard patches on the game, hard actions, and the script can also communicate with .asi by sending and receiving data.

 

CLEO Redux turns CLEO into a real language, ie JavaScript, so you can write code the way it should be, a real programing, without the usual limitations, and using existing JavaScript libraries and snippets all over the internet. And yes, you can use CLEO 4 with it.

 

Don't even think about working with Sanny Builder, that world has been gone for years. Use CLEO Redux, or if you want to continue the game's old SCM system (I still use it today), use gta3script by LINK/2012. Remembering that today we have the source code of leaked GTA Trilogy game missions, in gta3script, so we can use the official game source code as a base.

 

I created CLEO+ which revolutionized CLEO scripting in recent years, it is 3 times bigger than the entire CLEO library, and they are not useless commands, they are really very important things to making CLEO scripting a really good way to mod the game, for example the events system, extended vars for ped, cars and objects (works like a class extension for that specific entity instance), list/vector bridge from C++, better communication between different scripts, more conditions, better management for ped tasks, controls, timers, game logic, maths, strings, sounds, weapons, models... And you can use it on CLEO Redux.

 

We are living in a completely new universe compared to when DYOM was created. Erase it from memory (but I still think it's important to have backward compatibility with old missions) and reimagine the project structure with all the beauty we have in today's modding.

 

Think about oriented programming languages, do it like a real professional product and not just a game hack.

--- What would I do if I was creating a new DYOM?

 

I admire the work of CLEO Redux but it is still relatively early and I already have 10 years of experience with SCM, so I would use gta3script to code it, also because CLEO+ was created for it, so it's better adapted.

For anyone who has ever created a game or any software that works with object orientation, you know that the old scripting method in GTA is not suitable for creating advanced things that work with a lot of cars, people, objects (like DYOM).

 

I would simulate the way I create games in Unity with the CLEO+ extended vars system, that is, so I can store data inside the peds, cars and objects instances, instead of storing it inside my script. And of course, I can work on that data whenever I want, so the workflow is more similar to, for example, creating a new game in Unity (like each component is an extended var identifier)

 

Something similar can be done in .asi with plugin-sdk, but better because you actually have the class/struct there. Actually what CLEO+ does is a bridge, internally it's the same system.

But I don't recommend plugin-sdk here (as a core) because after all, we want to work with the SCM side of the game for better controls of the peds etc, an .asi can't be used to work out how the game's missions work, it's a pointless practice.

Big information like big arrays, variable element lists, just use CLEO+ LIST which is a bridge to C++ vector.

For example, you can have lists of actions, list of peds, and each ped can have stored in its instance, other data or even lists of data (maybe configurations), actions, etc.

 

I don't know if it's the best way, but an example for this is to use lists as managers, and extended vars as controllers/components/blueprints.

 

For example, I created this Ped Spawn Creator in just 4 hours, using gta3script and CLEO+:
https://gist.github.com/JuniorDjjr/e46312e95b5c5ed0ab52f8ae452b51ee
It supports basically unlimited amount of .ini (locations) and peds, modular, only less than 400 lines of code.

 

I've creatd an ENTIRE MODULAR inventory system using gta3script and CLEO+ (I didn't even use plugin-sdk here).
https://github.com/JuniorDjjr/InventorySystem
It supports basically unlimited amount of items, and each item can have different behaviours, each behaviour is a script that you can add it to.

 

And I'm not even up to date in 2022, I'm still using 2020 stuff, CLEO Redux makes it all even more possible, for example, it has some good native GUI solution, and mainly, object oriented programming, which is very useful for cases like DYOM.

 

btw I'm creating a GTA-like game and I think about doing a DYOM for it, but I think it's going to be very different, it's still going to take a while for me to start getting my hands on this idea.

\\-------------------------------//

Edited May 13, 2022 by Toriality

[Halter]

1 hour ago, Toriality said:

This is bullsh*t, this is what guys say when they can't explain the cause of a crash (crash is an error, not lack of hardware power).

And what do you think it is? This is the latest compilation of the latest version of DYOM IX. Let any person try to launch DYOM IX right now by removing the Limit Adjuster and I'll see how he will play "without crashes". It is very interesting to accuse me of obvious things when the game has obvious limits, and that, of course, even now there are crashes when I go to the 250000 mark. I would love to make my own version of DYOM, Horus Publishing knows about this, which I actually do now, but you need to understand that I do not have the source code for DYOM, so you need to change anything very, very carefully, and understanding the code so it comes with time.

 

To rewrite the DYOM, you need the source code and at least some comments from the developers so that they explain what's what, without this it will be very difficult to do a rewrite at all. You also need to understand that we have old, as it were, versions of DYOM, no one has canceled compatibility with 8.1, and if, for example, we transfer animation 5 to 1, then the same thing will happen in all the missions that we load, but the point is that this same animation will be in the wrong place because we have already moved it. Basically, Junior_Djjr here told what he would do if he made a DYOM from scratch, but we already have a finished product, the understanding of which was done by people on their own without a SINGLE COMMENT FROM THE DEVELOPERS

 

Naturally, I myself would not have done all this, having everything with me from scratch, why do I need all this? But we have a ready-made system, so you need to carefully approach everything. I have great respect for all scripters and even for him and I really respect your opinion, but after everything that happened, my desire to continue has already completely disappeared, because without the original code and such a crowd of hungry people, it’s hard to understand where everything is, so I’m better I will start my own business than to delve into someone else's business, which cannot be touched and treated with contempt. I have a lot of respect for DYOM and therefore I tried to keep everything in place without changing the interface, animation places for respect for people and, of course, to maintain missions from 8.1

[Guest]

11 minutes ago, Halter said:

but after everything that happened, my desire to continue has already completely disappeared, because without the original code and such a crowd of hungry people, it’s hard to understand where everything is, so I’m better I will start my own business than to delve into someone else's business, which cannot be touched and treated with contempt.

 

Totally understandable. Same thing happened to us while playing missions. We just stopped recording it, because they were getting harder, annoying & you can't save checkpoints to get back to like current point where you failed, you need to start the mission all over. Yeah if you would need any test for your softwares, without recording it or anything just tell us we're here  

1 hour ago, Toriality said:

I was looking for an solution to this, I'm not a very experienced programmer, specially when it comes to game development. I talked with Junior_Djjr to find some answers, he said the following:

 

\\-----------------(by Junior_Djjr)-----------//

This is bullsh*t, this is what guys say when they can't explain the cause of a crash (crash is an error, not lack of hardware power).

These limits basically do not exist, what exists are pre-defined limits, for example you can only create 140 peds, 110 vehicles, 350 objects etc. Then you use limit adjuster mods such as Open Limit Adjuster and/or fastman92 limit adjuster to increase them.

 

Worried about causing lag on weak PCs? The game was created in 2004, everything is optimized for low-end, and this game is huge, anything you do (like create a new person, run AI conditions on a person etc) is a drop of water in a pool, you have no idea how much processing the game does on each frame, and even more, DYOM runs in a game without NPC, that leaves a huge amount of hardware.

If something caused a bug or lag, it's a code error, we can't blame the game for that.

 

But it is necessary that this be destroyed, this system was created at the time of CLEO 3, we live in a new universe.

 

With the use of .asi, mainly plugin-sdk, you have full control of the game, since around 2017 this project became so absurd that creating a .asi mod today is practically like creating an extension for an open source game, it is simply incredible.

We should use .asi with plugin-sdk to perform hard patches on the game, hard actions, and the script can also communicate with .asi by sending and receiving data.

 

CLEO Redux turns CLEO into a real language, ie JavaScript, so you can write code the way it should be, a real programing, without the usual limitations, and using existing JavaScript libraries and snippets all over the internet. And yes, you can use CLEO 4 with it.

 

Don't even think about working with Sanny Builder, that world has been gone for years. Use CLEO Redux, or if you want to continue the game's old SCM system (I still use it today), use gta3script by LINK/2012. Remembering that today we have the source code of leaked GTA Trilogy game missions, in gta3script, so we can use the official game source code as a base.

 

I created CLEO+ which revolutionized CLEO scripting in recent years, it is 3 times bigger than the entire CLEO library, and they are not useless commands, they are really very important things to making CLEO scripting a really good way to mod the game, for example the events system, extended vars for ped, cars and objects (works like a class extension for that specific entity instance), list/vector bridge from C++, better communication between different scripts, more conditions, better management for ped tasks, controls, timers, game logic, maths, strings, sounds, weapons, models... And you can use it on CLEO Redux.

 

We are living in a completely new universe compared to when DYOM was created. Erase it from memory (but I still think it's important to have backward compatibility with old missions) and reimagine the project structure with all the beauty we have in today's modding.

 

Think about oriented programming languages, do it like a real professional product and not just a game hack.

--- What would I do if I was creating a new DYOM?

 

I admire the work of CLEO Redux but it is still relatively early and I already have 10 years of experience with SCM, so I would use gta3script to code it, also because CLEO+ was created for it, so it's better adapted.

For anyone who has ever created a game or any software that works with object orientation, you know that the old scripting method in GTA is not suitable for creating advanced things that work with a lot of cars, people, objects (like DYOM).

 

I would simulate the way I create games in Unity with the CLEO+ extended vars system, that is, so I can store data inside the peds, cars and objects instances, instead of storing it inside my script. And of course, I can work on that data whenever I want, so the workflow is more similar to, for example, creating a new game in Unity (like each component is an extended var identifier)

 

Something similar can be done in .asi with plugin-sdk, but better because you actually have the class/struct there. Actually what CLEO+ does is a bridge, internally it's the same system.

But I don't recommend plugin-sdk here (as a core) because after all, we want to work with the SCM side of the game for better controls of the peds etc, an .asi can't be used to work out how the game's missions work, it's a pointless practice.

Big information like big arrays, variable element lists, just use CLEO+ LIST which is a bridge to C++ vector.

For example, you can have lists of actions, list of peds, and each ped can have stored in its instance, other data or even lists of data (maybe configurations), actions, etc.

 

I don't know if it's the best way, but an example for this is to use lists as managers, and extended vars as controllers/components/blueprints.

 

For example, I created this Ped Spawn Creator in just 4 hours, using gta3script and CLEO+:
https://gist.github.com/JuniorDjjr/e46312e95b5c5ed0ab52f8ae452b51ee
It supports basically unlimited amount of .ini (locations) and peds, modular, only less than 400 lines of code.

 

I've creatd an ENTIRE MODULAR inventory system using gta3script and CLEO+ (I didn't even use plugin-sdk here).
https://github.com/JuniorDjjr/InventorySystem
It supports basically unlimited amount of items, and each item can have different behaviours, each behaviour is a script that you can add it to.

 

And I'm not even up to date in 2022, I'm still using 2020 stuff, CLEO Redux makes it all even more possible, for example, it has some good native GUI solution, and mainly, object oriented programming, which is very useful for cases like DYOM.

 

btw I'm creating a GTA-like game and I think about doing a DYOM for it, but I think it's going to be very different, it's still going to take a while for me to start getting my hands on this idea.

\\-------------------------------//

 

That guy is clearly so f*cking confident LOL. If he does his own "mission creation software" on Definitive Edition, we would like to try it and it would be interesting to check it out. Like he said he's making "His game with DYOM build in" - good luck, probably it will never reach GTA success without advertisement, but if it will be good - why not. Give him the DYOM code, let's see what he can do  

Edited May 13, 2022 by Horus Publishing

[Halter]

Here is the latest DYOM RED compilation

 

 

 

And here is the compilation 8.1. There is a bit of free space for features, right?

 

So, if someone turns out to be better than me and creates a really cool DYOM IX on the same basis, I think everyone will be happy, just don’t use the current developments of DYOM IX to be fair, but go to the very beginning to 8.1. Maybe there are people better than me and I know that there are. I myself understand that I am not a code master and that I cannot directly do super cool things, but I was very grateful to the people who gave real feedback and support. And in general, I'm glad that there were people who wrote at least something. Seriously, I think there will be nothing wrong if someone does something really better than us, everyone will only be happy

[Toriality]

@Halter I'm posting Junior's response because he can't post in the forums atm. Here:

 

Quote

(Junior_Djjr)

 

Why did you cut off part of my message to make it look like I'm wrong? This is dishonest.

 

This is my entire message:

 

"This is bullsh*t, this is what guys say when they can't explain the cause of a crash (crash is an error, not lack of hardware power). These limits basically do not exist, what exists are pre-defined limits, for example you can only create 140 peds, 110 vehicles, 350 objects etc. Then you use limit adjuster mods such as Open Limit Adjuster and/or fastman92 limit adjuster to increase them."

 

I literally said that the limits are predefined, and you showed a picture of a limit that is predefined. Wtf? And I understand that it's a lot of work to recreate the mod, but I think it's too much drama to treat this as something unimaginable.

 

The mod was created at the time of CLEO 3, today we are light years ahead of that time, today it is much easier. I think it's worth it, DYOM has a lot to improve in UX and features. Several youtubers have contacted me asking to recreate DYOM as they want something better for creating scenes for videos. Los Santos Cast, for example.

 

------

 

My opinion on all of this:

 

Although I agree with what Junior said, I can see your side. Making a DYOM from scratch would be a lot of effort and stress, over many months, to have a final product that cannot be approved without the original developers, who have abandoned the project and, even if they approve the new one, it would take a long time for it to officially enter the site and gain recognition. In short, there is no motivation for this and I agree with this thought.

 

I think the IDEAL alternative would be to gather a group of people really committed to change this situation, make a final product (it could be a DYOM made from scratch with these new technologies mentioned by Junior, or the DYOM REd or whatever is decided to be the best option among this group), together with other products that improve the current situation we are in, and when we have this ready, or in a final stage, contact the developers, showing the project, and requesting their permission for the source code of the DYOM and its site. Such permission will never be granted if we have an unstable project with no standards.

 

But this is the ideal scenario and very difficult to achieve.

 

There are other alternatives, several of them, but they all assume that at some point we will reach the limit and have to abandon the project, or end it with bugs and unfinished features -- which is happening with IX.

 

Know that my DM will always be open to help you in the project, even though I am inexperienced in programming, I have some ongoing projects and ideas that I believe I can help you with if you are interested.

 

1 hour ago, Halter said:

So, if someone turns out to be better than me and creates a really cool DYOM IX on the same basis, I think everyone will be happy, just don’t use the current developments of DYOM IX to be fair, but go to the very beginning to 8.1. Maybe there are people better than me and I know that there are. I myself understand that I am not a code master and that I cannot directly do super cool things, but I was very grateful to the people who gave real feedback and support. And in general, I'm glad that there were people who wrote at least something. Seriously, I think there will be nothing wrong if someone does something really better than us, everyone will only be happy

I think you are very talented and the fact that you accepted taking this project and give much effort to it just shows how dedicated you are. This situation really sucks, we all feel it, but no one is blaming you for the game's limitation or the lack of DYOM's source code breaking IX, it's something we couldn't predict would end so fast (at least I couldn't till now :p)

Edited May 13, 2022 by Toriality

[Halter]

1 hour ago, Toriality said:

@Halter I'm posting Junior's response because he can't post in the forums atm. Here:

 

 

------

 

My opinion on all of this:

 

Although I agree with what Junior said, I can see your side. Making a DYOM from scratch would be a lot of effort and stress, over many months, to have a final product that cannot be approved without the original developers, who have abandoned the project and, even if they approve the new one, it would take a long time for it to officially enter the site and gain recognition. In short, there is no motivation for this and I agree with this thought.

 

I think the IDEAL alternative would be to gather a group of people really committed to change this situation, make a final product (it could be a DYOM made from scratch with these new technologies mentioned by Junior, or the DYOM REd or whatever is decided to be the best option among this group), together with other products that improve the current situation we are in, and when we have this ready, or in a final stage, contact the developers, showing the project, and requesting their permission for the source code of the DYOM and its site. Such permission will never be granted if we have an unstable project with no standards.

 

But this is the ideal scenario and very difficult to achieve.

 

There are other alternatives, several of them, but they all assume that at some point we will reach the limit and have to abandon the project, or end it with bugs and unfinished features -- which is happening with IX.

 

Know that my DM will always be open to help you in the project, even though I am inexperienced in programming, I have some ongoing projects and ideas that I believe I can help you with if you are interested.

 

I think you are very talented and the fact that you accepted taking this project and give much effort to it just shows how dedicated you are. This situation really sucks, we all feel it, but no one is blaming you for the game's limitation or the lack of DYOM's source code breaking IX, it's something we couldn't predict would end so fast (at least I couldn't till now :p)

The thing that I am working is not DYOM at all. So i don't need approval from creators or developers, it's only DYOM-look-alike but nothing more. It'll be like a stand-alone application, something like Map Editor but not so cool. DYOM IX is already on the limit where we can't do anything, so i think REd is a great post version between unfinished DYOM IX and 8.1. The big reason why am i doing that is that GTA SA has limitations, and we all need to accept that like Ped or Car limitations. So when people ask to break the limits it's just pointless cause the game will hardly keep everything normally even with Limit Adjusters. When you're writing code every Actor is only on your code and not spawning with a marker on his head like in DYOM which takes 1 ped from the 140 PED limit. Imagine a big project with 500 peds, of course, the game will crash.

Edited May 13, 2022 by Halter