Well actually, I thought it would be more convenient that you could introduce enums instead of having a struct with the convention of the naming prefixes (for the case I was thinking, encapsulating a block of static variables and use them more like enums.)
Also, I would not say namespaces exists just for the naming prefix - it is more often I find myself writing "using" if I want to use a namespace. But indeed, nested namespaces is something I would like either way (however, in C# as you pointed out above, you don't actually have to nest namespaces that way - what you wrote could be replaced by "namespace Foo.Bar { } "). It does really help organizing the code and make it more modular, more like packages.
Speaking of which, there seems to be a compiler error with namespaces if you exclude using the "using" keyword.
Your code above for instance, does not work properly.
If I try to access Foo.Bar.Derp, it thows the error "Unable to find anything matching Bar.Derp". If I add "using Foo" it will work, with both Foo.Bar.Derp and Bar.Derp.
But that explanation you gave gives a better argument to have nested scopes:P What I meant with my code was:
structFoo{Barbar;}structBar{intderp;}Foofoo;
And then when being accessed, write foo.bar.derp. Though this is only a faked way of what I would want Foo.Bar.Derp to be using statics and nested scopes. And these do differ when processed and compiled.
I never meant that the first code was valid either (since it was what I was requesting as implementation, with a given example), only what I found reasonably fair that the compiler could give in return from it.
I would actually preper nestings, in particular since I want to make a conversion of the galaxy standard library into a neater scope format like in g++. The namespaces in particular or nested struct implementation would have been more desirable there.
As it is now, the implementation of:
struct Foo
{
struct Bar
{
static int Derp = 0;
}
}
Could easily be converted to Foo_Bar_Derp when compiled, instead of:
struct Foo
{
Bar bar;
}
struct Bar
{
static int Derp;
}
Not only does that create less readable code, but also a longer time to write the code, and would be compiled differently (would it not? Assuming we talk about no level of optimization right now)?
Would there per chance in the near future be added support for nested namespaces and structs/classes?
(or else, if it already exist, provide documentation of the proper syntax)
Edit:
After the latest patch(es) my project doesn't compile anymore. I know what's causing the issue, but I hope you will correct it as it was before.
This compiled in the past but does now throw the error:
"To refference a static field/property , you must type Foo.Bar" (Also fix that spelling error, it should be reference)
The problem with this is, that now I always have to write the struct name before I access the static variables when I'm inside the struct scope. It shouldn't be required. It makes sense that you need to type the scope name from outside, but not from the inside :p
Edit2:
It would be conveninent if one could copy and paste error messages as text to the clipboard, as one can't do that now.
Short and simple. The galaxy scripting language provides no support for constant values in records. Your alternative is to place them outside, that's all I cn think of.
You could also simulate having a record storing constant values by only creating one object instance of the record initialized with your "constant" data. Say you have a record called SMath or something, with the values PI, E, PI_OVER_2 etc, and then have an instance "Math", you could basically access it by Math.PI, which is a quite convenient syntax.
Yeah, a very simple way of doing it is to create a trigger registering when any player leaves the game, then counting all active players left and end game for the last player if he is the last player (I do assume or recall, that Active Players is a group returning all human playing players in game still playing).
Strangely enough, it does not seem to do that. Or rather, if you create a map with no external dependencies but Core, all external variables you will find when testing the map is the ones retrieved from natives.galaxy, ai.galaxy etc, and not NativeLib itself. And the default field for Trigger Libraries in the Gameplay Data is empty here.
<-> Oh wait, I see what you mean now. Yes, if you create a trigger and allow it to generate a mapscript, it will include NativeLib as default, and thus load it.
If you save the map as folder format and override mapscript.galaxy to not include NativeLib, but natives.galaxy instead, NativeLib wont be loaded at all.
(Conclusively, the problem seems to be somewhat less severe.)
---
A few more points on galaxy memory limitations and overriding:
All constants, triggers, variables etc, not created by the user, eg constants in natives.galaxy, everything in NativeLib and so on, will drastically decrease the amount of memory you can use. The 2MB limit is set for the entire memory pool, included what Blizzard loads within their libraries (that's what I got out of it when I overrided natives.galaxy, could perhaps need verification).
Bools have the same size as a byte.
You can override natives.galaxy and even define and implement the main entry point of the map (void InitMap()) here.
I recently discovered as well, that you can circumvent the need of overriding nativelib and libertylib.galaxy, and as well computer.galaxy
This is, at least, when having the Liberty mod as a dependency on your map.
Seeing in the Data Editor, and then under Gameplay Data, there's a field AI which you can set to load specific AI scripts (computer.galaxy) by default.
Theres also a field called Trigger Libraries which loads LibertyLib.galaxy (and LibertyLib will preload NativeLib as well). Removing these should solve many weird preloadings.
If no external mod is loaded but the Core.mod at all, I think the way we found out is the way to do it, eg, overriding it with empty scripts.
A pretty frustrating error:
Collapsed sections, (eg if elses, /* */ comments etc.) messes up scrolling and the lines you should write on completely. The marker get positioned awkvard and writes on lines you don't want to write on.
I hope you still have some time available to work on the editor, I have seen no updates in a while.
Oh, and also, what's up with the server? I wasn't able to send an error report through the editor, and the link on the first thread seems invalid now.
There is more. People in the "Looking for Custom Games" channel mostly are looking for.... melee games. It's so hilarious and sad at the same time that I can't even decide if I shall laugh or cry about it. Since you can easily see the most popular maps in the popularity list, it makes almost no sense to look for people in the chat channels. That's why it takes so long to fill up your own maps if they are not at the top of the list.
And that's also unchanged since wc3. If you want players for your game, you didn't look on the generic Blizzard channels - You looked mostly on your clan channel. Yes, clans do not exists in sc2 as in the sense of having the tag like in wc3, but it shouldn't prevent you from joining a clan or group, and ask people in those channels. Blizzard's official channels are usually silly, and has ever been due to the people there.
That's very interesting, the only one I seem to have had problems with, is Darken (for some reason I got the alpha wrong)
Taken pretty much directly from that thread, here's what I had for mine:
// There are blendstates (blend modes)publicstaticclassBlendStateExtra{publicstaticBlendStateSubtract=newBlendState{ColorSourceBlend=Blend.SourceAlpha,ColorDestinationBlend=Blend.One,ColorBlendFunction=BlendFunction.ReverseSubtract,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.One,AlphaBlendFunction=BlendFunction.ReverseSubtract};publicstaticBlendStateMultiply=newBlendState{ColorSourceBlend=Blend.DestinationColor,ColorDestinationBlend=Blend.InverseSourceAlpha,ColorBlendFunction=BlendFunction.Add,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.InverseSourceAlpha};publicstaticBlendStateScreen=newBlendState{ColorSourceBlend=Blend.InverseDestinationColor,ColorDestinationBlend=Blend.InverseSourceAlpha,ColorBlendFunction=BlendFunction.Add,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.InverseSourceAlpha};// Darken seems to fail and draw black where it's supposingly transparancy.publicstaticBlendStateDarken=newBlendState{ColorSourceBlend=Blend.One,ColorDestinationBlend=Blend.One,ColorBlendFunction=BlendFunction.Min,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.InverseSourceAlpha,};publicstaticBlendStateLighten=newBlendState{ColorSourceBlend=Blend.One,ColorDestinationBlend=Blend.One,ColorBlendFunction=BlendFunction.Max,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.InverseSourceAlpha};}
As for restarting the map, Mindy (MindWorX) told me that they made it in the sparsile project, but he never told me exactly how. Try to contact him (and I could also let him know to respond in this thread) to find out.
I recall they told for HotS, that they are implementing an UI designer. So far, I have seen nothing pointing towards them easing up dialog and dialog item creation. Time will tell though.
I just have to set GraphicsDevice.RenderState.SourceBlend, GraphicsDevice.RenderState.DestinationBlend and GraphicsDevice.RenderState.BlendFunction to the right stuff.. There are some examples here http://forums.create.msdn.com/forums/p/75039/457237.aspx
It's not that much work.
Haha yeah, I know that article, I've been using it myself. It's still only valid for XNA 4.0. Point was anyway, that in 3.1 you'll have so many more things to set, if you compare the versions. Be prepared that they might not work right from the start though (I had troubles with some of them), but oh well.
Edit: I have a request by the way. It would be very very convenient if you added the option to test the map even though starcraft is already running. There is a restart argument as far as I know, which you can send to the game. As such, it allows you to test the map much faster since reloading will take much lesser time, for the compensation of memory usage.
Layout files exsist simply to create a template that defines the structure (visual elements) of your dialog and can indeed reference race dependent assets. Once you have defined the template you will use the Hookup Dialog Item In Panel function to create a Dialog Item reference. You can then interact with this Dialog Item on a per player basis, as you would any other. All the dynamic logic for your layout, enabling/disabling buttons, show/hiding images, setting text values, etc. is still be handled by script.
There are also a lot of Dialog Item properties in layout files that the native script does not expose. An example are the frame elements Animating, AnimDuration, AnimColums, AnimCount that allow you to define sprite sheet animated images such as the autocast effect that command buttons use.
And hooking from templates has its drawback now too as currently they are flawed when it comes to all properties which are exposed through galaxy natives. Why? Well, if you hook up a layout for your dialog, it will set its values correct internally, but not from the proxy part from galaxy. Hence, trying to access any of the properties you might have set such as visible/enabled/image etc. is impossible. The native functions will spit out an error back at you from them.
As such, you will also need to set the dialog properties manually upon initialization, and that renders templates almost useless in the first place.
Ah, I see :) , not that I think using Draw multiply times to compose the dialog or item is going to yield any huge performance difference (since, (depending on mode ofcourse) a draw call is effectivily between a spritebatch draw and a spritebatch end, hence it still is the same amount of draw calls as yours), yours seem very convenient. Oh yeah, though, like you said, the arithmetic is on the gpu, so that is nicer.
Regarding the blendmodes, I looked up the compatibility with xna 3.1. Looks like you'll have to do much more things more manually using the RenderState class, rather than the BlendStates already easily supported for 4.0.
0
Well actually, I thought it would be more convenient that you could introduce enums instead of having a struct with the convention of the naming prefixes (for the case I was thinking, encapsulating a block of static variables and use them more like enums.)
Also, I would not say namespaces exists just for the naming prefix - it is more often I find myself writing "using" if I want to use a namespace. But indeed, nested namespaces is something I would like either way (however, in C# as you pointed out above, you don't actually have to nest namespaces that way - what you wrote could be replaced by "namespace Foo.Bar { } "). It does really help organizing the code and make it more modular, more like packages.
Speaking of which, there seems to be a compiler error with namespaces if you exclude using the "using" keyword. Your code above for instance, does not work properly.
If I try to access Foo.Bar.Derp, it thows the error "Unable to find anything matching Bar.Derp". If I add "using Foo" it will work, with both Foo.Bar.Derp and Bar.Derp.
0
Ah, my mistake.
But that explanation you gave gives a better argument to have nested scopes:P What I meant with my code was:
And then when being accessed, write foo.bar.derp. Though this is only a faked way of what I would want Foo.Bar.Derp to be using statics and nested scopes. And these do differ when processed and compiled.
I never meant that the first code was valid either (since it was what I was requesting as implementation, with a given example), only what I found reasonably fair that the compiler could give in return from it.
0
I would actually preper nestings, in particular since I want to make a conversion of the galaxy standard library into a neater scope format like in g
++. The namespaces in particular or nested struct implementation would have been more desirable there.As it is now, the implementation of: struct Foo { struct Bar { static int Derp = 0; } }
Could easily be converted to Foo_Bar_Derp when compiled, instead of:
struct Foo { Bar bar; }
struct Bar { static int Derp; }
Not only does that create less readable code, but also a longer time to write the code, and would be compiled differently (would it not? Assuming we talk about no level of optimization right now)?
0
Would there per chance in the near future be added support for nested namespaces and structs/classes? (or else, if it already exist, provide documentation of the proper syntax)
Edit: After the latest patch(es) my project doesn't compile anymore. I know what's causing the issue, but I hope you will correct it as it was before.
consider the following code:
This compiled in the past but does now throw the error: "To refference a static field/property , you must type Foo.Bar" (Also fix that spelling error, it should be reference) The problem with this is, that now I always have to write the struct name before I access the static variables when I'm inside the struct scope. It shouldn't be required. It makes sense that you need to type the scope name from outside, but not from the inside :p
Edit2: It would be conveninent if one could copy and paste error messages as text to the clipboard, as one can't do that now.
0
Short and simple. The galaxy scripting language provides no support for constant values in records. Your alternative is to place them outside, that's all I cn think of.
You could also simulate having a record storing constant values by only creating one object instance of the record initialized with your "constant" data. Say you have a record called SMath or something, with the values PI, E, PI_OVER_2 etc, and then have an instance "Math", you could basically access it by Math.PI, which is a quite convenient syntax.
0
Yeah, a very simple way of doing it is to create a trigger registering when any player leaves the game, then counting all active players left and end game for the last player if he is the last player (I do assume or recall, that Active Players is a group returning all human playing players in game still playing).
So, as an example:
0
@Deaod: Go
Strangely enough, it does not seem to do that. Or rather, if you create a map with no external dependencies but Core, all external variables you will find when testing the map is the ones retrieved from natives.galaxy, ai.galaxy etc, and not NativeLib itself. And the default field for Trigger Libraries in the Gameplay Data is empty here.
<-> Oh wait, I see what you mean now. Yes, if you create a trigger and allow it to generate a mapscript, it will include NativeLib as default, and thus load it. If you save the map as folder format and override mapscript.galaxy to not include NativeLib, but natives.galaxy instead, NativeLib wont be loaded at all. (Conclusively, the problem seems to be somewhat less severe.)
---A few more points on galaxy memory limitations and overriding:0
@Deaod: Go
I recently discovered as well, that you can circumvent the need of overriding nativelib and libertylib.galaxy, and as well computer.galaxy This is, at least, when having the Liberty mod as a dependency on your map.
Seeing in the Data Editor, and then under Gameplay Data, there's a field AI which you can set to load specific AI scripts (computer.galaxy) by default. Theres also a field called Trigger Libraries which loads LibertyLib.galaxy (and LibertyLib will preload NativeLib as well). Removing these should solve many weird preloadings.
If no external mod is loaded but the Core.mod at all, I think the way we found out is the way to do it, eg, overriding it with empty scripts.
0
A pretty frustrating error: Collapsed sections, (eg if elses, /* */ comments etc.) messes up scrolling and the lines you should write on completely. The marker get positioned awkvard and writes on lines you don't want to write on.
I hope you still have some time available to work on the editor, I have seen no updates in a while.
Oh, and also, what's up with the server? I wasn't able to send an error report through the editor, and the link on the first thread seems invalid now.
//Mexa0
And that's also unchanged since wc3. If you want players for your game, you didn't look on the generic Blizzard channels - You looked mostly on your clan channel. Yes, clans do not exists in sc2 as in the sense of having the tag like in wc3, but it shouldn't prevent you from joining a clan or group, and ask people in those channels. Blizzard's official channels are usually silly, and has ever been due to the people there.
0
That's very interesting, the only one I seem to have had problems with, is Darken (for some reason I got the alpha wrong)
Taken pretty much directly from that thread, here's what I had for mine:
But unfortunantly it requires XNA 4.0, and also the "Reach"´graphics profile only available there as well. The rest of the blendfunctions (alpha, additive) was already included in XNA 4.0 as static blend states ( http://www.innovativegames.net/blog/blog/2010/07/13/xna-4-0-blend-states/ )
-------As for restarting the map, Mindy (MindWorX) told me that they made it in the sparsile project, but he never told me exactly how. Try to contact him (and I could also let him know to respond in this thread) to find out.
0
@progammer: Go
I recall they told for HotS, that they are implementing an UI designer. So far, I have seen nothing pointing towards them easing up dialog and dialog item creation. Time will tell though.
0
Haha yeah, I know that article, I've been using it myself. It's still only valid for XNA 4.0. Point was anyway, that in 3.1 you'll have so many more things to set, if you compare the versions. Be prepared that they might not work right from the start though (I had troubles with some of them), but oh well.
Edit: I have a request by the way. It would be very very convenient if you added the option to test the map even though starcraft is already running. There is a restart argument as far as I know, which you can send to the game. As such, it allows you to test the map much faster since reloading will take much lesser time, for the compensation of memory usage.
0
And hooking from templates has its drawback now too as currently they are flawed when it comes to all properties which are exposed through galaxy natives. Why? Well, if you hook up a layout for your dialog, it will set its values correct internally, but not from the proxy part from galaxy. Hence, trying to access any of the properties you might have set such as visible/enabled/image etc. is impossible. The native functions will spit out an error back at you from them.
As such, you will also need to set the dialog properties manually upon initialization, and that renders templates almost useless in the first place.
0
Ah, I see :) , not that I think using Draw multiply times to compose the dialog or item is going to yield any huge performance difference (since, (depending on mode ofcourse) a draw call is effectivily between a spritebatch draw and a spritebatch end, hence it still is the same amount of draw calls as yours), yours seem very convenient. Oh yeah, though, like you said, the arithmetic is on the gpu, so that is nicer.
Regarding the blendmodes, I looked up the compatibility with xna 3.1. Looks like you'll have to do much more things more manually using the RenderState class, rather than the BlendStates already easily supported for 4.0.