Perhaps it is that you don't quite understand what a logic gate is or how it operates. "Basic" trigger logic is far from the truth, since triggers run off of conditions/actions, they're a glorified modus ponens. The definition of flowchart specifically employs the use of analyzing data as its main function. Where there is analyzing, there are logic gates because this is the only way for computers to analyze data.

It is interesting to note, because a flowchart is simply a visual representation of logic. It has an input (or several) and an output (or several). The input runs through the logic gate and then arrives at an output. Represented by 0 or 1 (or false and true, respectively). We can apply this directly to our trigger system with the following method:

Logic has several different conditionals used in logic gates. I shall list them:

AND: conjunction (& or ∧)
OR: disjunction (∨)
NOT: negation (~ or ¬)

Using negations, we can construct inverses:

NAND: inverse conjunction [¬(A ∧ B)]
NOR: inverse disjunction [¬(A ∨ B)]

Additionally, there are two others, making use of the exclusive use of the word or (one or the other, but not both).

XNOR: inverse exclusive disjunction (A ≡ B)
XOR: exclusive disjunction [¬(A ≡ B)]

---

Now if we design a trigger system based on these seven logic gates, we can obtain output values in complex fashions. This is useful in the area of Trigger-based AI, where complex decisions must be made (and can be made) with logic. Draw up several triggers for each. More than 2 inputs require much, much more triggers, so we should avoid that scenario. If we look at the logic outputs of AND we see this:

A B | A ∧ B
1 1 | 1 1 1
1 0 | 1 0 0
0 1 | 0 0 1
0 0 | 0 0 0

This means we need only four triggers to get full functionality for every function. We avoid redundancy by adding markers. Values for As and Bs will be set by death counters. Additional death counters will be used to mark which function is running the data. By using switches, we run through our conditions first, and once a flag is set (which means conditions have been met) these run through the functions for which the operator flags are set, churning out an output affected by actions, which then also uses switches to avoid confusion with other triggers. This is essentially a rudimentary processor. We may speed up the process by creating multiple processing units, essentially making a multi-core processing system.

Still pointless or unrelated?

Related, but still pointless.

Thank you Sacrieur, I understand what is a logic gate, because mathematical theory of integral circuits is the thing I'm professionally concerned. I am glad you understand all these. However, the task of emulating a microprocessor is meaningless. Why would one want to do it anyway? It's still a concept of a spherically symmetric horse traveling in a vacuum.

I don't understand what do you want to say? What do you want to discuss with people? What is the point of posting this? It sounds like: "Oh look, I'm so awesome I realized we can make a microprocessor on SC!" And the only answer that might be is "Oh cool!" Very fruitful discussion, eh?

Once again, I mean no offense. Excuse me if I'm too straightforward.
I am all up to doing little useful things, but against grotesque pointless discussions.

---

One little useful thing that follows from these math which I often use on practice is the application of the De Morgan law to reduce the number of triggers. Let's say I want to do something like (A ∨ B ∨ ... ∨ Z => Do something.). I can't implement this as a single trigger because we (unfortunately) don't have the disjunction connective in triggers. The straightforward implementation will need 26 triggers. We however do it with only 3 triggers:
T0 = (Always. => Preserve Trigger. Clear switch S.),
T1 = (¬A ∧ ¬B ∧ ... ∧ ¬Z => Preserve Trigger. Set switch S.),
T2 = (Switch S is clear. => Do something.).

If you then need to have multiple conditions of the form A ∨ B ∨ ... ∨ Z, they all share trigger T0 to reset switches. That way, the method is not really worse by triggers quantity than using trivia implementation whether there are only 2 disjuncts of more. But it's even better in the way that "Do something" isn't copied among triggers, and it's easy to change "Do something" on "Do something else" when you need it later (and sooner or later you will need).

Still have to be very care about A and ¬A, because there are cases when you can't simply construct ¬A from A (for instance "Bring at most N" doesn't always equivalent to ¬"Bring at least N+1"). It's really simple and I believe many people use this, but at least it's a useful thing.

---

P.S. http://www.staredit.net/?p=shoutbox&view=1322

---

P.P.S. More shoutbox reading reveals something.

http://www.staredit.net/?p=shoutbox&view=1323

The art of making triggers in SC consists in making a close to optimal number of triggers that won't lag the map for the aim one needs to achieve. And believe me, optimality doesn't include first (God forfend!) implementing a meta-microprocessor and second writing a meta-program. There is already a free embedded "processor" which is called SC Triggers Subsystem. Learn to use it well and you're the winner!

Also, triggers system is an event driven mechanism in contrary to control driven algorithms. But it's exactly what one needs when he makes an SC map!

Post has been edited 7 time(s), last time on May 7 2011, 11:00 am by Wormer.

Not too far unfortunately. We spent almost all of our time making Nightfall's (the RPG) core systems, and almost none of it actually making content so there isn't much to see (no more than a couple minutes worth of gameplay). It's all fragmented into a bunch of maps sporting different parts of it (most effective way for us to co-work on it). Your inquiry prompted me to talk with Lethal_Illusion and we decided we'd go back, blow off the dust, merge the different systems into one map and let people see it. We'll do this after exams are over, of course.

"Take it off [our] hands" as in, you just want to see it, or as in you'd like to potentially work with it?

Post has been edited 1 time(s), last time on May 7 2011, 10:04 pm by Kaias. Reason: wording

Cut the guy some slack. Don't you all remember when you discovered something cool with mapping and you wanted to let everyone else know about it? I think we've all been there. Just because you haven't thought of a use for an extra microprocessor doesn't mean he won't

The early posts in this thread were talking about making movies in the minimap, but said that the framerate was severely limited.

I found out earlier while trying to debug a bizarre JYD problem in my map, that actually when your units are under attack the minimap starts updating much more frequently, possibly as fast as 12 FPS.

I don't believe it until i see a test map.

Post has been edited 1 time(s), last time on Oct 26 2011, 10:44 pm by Tempz.