Staredit Network

The trigger programming language which I was talking about in http://www.staredit.net/index.php?showtopic=9291 is coming along really well. The main structure of the language is the if statement, and that's working well, I'm having no problems there. All 57 trigger actions are understood except for two (you might be able to help, see below).

There are only 5-10 trigger conditions understood at present, I've only just started coding them. It takes about a minute per condition depending on the complexity, so it shouldn't take that long. The resolving of names for things such as units, locations and switches will be added in before the release.

This is some test code that I was getting the program to understand in case you're interested. You can tell it's a test because it doesn't mean anything.




I'm having a problem coding the Set Unit Invincibility and Set Doodad State trigger actions. I can't find in the Campaign Creations trigger specifications in which offset I should stick the enable/disable/toggle value, and even if I did know, I wouldn't know which values to put into the offset (I mean, does enable = 2, disable = 3, toggle = 11 or what). I'm going to have to look at a CHK in a hex editor to find out, but I was wondering if anyone knew off the top of their heads.


I also realised that I'm going to have to make the program read every part of the CHK file to find all the references to each string in the system, so I know which ones the trigger program should remove. Each time you compile your triggers, it will delete all the existing ones and add your new ones, so it should be able to know which strings it can remove along with the triggers. Do you think I could make it so all strings referenced by the existing triggers will be removed, and not worry about the possibility that some strings might be references not only from the triggers but also from other places in the map?



Edit: I also recalled a bit of knowledge I learnt that the string limit is breakable when I was reading the specs. The number of strings you have is stored in the file, so anyone could easily change the 1024 which is stored in all maps to something bigger. I don't know why it hasn't been done yet. I might make that my next project.

[center]People have been working on increasing the string limit for years, I don't think many people have been sucessful.
I just looked at Campaign Creations' CHK specs, and the values for enable/disable/that stuff weren't in them. So I checked on a test map:
Invincibility; 0x04=Enable, 0x05=Disable, 0x06=Toggle.
Doodad State; 0x04=Enable, 0x05=Disable, 0x06=Toggle.
That's what it SHOULD be, not sure though.[/center]

Actually, Heimdal is trying to do just that within starforge. Hes going to take one of my old suggestions and implant variables to be used. So you can use more math when making your maps and do cool stuff.

IF Current player brings at least one dude to location 1, switch 1 is clear THEN
-Actions
-Set Switch 1

ELSE switch 1 is clear
-Actioins
-Set Switch 1

END IF
-----------------

And if you want a preserved IF ELSE

IF Current player accumulates at least 1 mineral, Switch 1 is Set THEN
-Actions
-Set Switch 1
-Preserve Trigger

ELSE switch 1 is clear
-Actions
-Set Switch 1
-Preserve Trigger

END IF switch 1 is set
-clear switch 1
-Preserve Trigger.

Now theres the basic IF ELSE in a trigger form. Now say you wanted a IF / ELSE in the middle of a trigger. If thats the case do this.

Trigger

Description:

MAIN TRIGGER

Conditions:

¤ Whatever

Actions:

¤ Actions Before If

¤ Set Switch 'IF'

¤ Wait 0

¤ Actions After IF

¤ Preserve Trigger

Trigger

Description:

IF

Conditions:

¤ Condidtion of IF

¤ Switch If is Set

Actions:

¤ IF Actions

¤ Clear Switch IF

¤ Preserve Trigger

Trigger

Description:

ELSE

Conditions:

¤ Switch If is set

Actions:

¤ ELSE Actions

¤ Clear Switch IF

¤ Preserve Trigger

It's too much like a programming language. So you're making this just for Bolt or something? Nobody's going to use it, I'll tell you that, unless it was made easier with autocomplete and stuff like that.

Plus, what's with the { and } everywhere, stuff in brackets, the &&, etc?

Well anyway, have fun making Starcraft triggering complicated(Or more complicated for those who think it already is).

Of course it's to make people feel cool and 1337 when using this. Go ahead, be pretentious and see how much farther you get using this than if you simply use a GUI trigger editor. The point of { and } is to make it look more like C++ because everybody knows that if you're a "OMFG PROGRAMMER" and you mention "C++", you're automatically the god of everybody else. A little off topic, but the response to n00bs who ask some inane question is "omfg leearn someting abuot programing", even if the topic doesn't connect to programming in any way. Mentioning it is just a way to boost your ego. Good job, you managed to pretend to know something you didn't and nobody (except for the others who care about what strangers think of them online) really cared.

Now that that's off my mind...
Honestly, what is the point? This is probably harder than making a normal, new GUI trigger editor which would help out a lot (and a whole lot more than this, in my opinion).

You are making sure that strings that are used in multiple sections are not deleted right?

also scmdraft can ignore the string limit and add more, however then you are unable to open the maps in staredit / SCXE. however there is a 64K char limit inherent in the tbl format.

Hmm, interesting... programmers everywhere rejoice I'm sure. Ah well, it sounds really cool and would be useful if you can do something about that string limit though my moneys on Heimdal coming through on that for us first .

Ah well, good luck and have fun making that program .

heh, Heimdal's making a trigger programming language. Oh well, if only someone told me that four weeks ago before I started writing so much code... Heimdal, how far are you with making your programming language? For me, I was just going to add the trigger conditions to the language today, and then make it convert the triggers to a CHK file, then I'd be done. I'm not doing the variables thing, because I want to get a stable finished version done first, then I'll mess around and add extra features.

I have actually been making this for myself so I can make large quantities of complicated triggers faster for a particular map that I was trying to make. I guess if everyone finds it useless I should just keep it within the Starchitects or something. I thought that'd be most people's reaction though, I mean, I saw Bolt's reaction to Garrec's trigger program, and this program is much harder.

Bolt_Head, I've got an if statement already programmed, but I don't know if I'm that happy with it at the moment, so I might look into different ways of setting it up. The problem happens when you have an if on one player, and the else on another. In that case, can you guarantee that the triggers will hit the if trigger before the else trigger? Because the else statement, as you know, works basically like an "always" condition.

What I'm thinking is, let the programmer decide, or maybe even scrap the "else" clause and just let you do your own "elseif(true)" command yourself.

I'm using a death counter to mark the current stage that the map is at, that's the meaning of the process statement at the top of that code in my first post, but it has the same purpose as your switch there. The values of the death counter is automatically managed by the trigger programming language compiler, so if you go:



You could make the compiler generate the same triggers by doing this:



Okay, now I think I'm ranting, and I'm just accentuating to triggersters that the programming language will be really hard for non-programmers. (I bet you're all looking at that and going "What?") But anyway, now that I hear Heimdal's making a bigger and better version of the same thing I guess it might never be used.











Edit: Another thing I could use your input on. How should I do those #enumerate commands? What they do is, if you give them a list, they substitute the $variables in your code with the items in the list. The question in my mind is, do you want it done like this:



Or do you want it like this:

I'd probably get a hell of a lot farther with the GUI than trying to learn some stupid code. Learning it takes time, while someone else could be done 3 complete maps before someone learns this useless code.


A.K.A. 85% of mappers(or more).

Still, I'll just tell you 95% of mappers aren't programmers, and 99%(Of SEN) probably won't use this.

If variables or extra features were added, there'd be no chance of me NOT using it. I'd FIND a way to use it, no matter what.

I like the idea (or so it seems) of having "pre-made" triggers, like If or Else, that are really long lists of actions and conditions.

Good luck!

*Whips out the magical PHP book*
Let's see...do we have:
&& (Logical AND)
ll (Logican OR)
xor (Logical XOR)
! (Logical NOT)

Who cares who uses it. For those who know how; it owns



elif not elseif; elseif looks ugly in syntax

That was EXACTLY my point (I was agreeing, not arguing with you).

What I was saying was that programmers aren't as famed as they are made out to be; it's not the "highest attainable degree of intellectual enlightenment". In fact, nowadays they're getting less money since there are so many people interested.

Yes, this is completely useless except for those pretentious few (or more than "few", we'll see) who take the most convoluted way out of every situation just to show off their amazing skills in nothing.

Edit: "Who cares who uses it. For those who know how; it owns"

Care to explain how it "owns"? Just make a goddamn GUI trigger editor and stop making the system more complicated than it should, feeding the egos of thousands of idiots worldwide. I'm pretty sure it's both easier on the person making the editor and the person who uses the editor. Oh yeah, and don't exclude people out of your elite circle of people who "know how it to use" an unnecessary barrier between you and the trigger format.

Once you get good at it, it should make triggering FASTER.

To make a trigger to move a unit from a location to another location, you need to click a few times in a GUI trigger editor.

To make a trigger to move a unit from a location to another location in this, you need to mind the proper syntaxes, TYPE IN, LINE BY LINE, (or copy and paste, if you're trying to duplicate triggers) CODE THAT WOULD HAVE BEEN REPLACED WITH A FEW CLICKS, and possibly get an ugly error message if you mistype something.

...and that's another thing. To duplicate triggers here, you need to select, copy, and paste. To duplicate triggers in, say, SCXE, you need to click a button.

It's making it more complicated, thus making it slower, not faster.

The thing about the text-based editor is that these triggers suit my way of thinking. As you'll know when you make complex triggers, you don't know every trigger before you start triggerising, and so it helps to have an environment which supports your freedom of thought. This might not be the way for everyone, but for me, I'll finally be able to make that map which I have been wanting to do for ages now.

What's more is, the text based alternative means that triggers can be mass generated by a program such as JavaScript, allowing maximum flexibility. I couldn't have made the scripts for the Doom Dragoon patch until I met IceCC. In one script I had about 600 commands that were almost the same except for a few parameters with about 60 different jumps in them. I don't want to think about how long it would've taken me to make that in ICE.

What I'm saying is, there is a use for everything for those who know how to make the most of it.

Uh-huh... This is an environment that supports your freedom of thought? Just exactly how does it relate to "not knowing every trigger before you start triggerising"? It's more complex. That's all there is to it. If you love convoluted crap and think that making SC triggers is way too easy, this should make things harder. These "triggers" are the SAME. It's just a different way to write them. If this is more comfortable to you (displaying it in a raw-looking fashion, making it harder to find and distinguish certain triggers that you may want to find), that's fine. I just don't want people going "LOL DATS SO EZ ONCE U NO HOW TO USE DEM!1", because my point is, why bother?


I believe that a clean GUI editor with a mass duplicator function could do the same (or a mass duplicator with given variations). There isn't much flexibility in StarCraft triggers. Just think about it: Blizzard defined the triggers, you can't make your "own", and the only thing you could do is add, edit, or remove them. Trying to make it into a "PROGRAMMING LANGUAGE", of all things, will make it HARDER. The only thing it will accomplish is make triggers look like complicated code to a person having no idea what he or she is looking at.


...if there aren't alternatives. You usually make the most of something if you're stuck with it. Outside of specific uses that the "general public" probably won't find necessary, there might be something.

evolipel has obviously made up his mind on the topic and will not be persuaded, so I won't even try to convert the mindless.

For the rest of you, I think that this is an awesome way to trigger and would definitely use it if the programming is not too complex. IF and ELSE functions will be hugely important to automatically set up chains of triggers. If for nothing else, I would likely use this in conjuction with a regular editor to make these chains quickly. I find it annoying to have to create seperate triggers for each combination of randomization. Thanks a lot for your work on such a helpful program.

I dunno, I find Starforged triggers a lot easier than StarEdit triggers, it's a lot quicker when trying to make gigantic systems. I type a lot faster than I click.

That's the thing. There is nothing here that say a modded editor can't do.
Variables = Deaths, scores, ore/gas, etc.

Instead of calling me mindless and "going after the crowd", how about you prove to me how this is going to be useful and/or practical?

...because so far, all everybody is doing is saying "LOL dis is goin to be great!!1 to bad taht nobody no's how to use dis, they're DUM!!!!11" The only person that doesn't agree is Deathknight. Thus, this makes you "part of the mindless".

The "IF functions"?? Hugely important? Nothing new, the last time I checked they were called "conditions" in SCXE and pretty much everywhere else. Now the "ELSE function" is duplicating the trigger with the conditions being the opposite of what it was for the IF. Too bad that now that you don't see the condition, you have no idea what it is exactly (remember, the action/condition format is the TRUE format of the .chk, not the artificial "programming" one). For example, if the true trigger with the "IF" thing is "Player x accumulates at least x minerals", which condition should be the ELSE one? "Player x accumulates at most x - 1 minerals"? What if "x" is 0?

I mean, if you like this go ahead, I'm just saying that it's not practical.

Its perfectly practical, and as you said the else would simply be player has accumulated at most x-1 minerals. If x=0 then don't allow use of the else function. You can think of hundreds of ways for a fool to screw something up. Try thinking or ways in which this wont actually work. People program in starforge triggers and find them easier, and this language is a simplification of starforge by chaining together triggers. How then would it possibly be slower? Unpractical for some, sure. If you don't like it, don't use it.

This is probably more trouble then its worth, I think the SCXE triggers are easier to debug than this would be. Its also pointless to learn the syntax and even if you did it would still take longer to do than even SF triggers. Sure SF uses text and all but it has the same structure as SCXE triggers and it doesnt need all the extra { } and whatever programming languages need. But hey if you want to make it go ahead, we'll just see how many people will actually use it.

variables would r0x but i don't understand how you would make them without modding o_O it'll probably use all the strings or something, no ?