Staredit Network

Well, you can easily use switches to count numbers (binary). What I was thinking of, is that you could use two deathcounts to replace hundreds, or even thousands of switches (depends where a deathcount becomes a EUD).

Here's the idea.

Have a binary countoff running, converting a variable number (deathcounts...) to another. Each deathcount, as it's fulfilled, would detect whether a switch is set or cleared. You would, as each binary deathcount remover removes score, or doesn't, a switch would be either set or cleared.

Examples:

Deathcount number: 343
256: yes 1
128: no 0
64: yes 1
32: no 0
16: yes 1
8: no 0
4: yes 1
2: yes 1
1: yes 1

So the switch set for 343 would be: 101010111

You could easily use the system for quite a few switches

SCMDraft can only add up to 999999999, so you can just use 30 switches for 2 deathcounts, unless you start copying some adders multiple times

well, this isn't really new but w/e. i'm wondering if anyone has actually used this before though.

I used this system for variables in the dead (but will be revived) SC:AOW. I reccomend that you make a text file describing what all the the numbers mean. Unlike switches, you can't name them.

Starforge doesn't allow you to name switches, and SCMDraft's switch namer doesn't work, so just do what I do (with switches too!), get a sheet of white paper, and manually take notes on all your info, just as good as the other system in my opinion.

ADDITION:
I guess that's what sucks about being a newbie in the mapping community, old systems disappear, I come up with seemingly new system, and someone mentions how old it is.

ADDITION:
I hate how editing doesn't work, the second paragraph was supposed to be on top...

ADDITION:
And where does the death counter start to overflow?

i think its 1 B something. ask kenoli if you want to.

The death counts should be unsigned, so you should be able to get up to 256^4-1 = 4294967295.

And just so you know, each death count is 32 bits, so that's how many switches you can get out of one.

This is a cool idea, one of the problems though is that you can't easily set or clear any arbitrary bit in the death count - you have to check if it was set or cleared to begin with.

Its not new either...

Not at all. We were looking into this a while ago because I needed more switches.


We were looking at this a long time ago and it is possible.. I forgot how and I'm not going to think it out again.


I have. I'm badass like that.

If you run out of switches then $10 says you could have designed your map in a better way that wouldn't have required as many.

I'm starting to think that maybe, if you needed a three way switch, perhaps instead of using a deathcount for each swtich, you could use 'trinary' (real word?) where you multiply be powers of 3, instead of powers of 2, Maybe even the same for 4 way, 5 way or even 6 way switches.

Either that, or I'm a squirrel climbing up a very short tree

And it wouldn't be very difficult to set or clear a given switch, you would detect whether or not it's set or cleared in a transfer to the other deathcount, and you would add or subtract accordingly.

I understand that they lack many of the useful features switches offer (toggle, randomize) But perhaps there is some use in this.

Being a noobie to the SEN community really screws up your thought of whether or not this has been done already.

err... its not going to work out the way you're thinking its gonna work out. the base number is irrelevent(although a higher base number will have fewer 'cutoffs'). using a cutoff method, you're going to always have two states, on / off (AKA you have the cutoff / you don't). by having a base of 3, you change nothing(except for having fewer total possible switches).

what you're looking for is a multi-state switch, AKA a death counter.

Binary switches are used to represent decimal numbers. How is it simpler to turn death counts into binary storage? It's more logical to just use a death count to store 343 than 101010111.

Actually he's completely right. What he's talking about is packing multiple many-state switches into one death counter.

Consider the case where you have two ternary (that's the word for base 3) switches in one death counter. Your detection code looks like the following:

Value at least 6-> high switch is 2, subtract 6
Value at least 3 -> high switch is 1, subtract 3
Value at most 2 -> high switch is 0
Value exactly 2 -> low switch is 2, subtract 2
Value exactly 1 -> low switch is 1, subtract 1
Value exactly 0 -> low switch is 0

Naturally you'd have to make sure that you don't execute the last trigger in each block of 3 if you already hit on one of the earlier ones in that group. The best way to do this would probably be...drumroll please...a switch.

In conclusion, everything people are saying in this thread is true and it is possible. Practical? Not a chance.

hows that multiplying by powers of 3? are you sure he didn't mean 1,3,9,27 insteado of 1,2,4,8?

It is. Maybe it wasn't obvious because I only showed it for 2 switches.

Here's the entire system for 4 switches in base 3 (conditions are on the left of the - and actions are on the right):

Clear hit
Value at least 54 - switch 4 is 2, subtract 54 and set hit
Value at least 27 - switch 4 is 1, subtract 27 and set hit
hit cleared - switch 4 is 0
Clear hit
Value at least 18 - switch 3 is 2, subtract 18 and set hit
Value at least 9 - switch 3 is 1, subtract 9 and set hit
hit cleared - switch 3 is 0
Clear hit
Value at least 6 - switch 2 is 2, subtract 6 and set hit
Value at least 3 - switch 2 is 1, subtract 3 and set hit
hit cleared - switch 2 is 0
Clear hit
Value exactly 2 - switch 1 is 2, subtract 2 and set hit
Value exactly 1 - switch 1 is 1, subtract 1 and set hit
hit cleared - switch 1 is 0

I think it would be accurate to say that you need (base + 1) triggers for each switch embedded in a single death count just for detection. And since there's not a great way to abstract out which death count you're using, you'd have to duplicate this logic for each death counter you wanted to turn into a set of switches. Not pretty.

Bitwise operators like and, or, not, xor would be great additions for that thing you mentioned in another topic about adding new conditions and actions for triggers.

i get the system perfectly(it took a minute or two, but i got it). what you're using is multiples of 3, using powers would be something entirely different. i was saying that using the powers wouldn't have the effect of what you're doing(whether he meant this type of system or not).

You'd lose that bet.

You were so desperate that even re-using death counters, making seperate locations with burrowed units, and all the switches didn't help?

No, it uses multiples of powers of the base (3). That's why you see 3, 9, and 27 in there. This is the fundamental notion behind base conversions. Think about it - 576 is 5*10^2 + 7*10^1 + 6*10^0.

The reason you don't usually see this is that we usually use binary, in which case there are no "multiples" of the powers because you can only have 1 and 0.

And those are definitely ones I implemented in my prototype =)

I used every switch and death counter, and in the most efficient way possible. And eveb in some ways that were essentially impossible. I would never waste units trying to store boolean variables though.

Heimdal:
Did you see my reply at http://www.staredit.net/index.php?showtopic=35410&st=20 ?

fair enough heimdal, i see your point, although, i don't entirely interpret things the same way. oh well!

Not new

But, nobody did add this yet:
It is not only possible to store one type of "switches" in a death counter, but you can just as well mix bases of 2, 3, 4, and whatever you want within a single counter. I have to admit, though, that it's tons of annoying maths to find the correct values in that case...

Usability... limited, indeed. I am using a derivate of it for a password system. But it's only a small step in the password creation porcess: All the information gets packed together tightly into some death counters and then the password is created out of these.

In-game usage is usually avoidable and way too chunky (especially when you want to set a value that could either be set or cleared).