Galaxy Problems - Petition draft

[gexxo]

We have found many severe problems in the galaxy language, that limit the language.

I have written an Article about them. It can be found here. What I want is to take this article as a base for a petition to Blizzard to let them know that the mapping community needs those features.

But to be sure, that you really all stand behind me, I want to give you the chance to discuss about that article. If you agree, just answer here with "agree" or "sign". If you have any problems or want to discuss a specific point or add something just do it here.

Note: this post is mirrored on other modding sites to reach more people.

 

[Giantr]

/signed

 

[real138]

/signed.

the memory limit(first problem) is gonna be bad if not fixed... i think they might be only doing this for the beta though? hopefully.

 

[HappyHero]

You all shoud know that blizzard isn't interessted in any petition.

Don't forget, this is a Beta-State editor.
You can believe me when I say: They know that the success of WC3 was heavily influenced by the Editor and they know it will clash on SC2's success the same way, if not even more.
There are definetly enough clever minds that will know about the problems this "BETA STATE" (!!!) Editor has and at least some of them will know they have to improve on the editor...

So don't freak out now, there isn't even a release date known and nobody knows how it will finally look like.

But you gut me:
/signed

 

[gexxo]

You all shoud know that blizzard isn't interessted in any petition.

Don't forget, this is a Beta-State editor.
You can believe me when I say: They know that the success of WC3 was heavily influenced by the Editor and they know it will clash on SC2's success the same way, if not even more.
There are definetly enough clever minds that will know about the problems this "BETA STATE" (!!!) Editor has and at least some of them will know they have to improve on the editor...

So don't freak out now, there isn't even a release date known and nobody knows how it will finally look like.

But you gut me:
/signed

there is a release date, Amazon mailed around 13-15. june.

 

[PurplePoot]

My comments on the petition:

Byte limit: This could be a problem if true. Is that 2mb before or after compression?

Pointers: I agree that this is a problem, although it is hardly "very serious". For that matter, the only reason this is a problem is because the language is otherwise C-based; if you could do stuff like

struct foo {};

foo bar[x];
bar[a] = bar[b];

(people tell me that this doesn't work)

then I can't see this as being a problem, especially since structs should be pass by reference anyways.

You don't "need" function pointers, however I agree that some way to represent functions would be useful; first-class functions are another excellent example of this.

You don't need horrible pointer arithmetic (C style). Your struct example can be solved by:

point3d foo;
foo.x = bar.x;
foo.y = bar.y;
foo.z = something;

Where bar is a point2d. You mention this and suggest that it is inefficient, but if galaxy is properly implemented this should not be any slower than somehow copying all of the point2d in one chunk. Hell, you probably would even find it weird to do it "C style", something like:

point3d *what (point2d *bar) { //this is destructive and stuff
    point3d *foo = (point3d *)realloc(bar,sizeof(struct point3d));
    foo->z = something;
    return foo;
}

We don't "need" inheritance because OO is not necessary. Hell, OO in vJass wasn't even very useful after all was said and done.

Your point about dynamic allocation is a good one assuming there is truly no other workaround.

Functions as strings: this is a fair point, but function pointers are not necessarily the best answer.

--

Most of this reads like "bawww galaxy isn't c(++)". You raise some legitimate points, but I really think you could do with trying a really alternative language and gaining a new perspective on things; I'm the first one to admit that I have a soft spot for C, but it would hardly be my first choice when designing a game's scripting language.

 

[Na_Dann_Ma_GoGo]

Sucks to hear about such huge restrictions already :/
Hope Blizzard's gonna have a look at it... we can just pray!

 

[PurplePoot]

Most of them aren't really restrictions, and several of the rest will probably be addressed, hence including the editor in the beta.

 

[staticfrog]

A petition for something that's not already released? GE just got out. It's still in beta. It's in beta for a reason to.

@gexxo Your still believing unofficial released dates?

 

[PurplePoot]

Also, this is one of the reasons why pointers need to die forever and just making structs pass by reference would be much nicer from a design standpoint:

point3d *what(point2d *source) { //this is the same function as above, only much more awesome
    double *i = (double *)realloc(source,3*sizeof(double));
    *(i+2) = something;
    return (point3d *)i;
}

 

[gexxo]

point3d foo;
foo.x = bar.x;
foo.y = bar.y;
foo.z = something;

Where bar is a point2d. You mention this and suggest that it is inefficient, but if galaxy is properly implemented this should not be any slower than somehow copying all of the point2d in one chunk.

I am not talking about bulk copying the point3d to the function, I am talking about pasisng a pointer to it to the function and just casting it to a point2d pointer. And that costs almost no time. Your example is not doable if structs get larger, imagine a struct Unit (wrapping struct for unit attaching 20 attributes to it) and a subtype of it, for example Building. Do you really want to allocate a local struct Unit and pass all 20 values to it, just to cast from Building to Unit?

point3d *what (point2d *bar) { //this is destructive and stuff
    point3d *foo = (point3d *)realloc(bar,sizeof(struct point3d));
    foo->z = something;
    return foo;
}

That was not what I wanted to express :/ After all I didn't want to cast a point2D to point3D (which makes no sence) but vice versa, this needs no reallocating. I just want any way to mimic inheritance without having to copy any values.

We don't "need" inheritance because OO is not necessary. Hell, OO in vJass wasn't even very useful after all was said and done.

Well you don't need it, but I think there is a bunch of people who would adore to get a OO language for SC2. I am not telling blizzard they should do that, but at least they should give us the tools to create such a language. If you use it then, is of course up to you .

Most of this reads like "bawww galaxy isn't c(++)". You raise some legitimate points, but I really think you could do with trying a really alternative language and gaining a new perspective on things; I'm the first one to admit that I have a soft spot for C, but it would hardly be my first choice when designing a game's scripting language.

Don't get me wrong. I don't want it to be like C/C++, I almost never use these languages (Andromeda is in Java for example), because I also don't like pointers and what mad stuff you can do with them. However, when designing an extension language, pointers are a very mighty tool to compile the extended code to efficient galaxy code. You will never see those pointers, they will be generated by the compiler. As I wrote in Andromeda's Spec.: "Andromda discourages the use of pointers..." so I don't wanna slay the user with pointers, I just want a good base for extensions, especially since they WERE ALREADY IMPLEMENTED! I would never dare to ask blizzard to include pointers if I hadn't already seen them in.
Right now I even dunno how to pass a struct or array to or from a function (since they are not passed by reference by default, that behaviour was only possible with pointers, I am afraid ).

 

[PurplePoot]

I understand what you are saying with regards to "casting" now (I thought you were trying to go the other way, hence confusion). I still think it's unnecessary; just use the child type, since without inheritance you shouldn't have a parent-child relationship structure in the first place.

--

Sure there are a bunch of people who would love for Galaxy to be OO, just like there are a bunch of people who would love for everything to be C++, or for the sky to be made of rainbows. People suck and can't adapt, but that doesn't mean we should support them for it.

--

Pointers are not some inherently superior construct which there is no reason to get rid of if they are already implemented (hint, they are easy as hell to implement and there are plenty of reasons not to have them, which aren't only concerned with usability). As for extensions, I don't really see the need in supporting them, since they seem to have addressed the big problems with wc3's editor that everybody was stuck on and even if we do find more they claim there will be much more active support for the SC2 modding community.

--

If structs and arrays are not pass by reference then Blizzard is stupid or reworking the language.

 

[gexxo]

I have slightly changed the article and do no longer fully rely on pointers, maybe I hit your flavor a bit better now. However, I still think that pointers would be neat.

@purplePoot:
Your opinion is a bit destructive in my PoV. Just "there is no OO, if you need OO, then you are a pussy that can't adapt" (I know you didn't say it this harsh). However, we are not talking about small syntactic sugar, we are talking about paradims. I would do anything to script my SC2 maps OO, not because I can't adapt but because OO makes my code more reusable, structured and understandable.

And the is-child-of relation also makes many things easier. Saying, "you shouldn't have a parent-child relation" just because galaxy doesn't support it is not satisfying.

 

[PurplePoot]

OO is not the strictly best programming paradigm, and if you think it is then you can't adapt, period.

Really, try some different languages which approach problems differently.

 

[gexxo]

OO is not the strictly best programming paradigm, and if you think it is then you can't adapt, period.

Really, try some different languages which approach problems differently.

I did. Almost all of today's languages allow (or require) OOP.

About adapting:
Well there is a difference between "can" and "want". Obviously, if I have no other choice I will adapt, but I don't want to .

But I think we should skip the discussion about whether OOP is good or not, there are billions of forums discussion that. My point is just that many users would appreciate if it was possible.

 

[Mooglefrooglian]

Some way to make scripts and insert them into a map without making functions in GUI would be great.

A way to pass structs is needed. I dont care either way for pointers, but some way to pass/return structs is needed.

OO is nice. Not required, but I would say it would be VERY nice to have. Code is three times more readable, and faster to write to boot. Blizzard doesnt even have to include it, just provide a way to allow us to add mods. Something similar to RubyGems would be nice, actually. But I have no hopes of that.

Sadly, the article link isnt responding. Oh well, will try again some other time.

 

[Dr Super Good]

1.1The 2^21 byte limit

Your evidence? I doubt the truth of this list as you know nothing about WC3 jass let alone SC2. WC3 allocated arrays dynamically based on size up to the 8xxx odd cap. I think they were initially allocated at 16-32 entries and as you hit that border element it added more indexes in powers of 2 until the true max. Or atleast this is what I was lead to believe by people at WC3C.

Additionally you never stated how you found this or provided proof of this existing or the errors this gives when it occors. A simple map with a huge arrays and loops would prove this.

2.1Function pointers

Well, the fact they were partly in means they were removed for safety reasons. Aka probably WC3 code type cast like situation. Basically all they need to do is devise a safe way to use the call instruction on a variable address (how it should be done if instructions support that). The big problem is that if the pointer gets altered in anyway it can link to addresses outside SC2 and so hack other programs. I am sure blizzard will add something like this.

2.2Some way to hand arrays and structs to and from functions

Only affects you if you are using dynamic array creation (a local array). This feature however is not that important as you could just map everything into a global array as a work around however it might be slower in certain situations. Additionally this feature would allow efficent allocation of multi dimensional arrays with variable element dimensions and stuff.

2.3Something to mimic struct inheritance and other stuff (Casting)

Honestly this is just nit picking although might be useful in some cases to reduce redundency and improve memory efficency.

2.4Dynamic allocation

The fact they have a construct for it means that there is a chance it will be in the final product already. The first versions of the beta did not even have support for most of the natives. They even admitted to the public the current editor is incomplete. Additionally if we do not get it now, we can awalys get it added in the 2 expansions.

2.5Triggers and functions as strings

However this supports your dynamic execution of code idea. Want a variable function to run? Just pass a trigger a different function name and run that. I admit this is horriably unefficent as you need a look up table and stuff. However as the game is still in beta it is quite probable this is there for debug purposes (you can actually run functions via a chat message). This would make making their campaigns easier where they could test functions one by one for debugging. Hope its changed to something better on release.

 

[PurplePoot]

I did. Almost all of today's languages allow (or require) OOP.

No they don't, but whatever (or many allow it just because people bitch, but don't really use it, or don't use it in any sense that you would recognize).

About adapting:
Well there is a difference between "can" and "want". Obviously, if I have no other choice I will adapt, but I don't want to .

So they should change the language because you can't accept that there are multiple ways to solve a problem?

A way to pass structs is needed. I dont care either way for pointers, but some way to pass/return structs is needed.

This is true, but pass by reference would be better than pointers.

OO is nice. Not required, but I would say it would be VERY nice to have. Code is three times more readable, and faster to write to boot. Blizzard doesnt even have to include it, just provide a way to allow us to add mods. Something similar to RubyGems would be nice, actually. But I have no hopes of that.

Ugh.

First, when you people say OOP, you usually think of Java (or languages which use a similar model). That is neither the extent nor the origin of OOP.

Second, OOP is not more readable, you're just more used to it. It's often better for extremely large projects, but most maps will not come close to this, and quite frankly structs with functions ("methods") below/above them will do just as good of a job, since inheritance etc aren't really necessary for something as simple as most (all?) maps.

 

[Dr Super Good]

The fact that the editor is so incomplete it took them 2 days to release in europe (apparently it is not even fully localized even), I generally say a lot of stuff is missing from it or not fully added.

However I do agree that blizzard does need to add to it still.

 

[Ardnived]

/signed

We all realize that there will be problems in Beta, but of course we should let Blizzard know about what people have found/want just in case they don't know.

 

[gexxo]

/signed

We all realize that there will be problems in Beta, but of course we should let Blizzard know about what people have found/want just in case they don't know.

exactly.

I am not saying that blizzard is maybe trying to fix that anyway. Just leading them in the right direction .

@Dr Super Good:
How we found out? We debugged the VM and found that it is register machine with 5 bit register adresses (i.e. 32 registers) and 6 bit op code (i.e. up to 64 different operations). In addition, every VM instruction is 4 byte (32 bit).

An important operation for such a VM is the "Load from / Save to address" operation that loads the value from a specific memory address into a register / saves the value in a register to a specific memory address. Whenever you access a variable or call a function, this VM instruction gets/sets the variable value or loads the function address into a special register (the program counter).

So back to the "load from / save to address" operation: It needs 6 bit for the op code and 5 bits to address the register (i.e. into which register should be saved/loaded). Since the VM op is 32 bit, and 11 bit are used by register and op code, there are only 21 bit for the actual memory address to load / save to. This means the VM cannot load or save to addresses higher than 21 bit, since it just cannot address them (just like 32bit systems cannot have more than 4gb RAM, since they can only adress 2^32==4gb).


Prove? Will follow

 

[Omniferous]

/signed

Even though I mostly operate in GUI (I've been creeping out into the real coding language ever since this editor came out... I'm used to C, so it felt more familiar), I've felt some of the effects myself.

 

[Mooglefrooglian]

Second, OOP is not more readable, you're just more used to it. It's often better for extremely large projects, but most maps will not come close to this, and quite frankly structs with functions ("methods") below/above them will do just as good of a job, since inheritance etc aren't really necessary for something as simple as most (all?) maps.

When I say OO, I mean structs with methods. That is all I want. I dont care a whit for inheritance or anything like that. I suppose I should be more clear.

And as for readable, like most English speakers I read from left to right. Non struct variable accessing tend to come with last variable on the outside, and as you go right you reach the inside, whereas structs go first->middle->last.

I do see your points, regardless. But Blizzard introduced structs already, I fail to see why they cant add methods to them or allow us to pass them around. But meh.

 

[Dr Super Good]

Well since you seem too lazy to come up with a simple proof, here is one.

As you can see on the picture, the first 324288 element array is compiled fine in the editor.

The second 324288 element array then raises a compile error asking that the size be reduced despite the first one being able to compile fine (delete / comment out the second and no compile errors will occur).

Both arrays when combined total greater than 2 MB. Alone each one is only 1 and a bit MB. All the proof that is needed to pursuade people of the problem.

Additionally, trying to compile only one array which is 524288 indicies results in the same error (as that is exactly 2MB so should be out of space due to other data).

Additionally on top of that, trying to compile "int[510000] TEST;" results in a "Script too large" error, matching exactly what was complained about.

Thus with proper proof, I agree that this is a major problem that needs adressing.

 

[PurplePoot]

I do see your points, regardless. But Blizzard introduced structs already, I fail to see why they cant add methods to them or allow us to pass them around. But meh.

Because foo(a,b) is so much worse than a.foo(b)?

Structs are not objects, and foo(a,b) fits more with common.galaxy (or whatever it's called) anyways.

 

[gexxo]

Well since you seem too lazy to come up with a simple proof, here is one.

It's not lazyness, I am having the most stressful week of my life, I am moving out my old flat and having to repair / repaint it. I wonder why I even manage to give some answers this week.

But thank you for providing the prove, I wouldn't had time to do it before the weekend.

BTW: You can also test that even the stack is involved in this limit by calling a recursive function with a big local variable (16kb array for example). If you count the recursive calls until the thread crashes with a "pointer moved out of code space", you will also recognize that it crashes at 2mb .

 

[Mooglefrooglian]

Because foo(a,b) is so much worse than a.foo(b)?

Structs are not objects, and foo(a,b) fits more with common.galaxy (or whatever it's called) anyways.

Because ProjectileSetX(p) seems a bit redundant to me, as compared to p.setX()? And what happens if you have two libraries that share a common name? With a class like system, you change one name. With a prefix based method, you have to change 50 functions and all of the calls to them.

Oh well, we shall see what the vJass equivilent will do. Hopefully namespaces!

 

[PurplePoot]

Libraries/namespaces aren't an OOP concept.

Also, if you think function name length being marginally shorter depending on your function naming scheme makes OOP better, then you're stupid... I have no other words for it.

 

[Dr Super Good]

I do not really care about the OOP part of it.

The 2 areas I am concerned about are the lack of pointers to functions and variables and stuff (dynamic array creation might be useful for improved efficency and being able to call variable functions is also very useful as it allows you to avoid huge multiple selection statments for systems while allowing them to be extended more easilly) and the limitied script size (although 2MB is enough for most things it might not cut it for very complicated or big systems with a lot of data).

 

[Palid]

/signed

 

[Zergleb]

GJ on the name calling Poot, but obviously he wasn't referring to written code length. He was referring to inheritance. a base class has setX as a method and then you only have to write that method once for all child classes. You can tell this is what he meant because he said that if you change a method name in OO then you only have to change once, and in without inheritance you are often times left writing many functions all of which have similar functionality and changing them becomes error-prone and a pain. (I'd also like to mention this includes the inside of the method as well, if you fix a bug in a method in OO you change it once and in procedural you need to change it in all similar methods(which sometimes leaves in already fixed bug in an unchecked similar method)).

So as you can tell, he wasn't just referring to just function written length. Misunderstanding posts happens, but I don't see a reason for insults anyway.

I'm not trying to say I see OO programming as better, But it does have a place, each paradigm has it's strengths/weaknesses. A better way of putting that is saying they have situations in which they should be used. And I do think that game programming is a very well suited situation for the OO paradigm.

 

[D4RK_G4ND4LF]

*signs*

right now I think the 1/16 second limit is the second-biggest problem with the minimum online delay being the third-biggest (but they either won't fix this or it will be hacked)

setting the operation limit manually might be even better than disabling it

right now blizzard is very busy to finish the game until release date so they will most likely just ignore us
getting many people to agree with these things will be essential (maybe there is someone who can make a list of people to sign this?)

anyway we don't know yet how the final editor will be like

maybe someone with good command of english could check your text ("Right now, they are SOO limit that they are only useful in global situations", 3.4 is quite messy and a few other minor things)
I couldn't write it better myself though but there are people who can

ps: nice to see you around here gexxo (I read your leak tests and other things at inwarcraft and it helped me a lot

 

[PurplePoot]

GJ on the name calling Poot, but obviously he wasn't referring to written code length. He was referring to inheritance.

I don't see how you can interpret anything other than comparisons of name length based on certain naming schemes from his post, and believing that they matter is stupid, regardless of whether or not you agree with "name-calling".

tl;dr inheritance

Can you actually justify why inheritance is needed in GEdit?

I'm not trying to say I see OO programming as better, But it does have a place, each paradigm has it's strengths/weaknesses. A better way of putting that is saying they have situations in which they should be used. And I do think that game programming is a very well suited situation for the OO paradigm.

But we aren't "game programming"--most of the gritty stuff is already done. We are scripting an engine running in an already written game.

 

[tagg1080]

Purple, you are just gunna have to face it that we live in an OO world.

You crazy C people are becoming a thing of the past. (I am one of you)


I actually think that OO is more convenient in this setting.


Mainly:
-It is easier to collaborate with others in an OO setting.
-It is easier to organize everything in an OO setting.


I am appalled at the amount of people that think that Java is special, and how it is the newest craze, I do personally think that OO has some potential to be a useful architecture for this kind of thing.

If the game was written in C, then OO would be a stupid idea. If the game was written in C++(which I am pretty sure it is as Maya has an extensive C++ library, and I think it is done in Maya?) then not only can OO give some easier ways of working on it, but it might actually give us better function calls if we are given access to the actual functions.



(Java is not special people, it is all C++ under the sheets, please understand that just cuz pointers are not prevalent, that they DO exist, and everything done at the machine level is the exact same)

 

[PurplePoot]

Purple, you are just gunna have to face it that we live in an OO world.

That doesn't make it good. Basically you're saying "most stupid programmers use OO for every situation now, so you should too".

You crazy C people are becoming a thing of the past. (I am one of you)

I'm not a "crazy C person" and I think they're wrong too. I believe there is no best general way to solve problems. You'll find I've done a good deal of work in OO languages, a decent amount of work in C and some other strictly imperative languages (JASS if you want to count that as well), and am probably the strongest advocate of functional programming languages as a way to think about problems differently that visits this forum.

I actually think that OO is more convenient in this setting.

Have you actually coded for any decent amount of time in Warcraft?

I would also have suspected that OO would be awesome in map scripting, but five years of (v)JASS convinced me otherwise.

Mainly:
-It is easier to collaborate with others in an OO setting.

Not true.

-It is easier to organize everything in an OO setting.

Not true either.

Namespaces/libraries provide both of the above advantages (for the most part), which are not an OO concept.

I am appalled at the amount of people that think that Java is special, and how it is the newest craze, I do personally think that OO has some potential to be a useful architecture for this kind of thing.

OO has plenty of potential, it just shouldn't be used everywhere.

If the game was written in C, then OO would be a stupid idea. If the game was written in C++(which I am pretty sure it is as Maya has an extensive C++ library, and I think it is done in Maya?) then not only can OO give some easier ways of working on it, but it might actually give us better function calls if we are given access to the actual functions.

This doesn't make sense. The language that the game is implemented in doesn't really relate to its VM. Also, structs, which make a lot of this stuff easy (and which people would consider part of what makes OO natural for games) are not an OO concept, although methods and inheritance are and are certainly useful for coding the game itself.

(Java is not special people, it is all C++ under the sheets, please understand that just cuz pointers are not prevalent, that they DO exist, and everything done at the machine level is the exact same)

C++ is a horrid beast and I would take Java over it in almost any case (obviously there are cases in which C++ is required for dlls and stuff, but then I'd probably just use C).

Also, they are totally different under the sheets.

 

[tagg1080]

That doesn't make it good. Basically you're saying "most stupid programmers use OO for every situation now, so you should too".

No, I am saying that the people that learn to write code on the internet love it. And that less and less of the people that are not programmers are using anything but it.

Have you actually coded for any decent amount of time in Warcraft?

I would also have suspected that OO would be awesome in map scripting, but five years of (v)JASS convinced me otherwise.

I havn't done too much with war3, but I would assume that OO would be great, could you elaborate?

Not true.

Not true either.

Ah, well, that is an opinion. I personally find that it is easier to understand and follow OO in general when compared. Therefore it is easier for me to collaborate with some1 else if OO is used.

Namespaces/libraries provide both of the above advantages (for the most part), which are not an OO concept.

I never mentioned those,

This doesn't make sense. The language that the game is implemented in doesn't really relate to its VM. Also, structs, which make a lot of this stuff easy (and which people would consider part of what makes OO natural for games) are not an OO concept, although methods and inheritance are and are certainly useful for coding the game itself.

If they used Maya, they probably used C++.
If they used C++, they might have used objects.

In the scripting language say we use UnitAddAbility(), for the sake of mutual understanding.

This COULD translate actually to:
Unit.addAbility()

or whatever.

If the editor used OO, it might be able to skip more steps, and give us closer control to the actual game language.

C++ is a horrid beast and I would take Java over it in almost any case (obviously there are cases in which C++ is required for dlls and stuff, but then I'd probably just use C).

Also, they are totally different under the sheets.

All languages boil down to the same thing.
In java there are methods to write/read objects to and from binary files.

My point is that Java does not magically do that without of the required steps that a C programmer would have to undergo.

 

[Dr Super Good]

Java sacrifices efficency for compatibility and portiblity (especially memory wise due to the lack of being able to dictate what variable sizes are needed). I would personally prefer if we were given more control (more like C) than less control (well currently in some areas this is the case).

For galexy to be a perfect langauge we do need stuff like pointers and maybe additional address ranges (or atleast ones where arrays are handled separatly). Being able to dynamically greate and store arrays would be a great feature and allow for some easy to make and flexible systems. I am aware that the editor can do a lot already, but with structures like that it could do so much more.

 

[PurplePoot]

No, I am saying that the people that learn to write code on the internet love it. And that less and less of the people that are not programmers are using anything but it.

That doesn't make it good. You are making an appeal to common practice.

I havn't done too much with war3, but I would assume that OO would be great, could you elaborate?

I just never found a case in which I needed more than structs (methodless), function interfaces, libraries, and free global declaration, none of which have anything to do with OO (nor a case in which I wish I had used anything else), and this was after coding a great variety of systems.

Ah, well, that is an opinion. I personally find that it is easier to understand and follow OO in general when compared. Therefore it is easier for me to collaborate with some1 else if OO is used.

That's because you're used to OO. I find it easy to understand and follow functional programming languages, and so do most non-programmers I know who learned only a functional programming language (so it isn't just because I'm a programmer or whatever), and they also had trouble following imperative languages like C and Java, while you would find it terribly confusing to write code in a functional style.

If they used Maya, they probably used C++.
If they used C++, they might have used objects.

In the scripting language say we use UnitAddAbility(), for the sake of mutual understanding.

This COULD translate actually to:
Unit.addAbility()

or whatever.

JASS makes calls to functions, not methods, if that is what you are asking.

If the editor used OO, it might be able to skip more steps, and give us closer control to the actual game language.

Do you actually have any evidence for this, or just "because"?

All languages boil down to the same thing.

No they don't.

My point is that Java does not magically do that without of the required steps that a C programmer would have to undergo.

C++ handles objects differently than Java on the back end, period.

--

DSG, none of that stuff needs pointers.

 

[Dr Super Good]

Weather it uses pointers or what ever is beyond the point, the fact the editor does not support it is the point. Most languages like python and java permit you to create lists of lists (python) or an array of arrays (java although it can do lists as well) in a dynamic way. To my knowledge you can not go table[1] = new int[25] in galexy or what ever the syntax would be for something like that as it pre compiles the script mapping arrays and stuff before hand (or alteast it gives that impression).

However I guess I will just have to emulate that behaviour lol. Its nothing more than mapping areas of arrays to certain tasks (lol silly me not thinking of this eariler).

 

[fancy]

/signed
But add the locale problem too! I can't see any text from US maps only Param/Value...And It's very iritating!

 

[Robbepop]

ABSOLUTELY SIGNED !

sometimes i wish i could code with vJass, just to NOT code with galaxy-Gui ...
and those other issues: timer, 2mb-limit (i already reached 1,21mb xDD) are really shit!

Robbepop

 

[Dr Super Good]

If your triggers are 1,21 MB, you must be seriously doing something wrong. Like mentioned eariler thats over 500000 array indicies - code and stuff. You cant honestly be telling me you have 25000+ lines of code already can you? Or is it storing the text form of the triggers as well (if it is then that seriously is messed up).

 

[Robbepop]

hiho,

well im making an RPG map and because of blizzard fails with their user interface and missing functions i had to make my own custom UI and had to store nearly every information of a player and his hero into variables.

my save load system for example which can store the hero data of 8 different heroes per player is already working and just uses variable definitions. xD
but that is how it works! ;-)

about 170 variables (the most with arrays ...) and 9 triggers. xDDD

Robbepop


EDIT: or is it the compressed value which should not increase over this 2mb limit??? atm i mean the non-compressed. =)

 

[PurplePoot]

sometimes i wish i could code with vJass, just to NOT code with galaxy-Gui ...

Then use the scripting language.

and those other issues: timer

We never used timers below 0.03 and 0.04 in Warcraft by the end, and apparently you can do ~0.03 timers in GEdit, so I don't see the issue.

 

[Robbepop]

hiho,

the min timer intervall for me is 0.0625,
and not 0.03 which would be OK then ... xD

but also the data editor and again waits have got the same limit. :-/

Robbepop

 

[PurplePoot]

People say that if you make a timer at 0 second intervals that it will expire every ~0.03.

I have not confirmed this (I have only worked with the Data Editor so far), but that's what they say.

 

[Robbepop]

hiho,

ok thanks for the information.
i will try it out tomorrow. =)

but still my question...
is the 2mb code limit set to the compressed or uncompressed value?

Robbepop

 

[Dr Super Good]

Most SC2 object editor spells do not go below that eithor. If you want smooth movement use an effect as the game I think interpolates the units position in the period between.

You can code usin the scripting language, you are not forced to use the GUI.

Robbepop, your map can easilly reach 4-8 MB in size, only then might battlenet throw you the "map too big" error when trying to publish it. Currently there is no hint for a limit at all so you might even have maps the size of 100s of MB eventually (although they should use mods for the models).

The issue is the virtual machine only supports 2MB of memory due to the virtual machine instructions it uses that the galexy code compiles into. As such your triggers can only use atmost 2MB of address space which in reality is much less as this adress space includes instructions (the actual code you made) and stuff. To reach this limit, even a single line like the one posted above "int[500000] test;" would sufice. As long as you do not allocate many large arrays you will probably never see the limit.

Once again, the limit is nothing related to the galexy script text I believe, it is entirly related to the compiled galexy code size (when in virtual machine instructions) and the areas reserverd for variables that accompany that.

If you are hitting the limit, try not using their GUI and scripting the code yourself more efficently. Yes the GUI is good now, but it still does not provide you with the optimum solution to a problem.

 

[Robbepop]

hiho,

well thanks for your answer.
if it is really just the compressed value, than it is ok. =)
my compressed value is something arround 180kb - slightly less than 2mb!

Robbepop

 

[Dr Super Good]

As far as I know it has nothing to do with compression.... Compile != compress although usually the result is a smaller file due to more efficent storage of instructions. Also the compiled file need not store variables in it only has to consider their existance, as such arrays might not be included in the compiled script size.

I will still consider researching this in more detail.