Hello, everyone. Nice to meet you all. I am happy to participate in your community.

On topic, I made a programming language that compiles into a UMS map. It's called LangUMS and you can check it out here - https://github.com/AlexanderDzhoganov/langums
There is a thread on TeamLiquid where most of the discussion is, but I'll make sure to answer questions and provide support here also.

Welcome.

Now, that's something interesting! I was thinking about an analogue to specify triggers, but this looks like you're working on a higher level of abstraction. Gotta look into it.

ah this is dope. Maybe you've heard of Oreo Triggers?

LangUMS is not a preprocessor that generates triggers (well it does, just indirectly). It's a programming language that runs on triggers, think of a VM. It has arithmetic, conditionals, expressions, etc. All gets evaluated at run-time inside the game.

Post has been edited 1 time(s), last time on May 1 2017, 9:59 pm by nlight.

Interesting project.

I made C library a while back with similar intentions as this project has. I haven't too much time to look deeply into yours, but are there any conspicuous advantages to an entire language versus a C library (with the latter having the advantage of directly supporting middleware)? I see event handlers but a C library could also support that as well with function pointers / certain GCC extensions.

Also, algorithmic generation of units/locations are pretty useful for certain non-EUDA grid systems. The ability to manipulate all CHK sections is also a plus.

It's not a language that generates triggers, it's a language that gets compiled into triggers.

I'm not someone who is very knowledgable on this topic, but isn't that effectively the same?

You put code in, and you get triggers out. Why does the method matter to the person using these systems?

It's the question of what's the difference between a code generator and a compiler and it comes down to how deeply the thing that is looking at the input code is going to understand it. Code generators in general have a very shallow view of the thing they're expressing, they don't "understand" the full semantics of neither the input or the output. That is they are more or less glorified copy/ paste machines. A real programming language compiler on the other hand is deeply integrated with the meaning of the thing it's doing. From purely practical standpoint this means it can catch most errors at compile-time and can prevent a huge category of bugs that a human or a simple code generator never could. It also opens the door for sophisticated optimization which would be nigh impossible to do on raw trigger definitions. All this means that eventually a sophisticated enough compiler will be able to produce more efficient triggers than any human or codegen ever could.

Post has been edited 1 time(s), last time on May 2 2017, 12:51 am by nlight.

The beginning and end is the same. It's just the technical aspect and functionality that is different. I can appreciate what he's doing, but to me it's just something that I will pass on again.

I enjoy writing out triggers as they currently stand with Draft's text triggers in N++, it might take more time and be harder in the end, but I like the busy bee aspect of it. Mainly because I am fucking weird.

So, in short this is Oreo Triggers with error checking?

Technically speaking this is really really cool, well done OP!

No, LangUMS is a real programming language and compiler and not a simplistic token-based preprocessor, though no offense to the author of Oreo Triggers it looks cool for what it is.
Here is stuff you can do with LangUMS out of the box:

- Arithmetic - addition, subtraction, multiplication, division
- Branching logic (if statements), loops (while loops)
- Expressions e.g. (foo * 3 + 14)
- Boolean operators (foo && bar)
- Local variables with block scope
- You can even call built-ins with expressions like spawn(TerranMarine, Player1, myMarineCount, MyLocation);

And maybe most importantly LangUMS code is sequential and lineariazable and prevents you from introducing race conditions. Why this is important is a Master's level course on programming so I'll spare you the details but it allows you to reason much more easily about what your code is doing unlike when working with the default parallel trigger machine.

Post has been edited 2 time(s), last time on May 2 2017, 10:49 am by nlight.

I did a map without hyper triggers, to allow replays to change speed and to reduce map lag. I didn't have the luxury of fast triggers, so a lot of brute force approaches to problem solving took too long to iterate. Everything I did had to be done within one cycle, and sequencing was ... interesting. How does your program do this? I introduced a couple of different "sequence" death counts that served solely as a way to make sure things were done in the right order. Is this what you've done? Do you rely on hypertriggers for your compiler to work properly?

This sounds almost correct. The compiler does not rely on hypertriggers to work properly, but it does add them automatically and by default (as there is no downside to it I think?). I can easily make it an option to not emit the hypertriggers and everything should still work just slower.

Oreo Triggers features all of this. Maybe you underestimate the power of the custom functions? A few comments on the less obvious ones. Most rely on knowing that sc checks all triggers every loop though: (Which is a given if you make triggers for sc*)
- loops: = just use "if" because sc does the loop
- expressions: The documentation doesn't say anything about it, but lets assume it doesn't work, then you need 3 operations (*, +, and whatever you use the expression for) --> Comfort
- Boolean: && = another condition, || = another trigger, but okay you got me with the other operators. Would have to use other functions for those: NOT: if then else --> Higher abstraction
- Scoped variables: Okay got me again, but I question the usefulness in the environment of a sc map project. Especially since whatever code you produce has to use global variables because that's the only thing sc knows.

So there's 2 aspects I'd acknowledge LangUMS does a bit better. But both are not that revolutionary that you couldn't compare the two or that an update couldn't add to Oreo, if necessary.

*) unless, of course, when your goal is to let people make triggers that have no idea how sc's trigger engine works. That's what I included in the "error checking". You can be unaware of trigger order and some such.
Don't think because I said "in short" I want to sweep that under the rug. Quite the opposite, actually. If your trigger language is (becomes) that smart to know all of sc's quirks, oddities and mechanics it would indeed make a mappers life easier.

Not exactly sure what you mean with this. Sc's engine checks triggers sequentially; there's never a problem with race condition because the triggers can access a dc variable, for example, only one after another.

Hello,

I've followed the usage directions verbatim and I've run into this problem in the attached picture. What did I do incorrectly?

It is a real tragedy, as I want to start using your tool. It looks awesome! I am very excited. Another stupid question, besides the already stupid one:

What do your global/local variables use as memory? These are converted into triggers somehow, so therefore is it possible to accidentally manipulate these? For instance, if I set global foo=10, and then I clear unit deaths for TerranMarine on a whim, what's the chance that I've just deleted foo?

Attachments:

Sorry to hear you're having issues. Could you join the discord @ https://discord.gg/TNehfve so I can help figure it out?


All variables are backed by death counts. By default the compiler uses only death counts for units that can't be spawned (or can't die) in the game. There are about 410 of those. There is a way to pass your own list of death counts with the --reg option.

Post has been edited 1 time(s), last time on May 2 2017, 5:07 pm by nlight.

I havent tested out your program yet but i plan to. This looks really cool! Sounds like a lot of work. Good job!

this sounds like some good shit and makes me actually want to try to make a map. nice work boss!