After testing the PHOT wavelength > charged LITH features, I've conlcuded that discerning the charge would cease to be very useful after LITH receives a charge of 100. PHOT, upon reflecting off LITH(1) for example, will force its wavelength to be PHOT(0x0000001F)/(31). Upon reflecting off LITH(4), PHOT(62); LITH(8), PHOT(124), and so on.

Until LITH reaches a charge of 100, the wavelength of reflected PHOT will change to 0x3E000000. Any charge beyond this leaves PHOT at the same wavelength. I thought this would be useful for measuring the Ctype of LITH (using LSNS with 3 tmp > FILT[0x1...] allows LITH a charge of far greater than 100 -- will demonstrate in a future save), but PHOT will only read charge up to 5 whole bits. Not very exciting, as PHOT wavelength can be changed in many different circumstances.

The reason why I reckoned LITH would be any different was because it looked like PHOT may have kept the Ctype of LITH, regardless of charge, but it instead falls back on its previous mechanics. Ultimately, this feature may render itself mostly useless, because all this tells us is whether LITH has changed its charge -- not what the charge actually is, precisely. Therefore, I think the only way to measure charge effectively would be by using subframe, and counting how many times charged LITH discharges onto NSCN -- which was already possible prior to the beta.

I hope this changes.

@LBPHacker, Yes, I revised my post the moment I sent it. It's not once every 5, like I thought -- but instead once every 4. 

Edit: And to be honest, I was really hoping a new mode would be added to FILT, LITH or PHOT that lets it read the Ctype, regardless of charge.

@jacob1 (View Post)

suggestion: add frame skip so laggy projects simulate at a better speed

just to let you know, russian wiki updated by me, added LITH to electronics. Also some minor changes

@-AverageHuman- (View Post)

Frameskip won't help. The source of lag in TPT is almost entirely with actually simulating the save, not rendering it to the screen. In some cases the rendering mode can cause significant lag, e.g. when rendering a save with most of the screen filled with fire while in Fire Display. In that case frameskip may provide some benefit, but the fact remains that it will be of only limited benefit even in the best case, and no benefit at all most of the time. It could still be interesting though to add an option to only render a new frame every n simulation steps, where n could be some selection from 1 to 4 or something, so if you really want all the speed and don't care about FPS you could set it to render only every 4th simulation step. Still, just setting it to Nothing Display will generally work just as well.

Also, that option already exists, tpt.setdrawcap.

jacob, is there going to be multiplayer avalable on android? 

dunno if this has already been reported, but in 97.0 when i exit the powder toy (without closing it entirely) the screen constantly flashes until i reenter the powder toy or close it out entirely, ive tried this on several computers with different OSs and it happens on windows 10 and 8.1 from what ive tried