Wifi Conductor
-
Right. After the ignored Wifi blocker wall suggestion, here is a suggestion again for Wifi and portals.
First, Thanks to @minecraft-physics for sparking this idea.
Now it applies to PUMP and GPMP too.
Here is how it goes:
Name:SPCD (special conductor...can anyone come up with a better name?)
Description, colour and other stuff, anything. It doesn't affect this elements functioning.
Properties:It will be indestructible by heat and pressure. It will conduct normally, and if powered with PSCN, it will set it's heat to the Wifi/portal if there is one in a 1 pixel radius.
If tmp=1, then it will NOT conduct normally, and if powered with PSCN, it will shiift up the channels of Wifi/portals .
If tmp=2, it will not conduct normally and shift down the channels of Wifi/portals.
If tmp=3, it will set it tmp value as the temperature of the Wifi/portals in contact with it.
Uses: It can be used to change the channels of Wifi and portals after a certain extent of time. This allows for terraforming saves to distribute certain materials to specific places (Making them a whole lot more complex.). It can simplify timed electronics, and save Wifi channels.
Implementation: I haven't tried this out by myself, but this could work..
In update:
//heatconduct should be greater than 0.
{
int r,rx,ry;
for(rx=-1;rx<2;rx++){
for(ry=-1;ry<2;ry++)
{
if(!r)
continue;
r=pmap[y+ry][x+rx];
if((r&0xFF)==PT_SPRK && parts[r>>8].ctype==PT_PSCN)
{
if(((r&0xFF)==PT_WIFI || (r&0xFF)==PT_PRTO || (r&0xFF)==PT_PUMP || (r&0xFF)==PT_GPMP ||(r&0xFF)==PT_PRTI )&& parts[i].tmp==0 )
{
parts[r>>8].temp=parts[i].temp;
}
else if(((r&0xFF)==PT_WIFI || (r&0xFF)==PT_PRTO || (r&0xFF)==PT_PUMP || (r&0xFF)==PT_GPMP (r&0xFF)==PT_PRTI )&& parts[i].tmp==1)
{
parts[r>>8].temp += 5;
}
else if(((r&0xFF)==PT_WIFI || (r&0xFF)==PT_PRTO || (r&0xFF)==PT_PUMP || (r&0xFF)==PT_GPMP (r&0xFF)==PT_PRTI )&& parts[i].tmp==2 &&parts[i].tmp2==1)
{
parts[r>>8].temp-=5;
}
else if(((r&0xFF)==PT_WIFI || (r&0xFF)==PT_PRTO || (r&0xFF)==PT_PRTI )&& parts[i].tmp==3 )
{
parts[r>>8].temp=parts[i].tmp;
}
}
return 0;
}}}
\\NOT COMPLETE, still needs a few things here are there to match the properties.
Please suggest/approve/disapprove below.
I hope this suggestion gets implemented. I'm also thinking about adding this to my mod(under construction).
I would like this element to stay as an element to alter the temperature of otherwise non-conducting elements only. I do not intend this element to be a property setting element (which is easy to make, as a matter of fact.) -
-
Nice idea. But if it could be expanded to work on other things like aray or pump then it would be even better.
Also another possible addition, with a tmp of 3 then sparking it with pscn/nscn will increase/decrease the temp of touching particles using its life value to determin how much each spark. That would allow exact controll over the temp.
Examples:
Laser that needs time to warm up.
Wifi 'hacker'.
Thermostat controll.
Better controll over special element properties.
Another even more complex addition is its ctype being used to determin what property it changes. 0 (default) would be temp, 1 would be tmp, 2 would be ctype... or something like that. Then you would be able to make even more complex things like changing what something clones.you could change what cray makes allowing a constructor machine to create almost anything given the right instructions.
-
Should be powered...otherwise it can't be turned off. Ps...I could just make a powered property converter. (property converter is my element)
-
If there's going to be an element that changes wifi/portal channels, it should be based on channel number not temperature. This is in case more channels are added and the temperature gap between channels is changed. E.g. "increases channel by 1 when sparked with PSCN, changes channel number to the one stored in tmp of the wifi conductor when sparked with METL", or whatever.
I believe I've made my opinion on property setting elements clear previously. If something changes other particles, I'd rather see it specified in terms of the effect it has, not what properties it changes.
E.g. instead of "sets ctype":
- "if tmp==1, makes all adjacent CLNE/BCLN/PCLN/PBCN/CRAY start producing the element stored in ctype" and "if tmp==2, sets the wavelengths in passing photons to the value stored in ctype"
- or "if tmp==1: when sparked with PSCN, if there is an occupied adjacent PIPE particle, absorb whatever is in the PIPE and make all CLNE/BCLN/PCLN/PBCN/CRAY within a 2 pixel radius produce that element"
This is for the reasons I've mentioned in previous threads (http://tpt.io/.224643) - insulating saves from changes to the underlying code, and avoiding glitchy things. Being able to use the console to do things is fine, because then the user is taking deliberate action to fiddle with the internals of the game and should therefore not be surprised by crashes, unexpected results, or results that change between versions. But that shouldn't be possible just by running a save. The only things possible by using a property setting element in a save should be those that are also achievable by use of the GUI (excluding the console and PROP tools) and element interactions (though any little useful features which are meant to be there, like zero life photons lasting forever, or TRON flags, can also be made available). No molten stkm, no frozen sing, no crashing the game using soap.
The other problem with a property setting element is to make it reasonably easy to use. Whilst remembering all the arcane values to use to make the element do what you want may appeal to some people, I suspect that it will make the element rather frustrating and difficult to use for most people.
-
*facepalm*
1. Doing that would require making alot of property setting elements...so...don't do that.
2. you are right about script running elements being a bad idea...but you DON'T need to run a script to change a property, you simply need to give it the data stored in the converter
(forshadowing missunderstanding and denial)
Still don't believe me? Well...
BAM!
int Element_PRPC::update(UPDATE_FUNC_ARGS)
{
int r, rx, ry, rt;
for (rx=-1; rx<2; rx++)
for (ry=-1; ry<2; ry++)
if (BOUNDS_CHECK)
{
r = sim->photons[y+ry][x+rx];
if (!r)
r = pmap[y+ry][x+rx];
if (!r)
continue;
if((r&0xFF)!=PT_PRPC)
{
if(parts[i].ctype!=PT_NONE)parts[r>>8].ctype = parts[i].ctype;
parts[r>>8].tmp = parts[i].tmp;
if(parts[i].tmp2!=0)parts[r>>8].tmp2 = parts[i].tmp2;
parts[r>>8].life = parts[i].life;
parts[r>>8].temp = parts[i].temp;
}
}
return(0);
}
Element_PRPC::~Element_PRPC() {}NOTE: This can be broken down into indevidual elements for each property...but it does not run scripts and will not change coordinates, velocity, or pressure.
EDIT: Working on a powered version too
-
I guess you have not read (or have misunderstood) http://tpt.io/.224643 where "insulating saves from changes to the underlying code, and avoiding glitchy things" is explained in full. Giving a particle data stored in the converter is a problem with the method you propose, not just with running scripts.
Also, "would require making alot of property setting elements" - no, just one with a lot of possible tmp values, but configuring it to do what you want would be a bit of a pain unless some GUI is added for it. Though I think that problem exists for your proposed method too. -
Remember self-replicating machine? That would make that possible...and...if an element would break with the console...why would it matter if it got broken automatically? No, it won't crash, this is contact only not flood fill. In fact, what if I want to use it break an element for something like "diffuse the bomb!" or some such saves.
That is its entire purpose...it makes things, and it breaks things.
-
if an element would break with the console...why would it matter if it got broken automatically?
Because the fact that the console is being used is a warning sign, "here be dragons", don't expect things to necessarily work fine or break in the same way in future versions. If the console is not needed to make a save work, there's more of an expectation that things will continue to work, with no automatic breakage.
No, it won't crash
Setting SOAP properties can cause the game to crash, regardless of whether the SOAP particles affected are those in contact with a certain particle, or if the effect is flood fill.
