Galaxy Problems - Petition draft

[gex]

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.

 

[13lade619]

so vJASS is pretty much 'more powerful' than Galaxy as of now, because Galaxy is too limited?

 

[Steel]

Oh wow, problems in a game at the Beta stage? In an Editor to a map that isn't quite complete?


You should be marking these as suggestions, not direct complains about what they have done. I'm still in awe of everything they have managed to stuff into this editor, I think we should all be grateful that they decided to give us this to play with so early. Any problems you run into should be posted about as bug reports.


To directly comment on your post on that website:

You mention pointers, I'm going to link you to this: http://www.thehelper.net/forums/showthread.php?t=149629
Yes pointers are unsafe, they should not be allowable in any regard. There is no safe way to go about giving access to pointers. I've written hacks before, if I can get something to write into your memory, I can take control of your computer.


Blizzard has stated they want to move away from people using the trigger editor heavily. To make complex spells you no longer need hundreds of lines of code, the data editor can handle all of this for you. You may retort that some basic features you're wanting are missing. Time and time again people have posted about getting mouseX mouseY coordinates in real time. They said they will have support for these, they aren't in just yet. I've been tinkering around with the Data Editor so much that I can tell that this thing clearly is not done yet.

 

[gex]

Well I will not write them to Blizzard in the way they stand there, of course. And of course, they are only suggestions when written to blizzard. But believe me, I made enough WC3 maps where I needed stuff like that but just hadn't got it. Of course, I can do it like vexorian and make call tables by wrapping each function in a trigger and then having a trigger array. But this will slow down everything, unnecessarily!

And about "using the trigger editor less heavily": They rather meant you don't have to use it for special effects and weapons and stuff. And that is good! It is cool that you can do so much in the XML files right now. But still, these files are static, so for dynamic behavior we still need the triggers.

And what you say about pointers is not true for galaxy pointers. The codespace was protected very good:
-You could not access anything out of it
-You couldn't access code space from data space and vice versa
-We even used pointer arithmetics to hack the stack and change the return address of the current stack frame. All we could do with it was jumping around a bit (but only in codespace, everything else was forbidden) or crash the triggerthread.

No matter what we did, or what data we casted to what other data with pointers, we could NEITHER crash SC2 NOR access anything we re not allowed to access. The worst you can really do is to crash the thread (but this can also be archieved by a division by zero, so it is no real problem).

Pointers in a VM are not as harmful as C++ pointers because Blizzard can track each dereferenciation and decide if it is allowed.

But let's play the case that you are right and blizzard is unable to handle this unsafety! Then there is still my last suggestion: Give us back pointers but remove pointer arithmetics. This way you still have their power but there is no way (since you can't even cast them) to do something harmful with them (of course, stuff like nulling a pointer once its adress is no longer valid, like if it points in a stack fram e that is no longer there, is still necessary).

 

[Cookiemaster]

SC2 is still in beta; but still, 2MB limit on script including variables?

How is anybody supposed to make anything worthwhile with this?!

 

[gex]

SC2 is still in beta

This is why I think it is the right time to tell them NOW, because right now, they still listen to every report and suggestion.

so vJASS is pretty much 'more powerful' than Galaxy as of now, because Galaxy is too limited?

It will always stay more powerful I guess. But with my suggested changes, we can make languages that are much more performant than vJass because vJass had to rely on Jass's limited features.

 

[Steel]

This is why I think it is the right time to tell them NOW, because right now, they still listen to every report and suggestion.



It will always stay more powerful I guess. But with my suggested changes, we can make languages that are much more performant than vJass because vJass had to rely on Jass's limited features.

vJASS didn't do anything new to the language but clever find replace to make the features in it work.

I remember when WC3 first came out. People were so pissed because it didn't do XYZ or rather they stated that it couldn't. Look at it now, you have someone who wrote a physics engine to make a dodge ball game? You have complex RPGs with save and load systems. You have multiboards with progress bars (multiboards). You have death prevention abilities, some of the most unique and awe inspiring abilities. Hell, some of the abilities in DoTA were lifted and could possibly be seen in WoW's next expansion.

I think your only real complain is the limitation on the script. I could see this being a very big problem. I don't think there are limitations in the code that we can't figure out. I always pose a problem to my friends: Anything they can think of, I can code it. The WC3 community was just about the same, someone asked if it could be done, a dozen people would try and succeed. I think it is a bit to early to say the can and can nots.

Wait for the brilliant map makers from Wc3 get a feel for the Editor, some people it's a whole new language to them. It's only a matter of time before some amazing things are to come of it.

 

[gex]

I don't think there are limitations in the code that we can't figure out. I always pose a problem to my friends: Anything they can think of, I can code it. The WC3 community was just about the same, someone asked if it could be done, a dozen people would try and succeed. I think it is a bit to early to say the can and can nots.

Well of course everything works. Galaxy is turing complete, so you can basically code anything with it. But that is no argument, also Brainfuck is turing complete! The argument is, how elegant and efficient can things be implemented.

Example: Pointers will speed up things. As I stated, I can also make a call table with triggers, but who likes a virtual function call that takes around 10x longer than a normal one, if we could have it with just function pointers for around 1.5x a normal call?

 

[Darthfett]

SC2 is still in beta; but still, 2MB limit on script including variables?

How is anybody supposed to make anything worthwhile with this?!

2MB is plenty of room for script and variables. If this included imports and objects however, it would be a whole different story.

Oh wow, problems in a game at the Beta stage? In an Editor to a map that isn't quite complete?

You should be marking these as suggestions, not direct complains about what they have done.

I agree with Steel here. The editor is not finished, this is a beta test (where they are specifically asking for feedback), not some finished product that you paid $60 for and are unhappy with. If there's a feature that is missing or a bug that exists, tell Blizzard. Explain what you're trying to achieve, because there may end up being a simpler way to do it (as they may have foresaw your request).

 

[Vestras]

2MB is plenty of room for script and variables. If this included imports and objects however, it would be a whole different story.

2MB is nothing. As geX said in the post he linked to, 2MB will be filled up by 60 arrays.

 

[Darthfett]

2MB is nothing. As geX said in the post he linked to, 2MB will be filled up by 60 arrays.

Oh? I thought it was 2MB for the code, which had nothing to do with the memory for the game. Sorry for missing the link.

 

[Steel]

Pretty sure that 2MB would be a regression and they wouldn't have that sort of limitation in the launch. It might have something to do with playing these maps on Battle.net right now, clogging things up perhaps?

 

[phyrex1an]

Pretty sure that 2MB would be a regression and they wouldn't have that sort of limitation in the launch. It might have something to do with playing these maps on Battle.net right now, clogging things up perhaps?

In the linked article they say that blizzard uses 21bit addressing so it's not like they just do a "if memory > 2MB then crash". The platform is designed with this limitation, chaining it means redesigning the platform (unless they have spare bits somewhere but that seems unlikely...).

 

[gex]

In the linked article they say that blizzard uses 21bit addressing so it's not like they just do a "if memory > 2MB then crash". The platform is designed with this limitation, chaining it means redesigning the platform (unless they have spare bits somewhere but that seems unlikely...).

this is correct, it is because Blizzard tries to pack one operation (op code + register + operand) into 4 bytes. This is just no good idea, normal register machines just have operations that are 8 bytes long if they need an operand (first 4 byte op code + registers, second four byte operand).
Since their opcodes have 6 bit and 5 bits are necessary to specify the register to load the content of the adress to, there are only 21 bits left for the actual pointer operand.

 

[Zwiebelchen]

The 2^21 limit is a really serious issue and needs to be adressed as fast as possible, if this is really true.
100% agree to the topic opener here, except that I do not really see the reason why their should be pointers, really.

I mean ... all handle variables are pointers anyways, aren't they? At least I could not give you an example where a non-pointer unit would make sense.

The only thing where pointers would really make sense is for functions. I agree to you there. But this can be done without implementing "general" pointers to the language.

 

[gex]

The only thing where pointers would really make sense is for functions. I agree to you there. But this can be done without implementing "general" pointers to the language.

Yes, but you need the concept back at least.

 

[Zwiebelchen]

Yes, but you need the concept back at least.

Hmm ...
I don't agree here. Don't get me wrong ... I love absolute freedom and stuff and would always welcome such an addition, but I also respect the possibility that someone could abuse this to hack your system.
And yes, I read your post about the pointer safety in SC2, but how can you tell that there isn't any other way? I would not be so sure about that.

If you now add the fact that the purpose of pointers in Galaxy would be extremely limited anyways (as I said, there ARE pointers in galaxy, they are just automaticly pointers), I simply think that the risk is not worth the gain.

This, however, doesn't go for function pointers, which I think are VERY useful (especially for something like an AI engine, where you would simply attach the AI function to the unit type). They could do this the same way they made unit pointers; simply threat is like an ordinary variable but use it as a pointer internally.

 

[kioSk]

I neither agree. You can get everything to work without using pointers. And I don't want maps to be able to freely mess around in my main memory

 

[Jesus4Lyf]

I think your only real complain is the limitation on the script. I could see this being a very big problem.

+1.

What's the point of Andromeda if we have these features natively? Write pointers yourself using integers pointing to arrays. Function pointers are achievable with triggers and globals in a similar manner. Asking Blizzard to implement it is like begging for another 1.23 patch, somewhere down the line...

Dynamic struct allocation is neither a requirement. In all my GUI systems so far, I've been writing allocators which allocate integer pointers to struct arrays, and it works fine.

If the 2mb limit was lifted, anything is possible. That is the only real problem so far.

Of course, feel free to change the wording of that doc to say "dynamic struct allocation would be kind of nice natively". Just can't stand this "we're missing out if you don't include it" business. I will not sign something that states "No pointers" is under "Very severe problems".

 

[gex]

okay, maybe I should change my wording a bit, true true.

But do you really want to argue that we need no function pointers because we can use triggers? I want to make maps where performance matters, and I just don't think triggers will have the performance I require. I want a language where such stuff can be done with high performance and not "somehow".

And that you had to write own allocators for your systems is of course no problem. But honestly, I don't want to care about allocation when writing code. I want an alloc and a dealloc and not do the stuff myself.