The Powder Toy

GreninjaWorks

hello, i needed some help for my next creation, i am still a tech novice but can LDTC sprk a conductor becuase of filt ctype? like if i have set up a FILT particle of ctype of 512, can LDTC of ctype 512 produce a sprk? i have tried this but no help. i know the AND logic but this can make my creation smaller.

Thanks in advance.

LBPHacker

I was going to say it can't, but then I wanted to reference the relevant piece of code for the record and found out that it actually *should* be able to and *was* supposed to be able to, it's just that there's a bug in there that makes it unable to.

There's this line of code that decides whether the LDTC sees a particle matching its ctype; but it's incorrect, it should actually be (along the lines of)

bool matchesCtype = ctype == TYP(rr) && (!ctypeExtra || ctypeExtra == parts[ID(rr)].ctype);

I'm going to issue a PR soon to fix that. So no, LDTC can't currently do that, but it should definitely be able to do that in the next snapshot and in the next stable version.

If it wasn't bugged, you could set the ctype of LDTC to [type to detect] + [additional ctype to check for] * [element number limit] (the latter is 512 as of v94). To get LDTC to detect a FILT with a ctype of 512, you'd have to use 125 + 512 * 512 = 262269.

GreninjaWorks

Hmm, so that thing was supposed to work for LDTC? and i tested the same for dtec but isnt working, hoping some fix will be there. And i turned my decision that the thing will be published after an update. And now i knew TPT was written in simple type C++ syntax...

Edit- +if LDTC could do that, then a new era (era?) in electronics would be there, electronics will be more smaller and LDTC will become more popular and useful.

jacob1

The code all looks intentional to me. LDTC is a type detector, not a ctype detector. It's not meant to have the ability to check for ctype=512 or anything like that.

The line of code LBPHacker linked is for GoL, which is the only element that uses ctype to determine the shown type. All GoL elements are actually PT_LIFE with a different ctype value. It specifically looks for PT_LIFE as the type before doing the type check because that's the only element that needs it.

Anyway, we could add a ctype detector but I'm not sure how useful it would be.

GreninjaWorks

maybe useful, for example like LDTC if we could set the range of detectiona and length of detection like LDTC, +some modes this maybe useful for advanced technologies (ex- registers and sorters/checking upon log). I have an idea below-

Name- CDTC/CYTC (ctype detector)

Description- Detects ctype of a particular particle and sprks in opposite direction

Modes-

tmp determines range (like ldtc)

life determines length to skip (like ldtc)

Tmp2-

Tmp2 = 1 = Inversion- every ctype except marked can trigger

Tmp2 = 2 = Stop detecting after one specified ctype has been found

Tmp2 = ??? upcoming :)

Cracker1000

@GreninjaWorks (View Post)

Actually you can use dtec to copy the filt wavelength and then transfer it using bray another dtec and end.

It isn't exactly same though.

Matera_the_Mad

If there were a ctype detector, we would find uses for it ;)

GreninjaWorks

Cracker1000:

@GreninjaWorks (View Post)

Actually you can use dtec to copy the filt wavelength and then transfer it using bray another dtec and end.

It isn't exactly same though.

i already know it :) but CDTC could be useful, for a little example we can seperate 'lava-ice' from other mixtures?

Can LDTC sprk because of a filt ctype?