[JASS] MOPS System V2.0

[Nestharus]

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.

 

[Sevion]

Sounds nice. Though, you've been telling be about this for how long? So it's nothing new. But hearing that it's so near release, I'm interested again. Now hurry up and release it!!! >=O

 

[GhostWolf]

Can't all this nice post be replaced with the word "Structs" (which are really Classes but whatever) ?

 

[Need_O2]

I was thinking making
UNIT and EFFECT classes (structs) in a short time

for UNIT
setmomentspeed(real) can be more than 522
setcolor(red,green,blue)
distruptcolor(red,green,blue,duration)
distruptmomentspeed(multipler,duration,stacks ?)

EFFECT
followtarget(target,vectorpower)
speedlosspersecond - not a function (I know its called something but I forgot that word)
scale(x,y,z)

etc etc

 

[NoNZealot]

I know its called something but I forgot that word

You mean constant?

 

[Need_O2]

no velocity change per second
negative acceleration
FRICTION
phew finally

 

[DiscipleOfLife]

First The Saver and now this... Perhaps next a script that cures cancer?

 

[spiwn]

Not cancer, AIDS
P.s. KGB is a great compressor

 

[Need_O2]

Idk about that but this one caused cancer

 

[spiwn]

Using a function before its declaration is mean
Change scope and endscope to library and endlibrary or just add them before and after.

 

[Nestharus]

Reason I didn't release The Saver is because I'm re-writing it for MOPS. Here's the list:
MOPS v2.0
3D Gridding System
GUI Menu System (in-game)
The Saver

But i can show you some of the code if you like? Also, structures are a quite different. Personally, I like an Object Orientated environment better than a structured environment ;p.

Another thing is that this has a memory management system built into it unlike structs. So.. Here's all I have to create now for this:
Unload Command
Destroy Command
Auto-Cleaner
Library Communicator And Auto Storage for Libraries (you'll see what I'm talking about if you look at the code ;p)

All of the rest is done at the moment -.-. It's all been fully tested as well and it all works. If you want some sample beta code (remember this is 2.0, there are bound to be some updates in the 2 series), you can go to this link. This is proof that I'm not all talk -.-
-
http://www.hiveworkshop.com/resources_new/pastebin/show/2b69f896e543061d2685b377a6483d74/

I'm sorry I didn't disclose the code for The Saver because I Was going to re-write it. If any of you want the old code, just PM me and I'll send you everything I wrote for it. I never finished the decryptor because at that point I decided to redo it through MOPS.

 

[Sevion]

Then hurry up and finish it >=O You make me mad. I want to lurn 2 MOPS >=O

 

[Nestharus]

I was thinking making
UNIT and EFFECT classes (structs) in a short time

for UNIT
setmomentspeed(real) can be more than 522
setcolor(red,green,blue)
distruptcolor(red,green,blue,duration)
distruptmomentspeed(multipler,duration,stacks ?)

EFFECT
followtarget(target,vectorpower)
speedlosspersecond - not a function (I know its called something but I forgot that word)
scale(x,y,z)

etc etc

Uh, I'm finally responding to this, sry for the delay.

Yea, you can use that in structs because you're storing the main data in the unit. MOPS is very different from structures. It makes it so you don't have to store any data in any unit. All of the data is processed through MOPS. What does this mean? You can have fully custom combat systems, new stat types, etc. The only thing stored in the unit is a pointer to all of its data. That is it... So yea..

I know a lot of you are thinking, you can just use structs. I keep saying they're very different. I hope this shows some of the reason why they are.

Structures are an entirely different environment from this. This is an object orientated environment. To me, Object Orientation seems more powerful. But they are simply different.

Now, as I said before, this system does have a data management thing built into it. If you look in the code you'll see some of it. I'm not releasing the variable lists because that'll give away a lot about how the data structures work in this.

I'm sorry you all feel like all you need are structs, but for me I need something more. Structs just can't do all the things I need it to do and that's why I came up with this. From here, I don't like using the game cache in any way.

Oh well, most of you are saying this is a useless system because there are already structs. I'm just trying to say that it's not useless because it's very different from structs. Structs are good for creating quick localized variables where the data types are constant and localized instances where the data types are constant. I suggest that system over this for sure.. however, if you are creating a system, I suggest using this to make it if it's going to be dealing with any sort of custom data. Perhaps you're making a character system, a combat system, inventory, almost any sort. Any system that deals with moderate quantities of data should use this as its base. You can still use structs for localized instances in the system, but I suggest this for the main design.

I'm sorry you all see it that way..

 

[GhostWolf]

Structs are OOP. They are not structures, but classes, like in any other language (beside the fact that they are messed up with integers because blizzard didn't implement classes), with class members, methods, a constructor and a destructor, and therefore I do not see anything special with your code, beside the fact that it makes people's work easier but probably less efficient (which people tend to like this days).

 

[Nestharus]

Also, one of the main reasons why structs can't be used in large systems is because of the lack of some way to store the memory.

This creates the objects and stores them. Also, with structs, u can't expand data etc while in-game. You can't create new dynamically named variables while in-game. You can't create new structs while in game. Another problem is you can't create unique instances of structs that stay in the game as permanent data unless you create some sort of memory store system.

Now, most people use the game cache. Personally, I know from my own experience that the game cache does have some issues. Number one, you can only have 100 game cache files in ur wc3 directory. So, imagine an inexperienced player trying to clean them up. It's best not to use it just to make your map easier to play. If everyone used game cache, it'd be gg for the players.

Next, game cache uses a massive amount of unique strings. This causes memory leaks, I know they're small, but still. We're talking about efficiency aren't we? The system I present uses some strings, but it doesn't use near the amount of unique strings that the game cache uses. On the contrary, it uses very little. Integers are one of the main factors in this system.

Also, this system automatically multi-threads your data. This means that if you are handling large amounts of data, it'll be around the same speed as the game cache. Right now, if you look, the beta is based on loops etc, but in v2.1, I'm going to change a bit. Granted, it wont' change the user's experience, I'm just changing the back end stuff.

As I said earlier, when it comes to localized instances that uses data structures that can be 100% pre-defined, I suggest structs. This system isn't as fast as structs are because it doesn't work the same way. This is an actual system than runs thru JASS. JassNewGen actually reformats your code to access specific variables.

Now, if this system were upgraded to be JASSNewGen, it would outrank JASSNewGen in every way, but I doubt that's going to happen : P.

So you can continue to use JASSNewGen while u use this system. I never said you had to use one or the other.

Whenever you are dealing with massive amounts of data, for example characters, inventory, etc, I suggest using this. If you're using quick timers or massive amounts of instances, I suggest JASSNewGen for the quick speed. You can use that data as constant data or data that's stored in the actual function.

I'm just saying that whenever you have permanent data that needs to be stored somewhere, this system outranks JASSNewGen. You can even run them together. Oh well, I'm hoping that you're beginning to see why I'm designing this system.

Imagine trying to track 500 cells in a grid? 500 unique cells..

Now imagine being able to run them all through one function that can take any amount of data and return any amount of data. That's one thing that the MOPS system outranks JASSNewGen on hands down. I'm going to be designing a lot of systems like the one I just described, so JASSNewGen just isn't going to cut it unless I was to make a memory storage system for each system I designed which would be a total waste of time.

You need to be able to store your memory easily and manipulate it easily at top speeds. However, if you were to run MOPS on quick timers etc, you might have 100 threads going at once.. and that would lag your game. That's why JASSNewGen is better than MOPS is in this case. You can collect the main pieces of data from MOPS and then use it with JASSNewGen for the quick speeds = ).

Another weakness JASSNewGen has is that it can only store 8192 pieces of information for each struct. It's very static with this limit. MOPS can store up to around 30,000 pieces of information for any data type (you can have 15,000 in one area, 5,000 in another, 2,500 in another 2, and 5,000 in one more area to hit the limit). The overall back design of MOPS is better than JASSNewGen, however, because it doesn't run through an editor like JASSNewGen deos, right now JASSNewGen beats it.

Personally, in my maps, I plan on using both. I just really need MOPS to manage all of the data. And I hope you can clearly see why MOPS has a better design for managing massive amounts of data than even using the game cache -.-. 50 unique instances can run off of the same variable... the same exact one. or the same object or w/e u decide. That just rapes jassnewgen hands down. This means you only have to go to that variable for each instance and modify it based on their own unique properties. You'd modify it once for each case (go thru that unit to get to the variable). Every time u go thru a unit, it's like a new branch of that variable. That unit accesses the public data that's not overwritten for it, then overwritten data, private extended data, etc. Can JASSNewGen do that?

That concept I just described is one of the main points in Object Orienation. I know it can actually do that, but it's simply a lot more work. You have to separate everything out yourself.. each unit has to have its own unique struct variable.. etc etc etc...

There is a reason for MOPS : ). However, it cannot yet replace structs, not until I get a WE designed for it : P.

Gg

 

[spiwn]

I am not saying that Mops is bad, yet, but I guess you have been too busy to for the past several years designing this to get updated with the latest news about wc3 and vJass.
First of all, game cache is avoided as much as possible nowadays. They say it is rather slow, but I suppose that depends on the hardware. And Game cache limit is 255.
JNGP is just a pack that combines different tools. One of them is the Jasshelper, which enables vJass.
It has been mounts since vJass offers maximum instance specification(even more than 8192).
You are already using vJass. Maybe only for small things, but you do.
"Permanent data"? Permanent as in the whole game? You surely mean that, but with vJass, one global struct(or several) is all it takes ... or am I getting something terribly wrong.
"50 unique instances can run off of the same variable"
I Just cant get that. You mean I cannot have 50 instances of the same struct? That's new.
And finally something visionary:
"You can't create new dynamically named variables while in-game"
If you managed to create MOPS, a far simpler system can be created that uses structs. And I do mean simper and easier to make, that would allow you to create dynamical structs.

 

[GhostWolf]

I'm sorry, I just can't grasp what's new or special here.
I just see it like any other system that makes peoples work easier, but is probably less efficient then the option that they'd code codes that are specific to their maps.

About the multithreading - you can't REALLY multithread as warcraft runs in one thread.

 

[PurplePoot]

I only skimmed the thread, but this system seems to me to be a fancy way of doing nothing special. I really can't think of an application for this which wouldn't be far easier and more efficient to do with raw vJass.

 

[spiwn]

About the multithreading - you can't REALLY multithread as warcraft runs in one thread.

I used to think that, but ExecuteFunc is said to start the executed function in a new thread.
P.s. Yeah, I know this has no relevance at all.

 

[PurplePoot]

So does TriggerExecute, or any other method of executing triggeractions (firing events etc).

 

[Nestharus]

In the information on vjass, it always said that the max was 8192. Hm..

Well, considering this new information (I was thinking of making v2.1 use a global struct anyways) I'm going to change around some of the design a bit. With some of these design changes, it'll make it easier to do certain things and still keep it at top speed.

Thank you for your input. This means I Need to re-write some things ; P. But I still do see a need for something like MOPS. Every system still needs a system to manage it. That system can run thru VJass, but the system is still needed. toadcop's inventory menu system has a memory system to run it that goes through vjass. In fact, most advanced systems have something like that. MOPS is going to be here to hoepfuly be the best data management system around that'll have full vjass capabilities.

Yes, this means I'm going to have to redesign it a bit.

Also, structs are not classes. If they are meant to be classes in vjass, then please change the name because that is not an accurate description. And structs are not object orientated. Classes are. I just talked to one of the foremost experts in the world about this and that's what he said ; P. If you want to argue with him, you're arguing with one of the top instructors on microsoft based information technologies in the entire world ^_^. He hasn't looked at jassnewgen, but he said either the terminologies are wrong or the people are wrong. So, just getting that cleared out ^_^. If JassNewGen was updated to go beyond structs and into classes, then please update the terminology because a struct is not the same thing as a class.

Okie, so... MOPS is going to change a bit to run the jassnewgen. What this means is that you'll be able to use it for those quick timers. This'll be an upgrade to it. This will delay MOPS for a bit. But purplepoot, I agree with you, and as I said before, v2.1 was going to be redone. I think I even said this in a previous post that I'd change the back end of it. Those changes would include better multi-threading capabilities and a change from the current design into a design that ran fully through jassnewgen.

I just think JassNewGen should be upgraded to have these capabilities because it'll make map design a whole lot faster and easier for people. However, with this design, as you pointed out, it won't be as efficient. The only way to do dynamically named variables is by storing them as a string.

Another thing, purplepoot... I'll tell you how some of MOPS runs at the moment.

When a variable is made, that variable's main information is in a public setting. This means any object that uses that variable uses that public information. If you change that public information, you change all objects using it. From here, you can extend that variable with new public information or private information that's used for a set of objects or a single object. This is done through the use of object clusters. Now, the real thing is the complicated use of pointers and ID tags. It'll go through the pointers linking all of the data together and use the ID tags to filter out the data. That's how this works.

You can also override public data for an object. That object, and only that object will ignore the pieces of overwritten public data to use the private new data instead. In this way you are using one single object to define 50 objects that have the same base structure. These 50 objects can be loaded into an object pool to use that single object (a set of variables). I tried showing it in those charts in the first post, but a lot of people didn't understand them very well : ). Now, these are extended and manipulated in-game. You can't do this with raw vjass. You have to design a system.

So, in short, I'm changing around MOPS to run through vjass. This will just add new capabilities to vjass and hopefully make everyone's life easier. And as I said before, most systems need a system like this to work. Most systems already have a system built within them to manage the data, but this will hopefully make it so you don't have to do that anymore.

The only weak point in this system is the need to use strings to store variable names. Everything else is worked off of integers or reals, so you will have very few strings compared to what you'd use in a game cache. I had an argument a long time ago with people who said you can just use the game cache and this was one of the main foundations to my argument.

MOPS has changed a lot and it was bound to change again. I was planning to re-write most of it after v2.0 was released because I know a lot of people want it now. It wasn't going to change any of the syntax, just how the back worked. I wasn't being very specific about my planned changes and I do apologize for that.

Hopefully everything is cleared up now ^_^, and hopefully I showed you guys why I found a need for a system like this.

 

[spiwn]

No argue there, this system would be useful. But it should be efficient.
About vJass Structs, hmm ... they are pseudo classes ... pseudo structs ... that is a tough question - it is a matter of how structs are emulated using a compiler.

 

[Nestharus]

Well, after some more thought as to how to design the system through vjass.

For one, it would require the user to know vjass, create their own structs. MOPS would mainly act by allocating data of any type to any function and return data of any type from any function to any degree. This would allow systems to remain private from each other and give systems a mean to communicate with each other.

Through the use of global structs, systems can easily use their own storage systems. From here, this can once again tie in with MOPS by automatically creating a new struct of the specific struct in an array and assigning it to that object. From here, you can have specific extensions to give to that object through the use of extending structs. However, an issue with this that isn't in the current design of MOPS is that a struct can only be extended one time while in game. You can have extensions extend other extensions and so on, but you can't manipulate the actual extension data types and you can't register new data types. So you have to create every possible data type in an extension. Another issue is that you may have 2 of the same data type for one unique instance. There is just a whole slew of problems that arise.

One of the main problems with jassnewgen is that it is too static when it comes to registering new data types with a struct. You can only do it through extending the struct. You do that by calling the extension. But what if you want to extend it further? What if you want to create specific pieces of information for that unit, register only 1 data type, or w/e. You either need to create a whole mess of different extension types and create some sort of pointer system, or you have to overwrite the current extension and pass the data to the new one with an even bigger mess of extension types.

Another issue is that in a system, it can define its own structs right? Well, how does MOPS know what the struct names are. You'd have to go through MOPS and tell it where to look. With the current design, it'll auto make everything. With a new design, you'd have to go through it. Now, I am going to make 2 versions, MOPS Generic and MOPS Map Specific. This way you can create beta versions and alpha versions of your map quickly. After that you can do a few modifications to make it map specific and you're done. You can make this the open version and make the generic the private version so you can easily update information. But oh well, that's just one of many more problems.

Another issue is that it would require systems to be located in one library. It would make users have to know vjass. It would make the system harder to use. I don't even know how much faster it'd actually be. I know the map specific would be extremely fast, but as for the generic..

One more issue. Remember how I talked about extensions? Let's say you have a unit on the map. You want to add a new piece of data and all of its data is full. So you go to the new extension type, clear out the old one etc, and replace it. Takes a bit. Now you want to add 4 pieces of data, so now you have to go to another extension type... clear the old one out... etc...

That is one of the main issues I had with vjass and that's why I wanted to design MOPS. It's not dynamic enough for me. I like to have one function handle everything. I don't like to make 5000000 similar functions or 5000000 similar structs or 5000000 similar objects.

So, after thinking about it, I'm not sure if I can run this through vjass effectively. If I did it'll constrict MOPS too much. either that or add lots of new lines of programming.

How MOPS Is right now is it'll go through an array and open up data slots for you. You tell it how many data slots you want and it'll open those up for you to use. These data slots are totally generic. You can assign specific integer IDs to them. This is not as good as vjass is because in vjass you can assign specific names, but in MOPS it lets you extend it to any amount *while* in the game. In essence, you're creating your own unique extensions while in the game. You don't have to predefine anything. It's a lot more adaptive. Considering this, I might stick with the current design.

And this follows an earlier argument I presented. Remember how I said that when you have the same data types, you can easily use vjass, but when you have dynamic ones that are constantly changing, then MOPS is better. This is why.

Now, I was going to run it through vjass in some ways, but I wasn't sure what I was going to do with it. I thought maybe it was the allocation and multi-threading. But then I said, no, can't be. Why? Because once again the data types are constantly changing and the data amounts are constantly changing.

Now, also, with that issue that you can only assign integer IDs to custom data types (not variable names or object names), this is supposed to be a system for designing other systems. In those other systems, the users of those systems won't have to worry about the integer IDs.

So I see plenty of areas here where MOPS does things vjass just can't do without creating a massive amount of extra code and making the user take a whole lot of extra time. I remember how frustrated I was when I was using MOPS. I tried to dynamically name and set a variable while in-game.

I remember there was something I was going to do to increase the efficiency of this system. v1.0 was all based on strings, now it's all based on integers (increasing speed and efficiency). v2.1 was going to increase it again through something in vjass, but I forgot .

Oh well. You guys have been giving great input, and I'm sure with some constructive feedback, we could figure out how to get this system really shining. The only way to do the stuff I mentioned is to do it through a JASS system. You can't work it through a WE by reformatting code etc because you can't manipulate the data while in-game. Vjass is already the best it can be. MOPS is just here to work things you need to do in vjass while you're inside of the game.

I showed plenty of examples... I came up with these while trying to think of a design concept.

Now, if you are going to have complete pre-defined things, I suggest vjass. MOPS is for something more dynamic.. more realistic.... something that is constantly changing.

Oh well, I'm trying to figure out how to increase the efficiency right now.

In a data type, you have the Data Name (a string), data extension flag, data pointer, a custom data type, data size, and the actual data. For the actual data, different variable types run with it so that you are able to store any amount of any type, such as a string, an integer, a real number, w/e.

In an extension, you have an extension flag, a data pointer, a custom data type, an extension size, and the actual data.

Now, I hope you can see how similar this is to VJass. I hope you can also see the differences here. Every time you do this, it's like creating a new struct, except you're creating it in the game, not in the WE. That's one of the primary differences.

I hope you guys can also see why something like this is very useful and could be needed. It can also save lines of code and it can increase a system's overall flexibility. VJass is not as flexible as this is. I showed plenty of examples as to why that is.

So, yes, you are right, this isn't as efficient, but it's much more efficient than something like a gamecache. It's also a lot more flexible than vjass is because it changes its own structures in-game and defines them based on the in-game data. It doesn't need any preset data.

So, this can be used in conjunction with Vjass. In fact, I really suggest it. Any time you need a very flexible system, you can predefine it with VJass and continue to manipulate it in game (giving it that flexibility) with MOPS. You need both a code formatter and an in-game system to really get the full power of your system.

And from here I've concluded MOPS simply can't use VJass. It creates its own more flexible data structures. When using both of these systems, you no longer have a need for variables (except for local variables).

So, I'm going to attempt to rewrite some of it. I've already locked off v2.0 and I'm already doing some redesigning for v2.1

Please, more thoughts and feedback? I want to see what you all think of my conclusions.

By the way, I just had an idea about connecting structs to MOPS. Let's say you want to create your base data for an object. I'll have a struct type variable array that'll run through MOPS. You can create that struct within MOPS that'll be used within a variable. From here, you can extend that struct through the MOPS system by adding any type of data to any degree. You can create structures and so on with the extensions in the vjass area, but to add new data in-game, you must extend it through MOPS. This will also improve overwriting capabilities and make the system more efficient.

 

[spiwn]

This thread inspired me to create this (CSS)
As the name suggests(see map), it is an useless dynamical struct handling system.
It just was fun
P.s. Took me 6-7 hours of not very intense coding to do this. And I have missed one text macro(yeap just one run), so in this map there is a bug.

 

[Nestharus]

from that example, it doesn't look like you understand what MOPS is used for..

Yes, you can do what you just did more easily with regular vjass.

If you read the last post I did... it lists some examples you can't do easily with vjass.

Also, if you read the last post I did, you'll see vjass will now be enabled in MOPS -.-.

Also, the system you designed does not run the same as MOPS does... thus it's useless and pointless.. it's just as flexible as vjass. So, you don't understand the capabilities of MOPS.

Example 1:
You have a unit on the map. It uses a unit struct that gives it all of its data. It's actually an extension (goes through a tree collecting data etc just like MOPS would use object clusters for).

Now, you want to add a new piece of data to this unit, a special piece of data. First, you'd need to create a unique extension just for this unit (annoying) and repoint its data to this extension. Now you need another extension, etc, etc. You'd have to have a list of all possible extensions. All of these data are special instances for this unit, and every unit has different special instances that are all completely unique and are based on the map. So let's say you just make all possible extensions happen in the struct. Well, let's say sometimes it might take any amount of integers. So, you create a list of 100 integers hoping that'll be enough. Well, maybe it isn't.

Now, if you did this in MOPS.. First, you create your struct and you're a happy kitty. You store it in MOPS as the object. You can even create the entire data structure.

Now, you want to extend the data with like 60 integers. You extend it through MOPS and add 60 new slots. Done. Wasn't that easier than creating entire lists of structs and extensions and so on? From here, it was easier than re-writing unit data every single time you had to add something new.

Now, I know that this wouldn't happen very often or for very many maps, so if you just ran this through MOPS, it'd be the same speed as structs =/=, exact same speed. It would just give you this new option and a few other options.

Let's say the player wants to make a complete unique instance of a new object that'll have x number of integer values, x number of reals, x number of this, x number of that, w/e. Now, in structs, you'd create a massive struct etc. From there... it'd get even more difficult because you'd have to store each value in each piece of the struct. In this instance, you'd have to use the MOPS features to create a new struct. Let's say it takes some values from an old struct. You just load it into the object with the struct in it and done. If you're planning for more, you can make an object cluster, load the struct into that, and then load the objects into that.

So, it's the exact same speed as structs when you're only using structs. If you do have instances that would be INSANELY hard to do in plain vjass, MOPS has those features available.

Also, it allows you to name your unique struct instances with dynamic variable names if you want to so you can more easily point unit data to it. It allows you to privately extend structs.

Also, you don't have to make structs if you don't want to. You can create the structs while the game is running. This is slower. I suggest you make all the structs you need, then extend them as you need in-game. If you have static extensions, not like the instances I described above, then you should just make struct extensions. You can run this through MOPS and I promise you it'll be the same speed. It'll be slightly slower if you decide to name your unique struct instances with variable names because the only way it can do this is with a string name. If you don't, it'll store it in a global array and you'll have to access it by index.

Another thing, I see you can add any type of data to any degree with it, but the data has to be accessed by specific names, etc. Also, with the MOPS system, I told you that new feature. So, my system is faster, it can do a bit more... it's just supposed to add new features to structs that'd be the exact same speed. -.-

Also, here's the reason it's been taking me a long time. I keep re-programming it. Every time I see a new feature, I add it in. Every time I see something that could be done better, I redo it. Btw, I did just see a new feature in this post. Right now, you have to name each object and variable, but I'll allow you to do it by index too from now on so that you can have the exact same speeds as structs...

If you guys still think it's useless, you guys obviously don't understand me and you''ll have to tell me so so I can explain it in a different light. But, it's not a useless system and it can do things that are normally extremely difficult, time consuming, and so on to do in vjass. It'll also save you a lot of code. I have need for stuff like this because every system I create always has enormous flexibility and I've had to design a mini-MOPS for every system.

First, I was designing a maze system... it automatically found terrain and loaded terrain properties into it. From here, it automatically created units for you, it did everything. It also separated terrain based on level barriers and grid barriers.

What did this need?

A mini-MOPS system and a mini-gridding system.

From here I wanted to do menus etc for setting difficult, picking a hero, and so forth. What would that have needed? a mini-GUI in-game menu system.

So in just about every case I need those 3 systems when I design a full map. Btw, the mini-GUI in-game menu system would have needed another mini-gridding system.

So, tell me if you still think this is useless. What you design in WE was *Totally* different from MOPS. I hope you can see why now. For one, you can only add 1 variable type when you do that. It can't take x amount of integers or x amount of reals. If you wanted it to be able to, then it wouldn't be dynamic anymore because you'd have to be able to run it through a loop.

It's just designed poorly. It's apparent that you didn't spend a lot of time on it.

= )

 

[GhostWolf]

The so called "Structs" that vJass uses are a hybrid of Structures and Classes and are used exactly like Classes, and therefore are OOP.

OOP is the simple idea of using objects (class instances) with each one having separate variables (class members) and each one having access to functions that are unique to the class (class methods).
You can do all that with vJass's Structs.

 

[spiwn]

Please accept my apologies for not being too clear. What I posted, up there, was not intended to compete against MOPS in any way
I said that what I posted was useless, not MOPS. But yes MOPS' usability is rather questionable. And yes I do not fully understand what MOPS does.

Hmm, please tell me(maybe on PM, in order not to spam this thread), what did you mean by "you can only add 1 variable type when you do that. It can't take x amount of integers or x amount of reals" ?

About MOPS:
Why do you even care what other people think about it. You should create it for yourself (and if you decide to share with others after that) not for others.
And about customization and features - having too much of them makes it a bit user-unfriendly(or should I say noob/nub/newbie/idiot unfriendly) - they always seem to mess something.

And if you want people to understand you, you should not go in much detail (having more text, than code ). You should give summarized information(while reading your posts I tend to lose myself between the lines occasionally, and have to reread), not everything.

Whether structures or classes, is an interesting question and the answer depends only on the point of view. For instance if a C++ programmer had to answer, he would say they are structs, because members are public by default.

P.s. I think CSS has some potential, but as the name states...
And that is pretty much as far as my skills go at the moment.

 

[Nestharus]

I'll edit the first post later with more clear meaning, k. I did add in some new features, so..

 

[GhostWolf]

Whether structures or classes, is an interesting question and the answer depends only on the point of view. For instance if a C++ programmer had to answer, he would say they are structs, because members are public by default.

Structs do not have methods, for god sake.

(sorry for spamming, I have nothing else to do)

 

[spiwn]

The only difference between structs and classes in C++ is that the members of a struct have public visibility by default, and the members of a class have private visibility by default.

As I said, depends on the point of view.

 

[Nestharus]

A class is by reference and a struct is by value

There, issue settled >: (.

Now, imma write that essay I promised all of you explaining extremely clearly what MOPS does and why it's very useful, ok? ^_^

 

[GhostWolf]

Who is the idiot who said that ?
Structs DO NOT have methods

Structs simply let you bundle different types of variables.

 

[Nestharus]

edit for a dumb response

 

[GhostWolf]

Oh really ? I do not care what a "leading programmer bla bla bla" said, mind trying using methods inside structs ?

[edit] ha... ha... *blush* you can use methods inside structs... /me suicides

And about a class using the original - each class instance uses its own unique members.
For example:

class bla
{
    public:
            float x, y, z;
}

bla var = new bla;
bla var2 = new bla;
var.x = 10; // this won't change var2's x

 

[spiwn]

And about a class using the original - each class instance uses its own unique members.
For example:

class bla
{
    public:
            float x, y, z;
}

bla var = new bla;
bla var2 = new bla;
var.x = 10; // this won't change var2's x

You did not get what he meant.

And that is in C++, in C(and other programming languages) I think structs do not have member functions - they are just structs of data.

 

[Nestharus]

sry, I thought you were referring to something else. He never did say anything about structs etc having methods ; p.

The only thing he did say was the difference between a class and a struct, so ;p.

Once again, sry : (

 

[Sevion]

Nestherus:

[12:38] Having Second Thoughts ;o: hey sevion
[12:38] Having Second Thoughts ;o: can u post on there that I'm thinking about waiting for SC2 and seeing what needs to be done there
[12:38] Having Second Thoughts ;o: =P
[12:38] Having Second Thoughts ;o: I might not finnish MOPS
[12:38] Having Second Thoughts ;o: if anyone is interested in taking off where I left off
[12:38] Having Second Thoughts ;o: send me an email at [email protected]

Anyone interested? I'd gladly use MOPS if anyone cared to finish it. But. If Mr. Solomon wants to wait for SC2. I will follow his lead. SC2 FTW!

 

[Nestharus]

Just putting in a final note.

If this is worked on again and finished meaning I didn't just wait for SC2, I will simply post it up for download. I will only post information about it when it is done.

If it isn't, that means I am waiting for Starcraft 2. I know some of you were excited about this, but there are only a few months left of warcraft 3.

For map editing, SC2 will simply be better. Wc3 will be obsolete =/=, so there will really be no point to stick around on this.

Also, from what I've heard of the programming language, there won't be a need for something like MOPS ^_^, which means people like me, system designers, will be able to just dive right into the systems we want to design without having to design rudimentary systems like MOPS.

I'm sure some systems will still be required to be designed such as a 3D grid system and possibly a GUI system.

Oh well.

MOPS would have been good and it would have been useful for many maps, but... not many more maps are going to be made in wc3.

In SC2, things like save/load systems might not even be needed. You might be allowed to store data on a server or on the player computer. Who really knows what's going to happen, but I think it's best to wait and find out, but that's just my own opinion.

I'm sure some people are going to end up staying on wc3. That's good for them, but when looking at these games from a map maker's perspective, there's really no point unless SC2 ends up adding a lot more restrictions and so on ;o.

Cya in a few months : D

 

[Eleandor]

1) It's a good practice
2) SC2 is not gonna be finished within the next year
3) Everything taken into account, we hardly know anything of SC2's programming language, its strengths or it weaknesses.
4) A lot of people will probably stay at wc3 because of the fantasy background. I don't think it'll die soon. Granted, I too will go to sc2 modding, but I can see a lot of people staying behind.

 

[Element of Water]

3) Everything taken into account, we hardly know anything of SC2's programming language, its strengths or it weaknesses.

I thought people were saying it is going to be a c++ API? I hope it is, as I am experienced in c++...

 

[GhostWolf]

I won't build on it, as most of the people who mod it now won't be able to mod anymore. Who do you know here that knows how to program ? (and no, I do not call Jass programming)

Even if they'll do, they'll probably give us a well made interference that will make it similiar to Jass just with less restrictions.

All this is my opinion of course.

 

[spiwn]

This is not a thread about SC2 discussion!!!
Though I say that we do not know anything about SC2's map making capabilities, so far.

 

[Herman]

Uhhhh.....

I might be talking extremely stupid here, but I don't see how one could beat out structs

Structs are just global arrays, and whenever you use .create(), it just indexes it up for the sake of MUI, after which it indexes back down (recycles the index) when using .destroy(), so for the most part you only use the same memory over and over, and for those special cases, you use twice as much

All of this is pretty minimal, unless your storing a few hundred values in a struct

I am assuming your very good at real programming, and understand how the variables are created in JASS for war3, and hence the whole intro about memory at startup.

I did not yet see your system, nor read these three pages before it, and I am going to do so now.

EDIT - 3D Grid System???

Warcraft3 has an X, a Y, and to top it off, a Z!

I do believe that is 3 dimensions

Lastly, I will never use your MOPS system, you go on and on and on about terms you've made up yourself that do not correlate to any code that I can use to translate into something I actually want to learn!!!!

Bastard.

 

[Nestharus]

Uh, 3D *Griding* System

I don't think you understand what Grid means.

Next, MOPS creates data structures in-game, so it gives much more flexibility. If you wanted to design a fully realistic game where players could literally create any sort of item or character imaginable, MOPS would be the way to go.

And uhm.. I'll be getting back to this project when I can. Right now I'm really trying to finish up that old save/load system. I ended up re-writing a lot of it because I came up with more new ideas ><.

 

[Herman]

Uh, 3D *Griding* System

I don't think you understand what Grid means.

Next, MOPS creates data structures in-game, so it gives much more flexibility. If you wanted to design a fully realistic game where players could literally create any sort of item or character imaginable, MOPS would be the way to go.

And uhm.. I'll be getting back to this project when I can. Right now I'm really trying to finish up that old save/load system. I ended up re-writing a lot of it because I came up with more new ideas ><.

You can already do that. Again, how does it give more flexibility??? When your talking about 'Grid' perhaps it would help if you would elaborate?? And you can already attach as much data as you'd like to items or units, UnitUserData and ItemUserData have been provided by war3 already

As long as you are under 8192 of each, you can do it quickly without a problem. If your making a system that can handle more than that, than I am interested, but for the love of god provide some code so we can understand what your really talking about.

 

[Sevion]

Humm...... Nes. I don't think making MOPS is really worth it..... no one understands what it's for. Why give something to the people who won't appreciate it?

 

[spiwn]

Ffs.
He will make it and use it himself.
Doesn't matter if anyone else will ever use it.
But putting it here, after finishing it, would be appreciated and would allow people to choose whether to use on their own experiences with it.

 

[Eleandor]

I thought people were saying it is going to be a c++ API? I hope it is, as I am experienced in c++...

All we know is that it's a language based on c.
They haven't said it contains OOP functionality (since they didn't say it's based on c++)
They have said the same about jass: "jass is going to be a language based on c".

I can't call "based on c" enough information on the strengths of a programming language. Maybe you can, but I can't. I sure hope it'll be powerful and at the very least contain pointer functionality...

And nes, the next time you post about one of your awesome projects, post your code too. Hyping us up is not good if
- there's nothing to see here (no offence intended, but all we've seen is a post which - in my opinion - isn't really making clear what it's all about)
- we don't get what you're trying to do if you don't give a decent example we can all "experience".

You've done the same with your ultra compression system. Even if you claim it to be working we want to see the map, not see a bunch of text...

 

[PurplePoot]

Herman, new versions of vJass provide more than 8192 struct instances.

The "Realistic items and units" example is rather bad, seeing as you can do that fine with vJass.

 

[Herman]

Herman, new versions of vJass provide more than 8192 struct instances.

The "Realistic items and units" example is rather bad, seeing as you can do that fine with vJass.

*Offtopic* - I knows, I just hate using it as it makes it really in-efficient, turning array calls into function calls, unless there is a newer, better way its done, I am very much against it