- Joined
- Jul 10, 2007
- Messages
- 6,306
Post Update #1:
To clarify issues regarding the MOPS system, I have decided to update this post. It appears that a lot of people really don't understand why it's any different from structs. Well, here, I am going to show why. I am also going to show a few different ways to use it and the strengths and weaknesses of each way.
MOPS is a massive object and property storage system. Now, how this system differs from vjass is that it works by reference and not by value.
When something works by value, every time you access it, it creates a copy of the original. You can never edit the original. When something works by reference you access the original and change that.
Structs work by copying themselves every time you use them. This may be fast, but it takes up extra memory. However, an advantage is you can control each instance of the struct in a unique fashion.
Now, we're going to move on now that we know some of the differences.
MOPS creates all of its data structures as the game is loading up. It also creates new data structures as they are needed while the game is running. This means, unlike vjass, it maximizes space. Now, we talked about how vjass can be edited uniquely. So can MOPS. Instead of creating entire new sets of data, it takes that original data and makes private branches off of it, this way it uses as little data as possible. A downfall to this is that all of the data has to be looped so it will take *longer* than a vjass data structure, but it will save memory.
Another issue is expanding data. I'm not talking about expanding data through a struct extension, but expanding it within a struct. In vjass, the simplest way to do this would be to create an array within the struct for your data and another array within the struct for your data types. From here you can loop through that new data and collect it along with your old data. However, as I said before, this will take up a lot of memory. Also, if your objects begin to vary with this data as you expand and overwrite, then you'll need to create new structs for the varying objects. This can be annoying, time consuming, and once again, will take up massive amounts of memory. Again, this is the fastest method as it accesses the data directly and not through a loop.
Now, here's where MOPS starts coming into play.
There are three methods to using MOPS and two of them require vjass.
Method #1:
The first method involves creating all of your structs in vjass that you plan to use in the system. From here, you load them into what we call Object Clusters in MOPS. Object Clusters act as tables.
Table
------------------
|Object | Variable |
------------------
Now, in this table, each object loaded into the object cluster will share the variables loaded into the variable pool.
Table 1
------------------
|Object | Variable |
|Object | Variable |
|-------|Variable |
|-------|Variable |
|-------|Variable |
------------------
In this case, the two objects in the object pool share the 5 variables in the variable pool. They also share variable data from pools above them.
A Table 2 is loaded into the Table 1 above that looks like this-
Table 1
---|---
Table 2
------------------
|Object | Variable |
|-------| Variable |
|-------|Variable |
------------------
This one object will use all of the variables from this variable pool and all of the variables from the variable pools from object clusters above it. An object cluster can be loaded into multiple object clusters, so they can take data from multiple pools. It can also take data from any pool above it like so:
Table 1
--|-- \
Table 2 -- Table 6
--|-- --|--
Table 3 -- Table 7
Table 4
--|--
Table 3
Table 3 here takes data from Table 1 and Table 2 because it takes data from all pools along the branch it follows. However, because it's not connected to the other branch, it cannot take information from Table 6 or 7. After this, Table 3 is loaded into Table 4 so it takes information from there as well.
Now, let's say each of these variables are object clusters and each object is something like a unit on the map. Remember, Objects in MOPS don't have to have variable information loaded directly into them. They can always take it from somewhere else. Each Object can simply be an empty object for the unit to point to to collect all of its data.
Now, in this tree as I said before, you would predefine all of your structs (your variables) and load them into each of the variable pools where they are needed. This would mean the data structure would act within MOPS and so looping would be required. From here, you can easily use some of the very nice methods of extending information with more freedom than vjass. You can also use this data structure to branch it off further based on completely unique in-game instances which would require a massive list of structs if you were to use plain vjass. It's either that or a generic struct with huge arrays.. again, not very cool.
Now, MOPS does allow you to label all of your information within the data structures you design. However, each label is a string, so it does slow it down, but there is something else. It will have a special feature which will allow you to retrieve the direct indexes to the data you are searching for. You can store these indexes within your system to speed up your system to get around the labels. You can use labels just to make it easier for you to design the system : ), and you can label each variable in your system to equal the string name within the MOPS system if you want to make it even easier. This will make sure that MOPS is just about the same speed as vjass with this method.
-------------------------------------
Method #2
With Method #2, you create your entire data structure with pure vjass. This means you will be using structs and struct extensions and you will be designing all of your trees. From here, every time you have an instance, you may load that into the MOPS system only so you can easily track that instance. Thus, instead of using an array, you will be using the complex data management system to keep track of it so you can more easily access it later and you don't have to remember array indexes and what not.
What this means? MOPS will be the exact**** same speed as vjass. You will be able to extend your information with the MOPS system using the extension commands like the ones I stated above. You can also extend the information within the specific structs, but let's say you want 2 structs to use the same extended information. You can load them into an object cluster and pretty much retain their speed while staying more memory efficient. You may create new trees off of your data structures while in-game. Well, there is just a whole list...
So, MOPS acts as a very useful extension for vjass. These are just some of the possibilities with the MOPS system... And I hope that you saw from those tables how much easier your data will be to manage, to keep efficient, and to keep fast. You can stick with plain vjass and have it run through the MOPS system just so you can retrieve it more easily if you want to, or connect it with units more easily. It'll retain its speed. Or you can be more memory efficient and run the data structure through MOPS. From here, you have a whole slew of options within MOPS that will allow you to manipulate data while retraining maximum speed and maximum memory efficiency.
While MOPS acts as a massive data management system, it also has a few very useful side features that come with it.
First, it can store as much memory as wc3 can possibly store. It can store this information dynamically.
Next, it allows for easy system communication between systems. It prevents information from colliding within systems.
Next, it automatically multi-threads all data going into it as much as it can. This means if you are running functions through MOPS (i'll get into this later) it'll be faster than normal.
After this, it has an memory allocation process within it that allows you to transfer any amount of data from any function to any other function of any type. This means unlimited sends of any type and unlimited returns of any type. Of course, it uses the MOPS system to track the data threads and search through : ). When you create a new function, you can create a sort of thread within MOPS for that function to use, almost like a table. Just name that thread the function name (string) this way it can multi-thread it. When MOPS goes, it'll search for all of the information for a single instance within that branch and send it to the function. This means functions can communicate with each other through MOPS and not through traditional methods. This is how the unlimited returns and unlimited sends of any type is achieved, and you can see where MOPS plays a big role in this. All you literally have to do is create a variable for the function... and you're done..
If you were to do this with plain vjass, it would.. be hard... i'll just stop that there because it gives me a headache thinking about it..
After this, it allows you to call any function with any other function. How? Through a special trigger that the allocation process will use. This will make it multi-thread all data going through the threading system MOPS will use, however, to prevent data that requires other data from being processed first, it'll have some nice waits to wait until data reaches a function. When data reaches the function, it'll collect the waiting data and begin to process it. This is how maximum possible speed is achieved. The function within the trigger will be at the bottom of the map. Because it works off of a trigger, any function within the entire map will be able to run it, however, the only function that will be running it will be the allocation process, which will always be located at the top of the map.
Now, why would this make systems run faster? Let's say a system uses 100 functions. Let's say most of these functions don't have to wait for data and can run independently.... well... yea..
This is what MOPS is... and I might be creating more features for MOPS.
Guys, please respond to this thread with new ideas, comments, or w/e. Also ask any questions you may have. I will update the post accordingly to be more clear on the specific areas that are questioned.
I know a lot of you thought this was a useless system, but in this post, I explain why it's not a useless system.
Also, when you're using vjass, you're still going to have to have a way for units, items, and whatnot on the map to point to the data. As I said before, it MOPS acts as a plain translator between the two, it's the exact same speed as vjass, it's just easier to manipulate and organize.
To clarify issues regarding the MOPS system, I have decided to update this post. It appears that a lot of people really don't understand why it's any different from structs. Well, here, I am going to show why. I am also going to show a few different ways to use it and the strengths and weaknesses of each way.
MOPS is a massive object and property storage system. Now, how this system differs from vjass is that it works by reference and not by value.
When something works by value, every time you access it, it creates a copy of the original. You can never edit the original. When something works by reference you access the original and change that.
Structs work by copying themselves every time you use them. This may be fast, but it takes up extra memory. However, an advantage is you can control each instance of the struct in a unique fashion.
Now, we're going to move on now that we know some of the differences.
MOPS creates all of its data structures as the game is loading up. It also creates new data structures as they are needed while the game is running. This means, unlike vjass, it maximizes space. Now, we talked about how vjass can be edited uniquely. So can MOPS. Instead of creating entire new sets of data, it takes that original data and makes private branches off of it, this way it uses as little data as possible. A downfall to this is that all of the data has to be looped so it will take *longer* than a vjass data structure, but it will save memory.
Another issue is expanding data. I'm not talking about expanding data through a struct extension, but expanding it within a struct. In vjass, the simplest way to do this would be to create an array within the struct for your data and another array within the struct for your data types. From here you can loop through that new data and collect it along with your old data. However, as I said before, this will take up a lot of memory. Also, if your objects begin to vary with this data as you expand and overwrite, then you'll need to create new structs for the varying objects. This can be annoying, time consuming, and once again, will take up massive amounts of memory. Again, this is the fastest method as it accesses the data directly and not through a loop.
Now, here's where MOPS starts coming into play.
There are three methods to using MOPS and two of them require vjass.
Method #1:
The first method involves creating all of your structs in vjass that you plan to use in the system. From here, you load them into what we call Object Clusters in MOPS. Object Clusters act as tables.
Table
------------------
|Object | Variable |
------------------
Now, in this table, each object loaded into the object cluster will share the variables loaded into the variable pool.
Table 1
------------------
|Object | Variable |
|Object | Variable |
|-------|Variable |
|-------|Variable |
|-------|Variable |
------------------
In this case, the two objects in the object pool share the 5 variables in the variable pool. They also share variable data from pools above them.
A Table 2 is loaded into the Table 1 above that looks like this-
Table 1
---|---
Table 2
------------------
|Object | Variable |
|-------| Variable |
|-------|Variable |
------------------
This one object will use all of the variables from this variable pool and all of the variables from the variable pools from object clusters above it. An object cluster can be loaded into multiple object clusters, so they can take data from multiple pools. It can also take data from any pool above it like so:
Table 1
--|-- \
Table 2 -- Table 6
--|-- --|--
Table 3 -- Table 7
Table 4
--|--
Table 3
Table 3 here takes data from Table 1 and Table 2 because it takes data from all pools along the branch it follows. However, because it's not connected to the other branch, it cannot take information from Table 6 or 7. After this, Table 3 is loaded into Table 4 so it takes information from there as well.
Now, let's say each of these variables are object clusters and each object is something like a unit on the map. Remember, Objects in MOPS don't have to have variable information loaded directly into them. They can always take it from somewhere else. Each Object can simply be an empty object for the unit to point to to collect all of its data.
Now, in this tree as I said before, you would predefine all of your structs (your variables) and load them into each of the variable pools where they are needed. This would mean the data structure would act within MOPS and so looping would be required. From here, you can easily use some of the very nice methods of extending information with more freedom than vjass. You can also use this data structure to branch it off further based on completely unique in-game instances which would require a massive list of structs if you were to use plain vjass. It's either that or a generic struct with huge arrays.. again, not very cool.
Now, MOPS does allow you to label all of your information within the data structures you design. However, each label is a string, so it does slow it down, but there is something else. It will have a special feature which will allow you to retrieve the direct indexes to the data you are searching for. You can store these indexes within your system to speed up your system to get around the labels. You can use labels just to make it easier for you to design the system : ), and you can label each variable in your system to equal the string name within the MOPS system if you want to make it even easier. This will make sure that MOPS is just about the same speed as vjass with this method.
-------------------------------------
Method #2
With Method #2, you create your entire data structure with pure vjass. This means you will be using structs and struct extensions and you will be designing all of your trees. From here, every time you have an instance, you may load that into the MOPS system only so you can easily track that instance. Thus, instead of using an array, you will be using the complex data management system to keep track of it so you can more easily access it later and you don't have to remember array indexes and what not.
What this means? MOPS will be the exact**** same speed as vjass. You will be able to extend your information with the MOPS system using the extension commands like the ones I stated above. You can also extend the information within the specific structs, but let's say you want 2 structs to use the same extended information. You can load them into an object cluster and pretty much retain their speed while staying more memory efficient. You may create new trees off of your data structures while in-game. Well, there is just a whole list...
So, MOPS acts as a very useful extension for vjass. These are just some of the possibilities with the MOPS system... And I hope that you saw from those tables how much easier your data will be to manage, to keep efficient, and to keep fast. You can stick with plain vjass and have it run through the MOPS system just so you can retrieve it more easily if you want to, or connect it with units more easily. It'll retain its speed. Or you can be more memory efficient and run the data structure through MOPS. From here, you have a whole slew of options within MOPS that will allow you to manipulate data while retraining maximum speed and maximum memory efficiency.
While MOPS acts as a massive data management system, it also has a few very useful side features that come with it.
First, it can store as much memory as wc3 can possibly store. It can store this information dynamically.
Next, it allows for easy system communication between systems. It prevents information from colliding within systems.
Next, it automatically multi-threads all data going into it as much as it can. This means if you are running functions through MOPS (i'll get into this later) it'll be faster than normal.
After this, it has an memory allocation process within it that allows you to transfer any amount of data from any function to any other function of any type. This means unlimited sends of any type and unlimited returns of any type. Of course, it uses the MOPS system to track the data threads and search through : ). When you create a new function, you can create a sort of thread within MOPS for that function to use, almost like a table. Just name that thread the function name (string) this way it can multi-thread it. When MOPS goes, it'll search for all of the information for a single instance within that branch and send it to the function. This means functions can communicate with each other through MOPS and not through traditional methods. This is how the unlimited returns and unlimited sends of any type is achieved, and you can see where MOPS plays a big role in this. All you literally have to do is create a variable for the function... and you're done..
If you were to do this with plain vjass, it would.. be hard... i'll just stop that there because it gives me a headache thinking about it..
After this, it allows you to call any function with any other function. How? Through a special trigger that the allocation process will use. This will make it multi-thread all data going through the threading system MOPS will use, however, to prevent data that requires other data from being processed first, it'll have some nice waits to wait until data reaches a function. When data reaches the function, it'll collect the waiting data and begin to process it. This is how maximum possible speed is achieved. The function within the trigger will be at the bottom of the map. Because it works off of a trigger, any function within the entire map will be able to run it, however, the only function that will be running it will be the allocation process, which will always be located at the top of the map.
Now, why would this make systems run faster? Let's say a system uses 100 functions. Let's say most of these functions don't have to wait for data and can run independently.... well... yea..
This is what MOPS is... and I might be creating more features for MOPS.
Guys, please respond to this thread with new ideas, comments, or w/e. Also ask any questions you may have. I will update the post accordingly to be more clear on the specific areas that are questioned.
I know a lot of you thought this was a useless system, but in this post, I explain why it's not a useless system.
Also, when you're using vjass, you're still going to have to have a way for units, items, and whatnot on the map to point to the data. As I said before, it MOPS acts as a plain translator between the two, it's the exact same speed as vjass, it's just easier to manipulate and organize.
Last edited: