Staredit Network

evilopel, what exactly is the problem? If he thinks he can help some people out, it's no skin off your nose. Hell, even if he's the only one who uses it it may be worth it to him to make it. I don't see what you're objecting against. Are you telling him his time would be better spent on something else? Because it's up to him what he does with his time, whether or not you like what he's doing.

As much as you complain about the StarCraft "elitists" pushing newer mappers around, the topic never comes up unless you bring it up.

I'm not objecting against it, I'm just asking people what the whole point is. Nobody answered and one person called me "a part of the mindless" (something that I've covered in a previous post).

I'm not telling him anything, I'm just asking why this, instead of a GUI trigger editor?

You make it sound as if though this is the 15th thread I'm mentioning it in. I've only brought up the "topic" just now, saying that they're not pushing newer mappers around but acting high and mighty because they've learned some pointless crap (who knows, it might not be as pointless as I thought, although I have a feeling that it will be pretty much unnecessary to most people here).

The Catholic elite pushed around the king and much of Europe for a couple hundred years and the illiterate and ignorant thought suffering on earth would give them a heavenly reward. Only very few people got high enough into the Catholic elite to understand the Bible, but still have ties with the common people to realize that something's wrong.

Just a thought.

Hmmm... why text and not a GUI editor...

Well, it's personal preference really. If you're thinking about a graphical programming language like RoboLab or Arena, I know that those languages are just as powerful as any other language and they're both quite easy to use, but I find them clunky and slow compared to text based languages, the same way you find text based languages clunky and slow compared to graphical programming languages.

I could imagine a graphical programming language for StarCraft, where you drag a "Create Unit" module, and you can select "Marine" from a categorised list of units and a little display of a Marine appears on your page. Your bring conditions could display next to your locations in your map view, and you could link pieces together in a series to create a trigger process and such.

I realise that'd be incredibly cool to use, and it would be unbelievably easy for anyone to understand their triggers, but like I said with RoboLab and Arena, I can code faster by typing, and typing also suits my way of thinking. Not only that, I can create a program to understand a text based language faster as well. So I've chosen to make a text based language.

Learning a text based language might be harder than learning a GUI programming language, but it has its benefits. For particular problems or for particular people, the text based language will be more suitable, and that is when people will find that the text based language actually has a point to it. Perhaps I can't convince you that a trigger programming language is not pointless, but I know that for me this language has a point, and so I have a reason to make it, even if no one uses it.

I've never liked the idea of automatic trigger generators. Yeah if you did it right you could be guaranteed that the else wouldn't fire first. Thats mostly just trigger order issues (it's not random)

The trigger I wrote out in trigger code should do that. As long as the If trigger is after the main trigger.

The variables, or death scores, can be used in triggers. You can do almost every possible mathimatical equation, including Addition, Subtraction, Multiplication, and Division, with these "Variables". Decimal numbers are also quite possible(without the decimal itself ).

Let's put it this way.
SCXE - The default trigger editor. People now hate it becuase SF's is text-based and easier to create triggers.
SF - Fastest and "Best" way to create triggers.
This language - Fastest, best (Yes, it is), most functional way to create triggers. Only thing I see is the steep learning curve. Other than that, it'll be like SF triggers vs SCXE all over again.

Yep, completely true . I remember a thread long ago where someone was trying to use death scores such as each death score equaled a specific digit slot, like death1= 2, death2 = 3, death3 = 9, and that would be 239. What ever happened to that thread? I remember him getting stuck on Multiplication and Division. Anyways, this is probably one of the positive things (fact for evolipel coming through!)about this programming editor; cut and paste.

Usually (for me anyways), to make an event on Starcraft, one needs relatively few triggers. But, sometimes, you need to juggle multiple complex triggers with switches, and not exactly everyone jots their ideas for an easy refresher of how the trigs are supposed to be. This is probably where this comes in. Some cases, plain typing is better than looking through a list.

I still hold my ground upon the normal editor being better

This thing sounds Sweet..., maybe i missed something but what language is this in? (c++?) would make mass trigz way easier. copy+pasteing...

This looks very impressive...I especially like the OO feel of it (deaths member of player object, etc). I can't imagine how much code must be going into this though.

The implementation of variable arguments and customized functions in Starforge hasn't really been started yet...

And evolipel...just chill out. People like different things. Rhino isn't trying to make everyone like this system. You seem to be trying to make everyone like GUI trigger editors, which I (and most other programmers, I imagine) hate with a passion. What's good for one person isn't good for others. I definitely agree that a very very small portion of the map making community will find this feasible to use, but I applaud the effort.

...which of course could be partly fixed by a GUI implementation of it in turn.

The fact that so few people would use it is why I scrapped Trigger Happy editor way back when (which was going to be a GUI editor, btw). If that proves not to be the case, then I just might go ahead and finish and release it. Unlikely though.

I completely support this, unlike some people. If you don't like it, then don't complain - it should be obvious that this is an alternative, not a method forced upon you.

I myself only began learning Java last year, but I can imagine how much more flexible it will be to program with something like this. Hell, as soon as I got into the methods of if statements in Java, I was thinking how great it would be if you could program StarCraft triggers this way.

If you really have the kind of time and energy to complete this project, Rhino, please do. I'd love to see this through.

Yeah me too. At least to know whether or not it would be something people could possibly appreciate. If you finish it soon enough, I might use it for the next stage of A&O coming up.

The part that understands the programming language is actually done already, I finished that last week. So it's already generating triggers, just not in a format that StarCraft understands. I can't find any flaws in the system yet, I've been generating several thousand triggers in one gulp (using the programming language to define the patterns to change the triggers progressively) and it is actually generating them without a hitch.

This weekend, probably tomorrow I'll finish that part to a point where I'll be able to create working StarCraft triggers, except whenever I'll need to recompile I'll have to delete the triggers manually. Even though it won't be in release state, at least I'll be able to prove to myself that it's possible.

The version I've been programming now has got the codename Neutrino 2.0, but I don't think that Neutrino 2.0 will go into a public release, considering all the bad publicity the program has gotten I don't think it's a good idea for me to show the final version of Neutrino 2.0 to anyone except my best friends because it will get more "this is hard" than it will get "this is good." Neutrino 1.0 and 2.0 have just been learning experiences for me to create Neutrino 3.0, which I have already designed and redesigned with my new knowledge, and I'm hoping it works like I originally wanted it to. I'll hope it's good enough to release to the public, but we'll see.