When you make something easier, you can do things faster and better. Example: You make a game with Normal Difficuly, and Hard Difficulty. People complain that the Difficulties are too hard. You go back in and *ADD* [KEY WORD: ADD] Easy Difficulty. They praise you for it!
Now since you added Easy difficulty, players now have 3 difficulties to choose from, instead of just 2.
PS: 3 Better than 2! xD
LMAO! How can you TAKE-OUT the fun of TPT if all we did was PUT-IN something new? Please let me know when you get that answer! LMAO! *Crying from laughing/Not!* Too funny man, Too funny!....
LMAO! How can you TAKE-OUT the fun of TPT if all we did was PUT-IN something new? Please let me know when you get that answer! LMAO! *Crying from laughing/Not!* Too funny man, Too funny!....
Easy. Add in something that does what a hell of a lot of saves already do. The fun is in making things that do this, not by placing a big blue block on the screen and going "Done! Where's my front page slot?" It doesn't make anything "easier." What it does is ruin things that people actually spent time on to accomplish a goal by accomplishing the same goal with little to no effort.
How does it take fun away to add new electronic elements? Making electronics out of just METL and SPRK is nearly impossible. We absolutely need WIFI (or at least INST or ARAY) to make most games/computers that are in TPT now.
Also, since everyone knows how to make colored PHOT the old way, the new FILT doesn't take any fun out of it; there isn't any fun coloring lasers anymore anyway.
@OmegaSupreme(View Post) @Jackeea(View Post) @OmegaSupreme(View Post) What's the damn limit then? If you want to make things easier, then you must accept the consequences. Do you know how many crappy uploads made by n00bs that exploit these so-called "easy" solutions? Also, where do we stop? If we make those elements what's to stop us from making an element that makes other elements have almost all the same hidden values that it has? What's stopping us then from including a program that can make new elements for TPT?
Anyway, a heater unit using LIFE can take up as little as four pixels, a cooler can take up as little as one pixel.
Another issue is this: many of those values can be rather volatile. Improper manipulation of it can crash TPT. For example, earlier, ctype manipulation of soap can could crash the game. And how does TPT process multiple stat changes of the same stat of the same substance? What if, say one element next to a pixel of DMND is changing it's ctype to BOMB while another element is trying to the change the same DMND's ctype into LIFE?
Also:
Setting up those elements REQUIRES A LOT of console use
In fact, a good save using those elements would require multiple value changes all of which would require either particle ID-based localization or coordinate-based localization.
And what happens if two ctype-changers try to change each others ctypes simultaneously.
WIFI opened no possibilities, as simple ARAY-based unit can easily replace wifi.
@OmegaSupreme(View Post) *scoffs* I doubt that Simon will add stuff that was suggested countless times. If the element suggestions subforum is open, then I'd post my entire "Do not suggest and Why" thread here.
@code1949(View Post) "Do you know how many crappy uploads [there are] that are made by n00bs that exploit these 'easy' solutions?" The reason those get popular is that they show a new, easier use for an element. Also, saves like that are usually based on a more complicated version that has already been made. The only fun part is making the first version of something that hasn't been done before, so there's no fun that can be taken out of those ideas anyway. If you want fun, then just try to make a save that doesn't use any complicated elements. It doesn't matter if no one likes it, you don't have to get to the front page to have fun.
"A heater unit using LIFE can take up as little as four pixels..." Yes, but it can only works at 50% efficiency, only produces a limited amount of heat per frame, and can only heat to 8600 degrees.
"A cooler can take up as little as one pixel." GOL cools fairly slowly.
"Improper manipulation of [values] can crash TPT." Then make the elements incompatible with glitch-causing elements.
"What if [multiple elements are] trying to change the same DMND's ctype?" Interactions between elements are most likely computed one after another, not at the same time, so the DMND would probably pseudorandomly get one ctype based on which elment the ctype was changed to last.
"And what happens if two ctype-changers try to change each others ctypes simultaneously" Answered in the two previous questions; you could make it incompatible with itself, and even if you don't, it won't cause a glitch.
"WIFI opened no possibilites" Seriously? My connect four used 168 WIFI channels (67 were actually PRT acting as WIFI) and over 1,500 pieces of WIFI. Try doing that with ARAY without crossing any wires or slowing it down.
"Setting up those elements requries a lot of console use" Not if you use the tools I suggested to modify them. Plus, you could make a lua script to help you. Besides, people are willing to put a lot of work into setting elements one-by-one; read the answer directly above this one. Requiring work isn't really a reason to prevent an element to be implemented anyway.