wifi glitch

  • jansuki
    11th February Member 1 Permalink

    if wifi's channel is 1, tmp is 1, if you pressurize it, it becomes brmt tmp=1, when melted it becomes molten bmtl tmp=1,  molten bmtl tmp=1 when cooled becomes bmtl tmp=1, which rusts

  • MachineMan
    12th February Member 0 Permalink

    This isn't a glitch; there's no way to change the tmp of BRMT or LAVA(BRMT) without the console or propety tool.

  • jansuki
    12th February Member 0 Permalink

    and guess what I DIDNT USE THE CONSOLE

  • jacob1
    14th February Developer 0 Permalink
    Yeah this sounds like some old glitches where properties aren't properly cleared on type change. I don't think it's intended.
  • Gavin102938
    1st April Member 0 Permalink

    all roads lead to brmt

  • linfuciuscont
    1st April Member 0 Permalink

    If properties were always cleared on type change, we wouldn't be able to make SNOW(SING) explode by increasing its tmp before warming it up.

    Edited once by linfuciuscont. Last: 1st April
  • jacob1
    1st April Developer 0 Permalink
    @linfuciuscont (View Post)
    Yeah that's why every single reaction needs care to make sure we're doing it correctly. Either preserving or not preserving properties.

    In this case, WIFI's .tmp is only used by WIFI to control channel, and has no use for BRMT. It shouldn't be carried over.
    We handle this in the code like:
    part_change_type -> preserve all properties
    create_part -> recreate particle overtop existing particle, resetting all properties