In addition, if people agree, I think we should begin using typedef to suggest parameter values.
We could come up with a standard "Types.galaxy" which just has stuff like...
typedef int player_t;
typedef int unitflags_t;
Since this kind of shared dependency couldn't just be included in every library, we could implement a dependency notation, so that the map author knows to include these dependencies ahead of including your library.
Ex:
//#include <Types.galaxy>
This kind of commented C-style include is pretty distinctive and would be a heads up.
Jademus and I have talked about this a lot casually in IRC, but I don't think anyone's ever really made a post about it. The things that make Galaxy strong are it's speed of development, file-based modularity, and support for things such as constants in array declaration.
Probably the strongest plus-side of Galaxy is that we can export individual files as a library for a simple "include" statement, and have someone else using it in seconds. Also, since Galaxy is inherently plaintext, glancing over the library before importing is extremely easy. With the benefit of even the half-broken "static" modifier, we can hide library's internal mechanics and organize our code in a much cleaner fashion.
If we really want to showcase Galaxy like JASS was in WC3, we need to start making our own code in our maps modular, and uploading generic libraries to this forum, or the Assets section of Mapster (don't forget to leave a note here, too!).
So my challenge to you Galaxy programmers is over the next few weeks, to look at your map's code, improve it by modularizing it, and then post the modularized libraries in this forum.
I'll start by listing some libraries I've been working on.
We also need to start standardizing our code. What I've found works for me best is:
Library prefix: libLibraryName_
(Applied to all private/public functions, as well as any variables in the global scope. This prevents collisions with other libraries)
Ex:
Constant prefix: c_libNameVariableName
(Applied to any constants in the global scope. This method is consistent with Blizzard's Galaxy coding style.)
Ex:
I recently came into a need for a hashing library that supported something secure like SHA256.
In any case, I found magnificence7's GUI library asset on Mapster: http://www.sc2mapster.com/assets/md5-hash/.
This would be his library ported to Galaxy. I've removed all of the ugly GUI parts, and all of the variables have been encapsulated into the libHash_ prefix.
wanting or not wanting to learn has nothing to do with it. Since nobody won't "just make it for me" as you said, I will have no choice but to do it myself. Thing is, I am not naturally good at it. I have no artistic inclination, nor natural understanding of this infernal contraption other than I built it. I hate books and reading, I am a full learn by doing person. If I can't learn it as I actually do something and go along, I get sick and quit. I don't give a darn about game creation philosophy or how the mind of the gamer works. I JUST WANNA MAKE SOMETHING THAT ISN'T A BUNCH OF BOXES!
That kind of attitude is fairly stupid. It takes a lot of work to build a game engine even, much less an actual 3d game.
These things don't happen overnight.
You need to start small, with pointless and boring stuff, before you can move on to try something more advanced.
I think you guys should remember the OP is at a very basic level right now. He shouldn't be even remotely worried about encryption until much, much later in the process of learning.
He should be focusing on the basics of maintaining P2P connections, or a large number of connections to a single node, in an efficient and OOP fashion.
You could probably, with statistical analysis, figure out how many times the average player plays your map per day, and use that to create durations like "1 day" but it'd be readily exploitable anyways.
0
I already talked to Sixen. He knew nothing. Lol
0
And now it's gone. WHAT?
I'm seriously confused here.
0
I woke up today, made a long post in the Galaxy Scripting forum, and then I noticed I have Curse Premium after that.
Why?
WHY?
It's going to kill me.
0
In addition, if people agree, I think we should begin using typedef to suggest parameter values.
We could come up with a standard "Types.galaxy" which just has stuff like...
typedef int player_t;
typedef int unitflags_t;
Since this kind of shared dependency couldn't just be included in every library, we could implement a dependency notation, so that the map author knows to include these dependencies ahead of including your library.
Ex:
//#include <Types.galaxy>
This kind of commented C-style include is pretty distinctive and would be a heads up.
0
Jademus and I have talked about this a lot casually in IRC, but I don't think anyone's ever really made a post about it. The things that make Galaxy strong are it's speed of development, file-based modularity, and support for things such as constants in array declaration.
Probably the strongest plus-side of Galaxy is that we can export individual files as a library for a simple "include" statement, and have someone else using it in seconds. Also, since Galaxy is inherently plaintext, glancing over the library before importing is extremely easy. With the benefit of even the half-broken "static" modifier, we can hide library's internal mechanics and organize our code in a much cleaner fashion.
If we really want to showcase Galaxy like JASS was in WC3, we need to start making our own code in our maps modular, and uploading generic libraries to this forum, or the Assets section of Mapster (don't forget to leave a note here, too!).
So my challenge to you Galaxy programmers is over the next few weeks, to look at your map's code, improve it by modularizing it, and then post the modularized libraries in this forum.
I'll start by listing some libraries I've been working on.
Modified Melee Library based on Phantom Mode, with enhanced configuration options
https://github.com/Motive/LibPhantom
Dialog-based WoW-style action bar GUI drawing
https://github.com/Motive/CortexEngine/blob/master/Common/lib/libactionbar.galaxy
We also need to start standardizing our code. What I've found works for me best is:
Library prefix: libLibraryName_
(Applied to all private/public functions, as well as any variables in the global scope. This prevents collisions with other libraries)
Ex:
Constant prefix: c_libNameVariableName
(Applied to any constants in the global scope. This method is consistent with Blizzard's Galaxy coding style.)
Ex:
0
But I've already won.
0
I recently came into a need for a hashing library that supported something secure like SHA256. In any case, I found magnificence7's GUI library asset on Mapster: http://www.sc2mapster.com/assets/md5-hash/.
This would be his library ported to Galaxy. I've removed all of the ugly GUI parts, and all of the variables have been encapsulated into the libHash_ prefix.
Enjoy. https://github.com/Motive/CortexEngine/blob/master/Common/lib/libhashlib.galaxy
0
SWEET JUSTICE, THE TIME HAS COME.
BEGONE, FOUL RODRIGO DEBATESLING.
MY ANIMATED AVATAR HAS RETURNED!
0
Did it work?
0
@Zolden: Go
Some properties are read-only, such as c_unitPropRadius.
0
@FuzzYD: Go
.galaxy files for whatever reason aren't including as part of the MPQ hierarchy between mod and map. So, that doesn't work. :(
0
@iSaintx: Go
You're thinking about it wrong.
Think about it this way, what if everyone starts with 1 free coin, and more bonus coins for every extra "point" they have.
With a while loop, you'd have to do:
0
That kind of attitude is fairly stupid. It takes a lot of work to build a game engine even, much less an actual 3d game.
These things don't happen overnight.
You need to start small, with pointless and boring stuff, before you can move on to try something more advanced.
0
@Mephs: Go
I think you guys should remember the OP is at a very basic level right now. He shouldn't be even remotely worried about encryption until much, much later in the process of learning.
He should be focusing on the basics of maintaining P2P connections, or a large number of connections to a single node, in an efficient and OOP fashion.
0
@Cloud_Wolf: Go
Negatory.
You could probably, with statistical analysis, figure out how many times the average player plays your map per day, and use that to create durations like "1 day" but it'd be readily exploitable anyways.
TL;DR: no