SC2Mapster

@Kueken531: Go

Omni is pretty useless at the moment, but wait for Omni 2.0, it will be much better/easier to use, though it might take like 2 more months till I get it done..

@JademusSreg: Go you mad!!

I made those some time ago, and discussed many of my assumptions with Deaod himself, he told that he hasn't made many tests, and my chart would be more complete, I probably tested it more than he. So plz shut up.

Anyway, I didnt made it as the ultimate reference for Galaxy, It just some notes of what I need to know for making sure my parser is correct

Surely, I already knew those docs, though I forgot that they existed, but note that they are pretty old and mines are probably more correct/complete

I wrote my version of those charts just to make it more clear in order to help me write my Galaxy parser ...

@Mille25: Go

I have compiled a list about every type that the game supports (in the Galaxy language), it is here: https://github.com/midiway/Anion/wiki/Galaxy:-type-system

That chart can serve as a listing of every type supported by the game and its characteristics. But it doesn't identify this kind of types that have 'reference' semantics, f.e. trigger is 'reference' based, but it doesnt extends handle, as do the most of the handle types that surely are 'reference' types. I think we can name those types as 'complex types'. And as already noted, integers can also be complex types when they refer to dialogs, for example.

anyone have a key for me?

you could use an arrayref<> of an array of size1

@midiway: Go

just updated it for the last patch

@Alevice: Go

I keep an (almost) updated copy of every .galaxy of the MPQ's here: https://github.com/midiway/Omni/tree/master/ScriptData/TriggerLibs

thats because I updated it to patch 2.0.4, but then the 2.0.5 patch came out

maybe tomorrow I will update it ..

All right, I updated to support the last patch for WoL and HotS since someone asked me

I am making version 2.0 which will change many things, it will have its own compiler for Galaxy and maybe there will also have my own language extension for Galaxy, though it will take sometime to get it finished ...

old times sake

It made me remember a biiiiig terran unit which I cant remember the name that was shown in the first sc2.com. It was like a megazord, it was created by joining terran buildings (the barracks were its legs), buildings started floating and joining in the air. I think the name was Terrathor ...

I also remember that the mothership had a shield that would stop incoming projectiles, after the shield has gone, the projectiles capsules would drop in the floor

or was it just a dream I had? ...

@nestharus: Go My plan for extending intellisense, more specifically the database of symbols keep internally (for displaying autocomplete, nametips, ...), would be letting the user customize it, not just plugins. It would be by reading custom text-blocks with those definitions, those text-blocks located inside the trigger content. For example:

// Define symbol names
#{{icodesymbols
int UNIT_LIB_VERSION = 0x03
int UnitLib_AllocateData(int unitid, string key);
void UnitLib_DeallocateData(int data);
void UnitLib_WatheverOtherFunc()
#}}icodesymbols

// Define snippets
#{{icodesnippet SnippetName
for(int i=0; i<10; i++)
    UnitLib_AllocateData();
#}}icodesnippet

Why this? I am not making another Visual Studio, my effort is toward something really usefull for map-making, not a full-featured IDE. With this approach someone writting a library could define what symbols the library is exporting for the final-user, symbols which would appear in autocompletion, calltips, .., and also the library could define snippets of code that user could insert (like a macro, maybe with parameters, to insert text).

I know ANTLR 4, and only the JAVA target is available. Dont know if you are familiar with DLLs exports, but this is the way Omni loads and communicates with plugins. Im not familiar with JAVA, but I guess you would need to write a DLL in C that Omni can load/talk, while this DLL interops with the JAVA program, what do you think? Are you really making a Galaxy extension with ANTLR?

@nestharus: Go

• Translators: yes it should be supported as plugins, but not really rdy yet, custom highlighters are also doable.
• Intellisense: no user-defined symbols, only the symbols parsed (when Omni is started) from the .galaxy files in the \ScriptData folder of Omni, which at the moment contains the game natives. This kind of runtime parsing would need a lot of work to make, its too advanced.

This tool is supposed to be extensible with plugins support, something I have decided from the beginning when I started it. Its a language tool, so support for translators, preprocessors is of course what I want for plugins. Plugin support is already working as you can see in the plugin named Ion, that comes with Omni: it is a separeted .dll loaded at startup; it is a preprocessor, when you save the map it process the script and returns a modified version of the script, that is, Ion is a translator.

In order to further develop plugin support, its just a matter of we working together in order to I know in what I should focus for supporting plugins.

Version control inside Omni, that is for a very distant future.

New version, now it got overloads!

The major thing is that I implemented a feature (that I called IntelliWrap) to the code editor for wrapping and inserting code from a list of natives or from a list of language constructs (if, while, for, function). I had planned it long ago, but now I dont find it so usefull, but I have better plans for it, so its like a version for seeing how I am making this kind of UI and if anyone like it, but which I can improve, though I wont work in it again any time soon.

@PhiSC2: Go yes, the crash while moving folders to given locations is a known bug, I have to write the checks for invalid places for the dropping, maybe in next release ..

@PhiSC2: Go At some near time I will publish a proper SDK, it is just not ready. But if you already want to learn how to write those plugins before the SDK is released, which is something you would want to learn anyway, start looking at how I wrote Ion, the source is here.

Note that I expect people interested in making plugins to know a bit of C and compiling DLLs for Windows. Main thing to start understanding is the header file for the DLL here.

There is no such thing as you imagine: "how the dll loads the map file", when the map is saved, Omni calls exported functions of the plugin DLL to it do certain things, thats all for plugins.

I will describe what I will let plugins do when the map is saved:

• preprocess the script: plugin receives the raw script of Omni and return a modified version
• compile the script: there can be only one compiler, it will be responsible for receiving the already preprocessed plugin, and 'compile' it to pure Galaxy code, returning the final script of the map to be put in its MPQ
• modify the MPQ: make any changes desired to the map MPQ, just before everything is packed as the .SC2Map

Also plugins can write an interface for the user in form of a panel (as the panel of Ion plugin) which is coded in HTML. The HTML supported is the one of this library, it also supports a scripting language similar to Javascript. I plan also to make a D version of the SDK, just because I am learning D.

As for the requests, already added the one you asked for hidding that space, just wait for the next version. As for the Data tab, havent considered that, and so I am not willing to make it, so many things planned to do ... right now I am working in a widget for showing a list of natives, also I am studying how to write a parser for Galaxy with ANTLR. But you could write with my help a plugin for that ...