Official Game Feedback

  • Schicko
    22nd Mar 2016 Member 0 Permalink

    @jacob1 (View Post)

     Awesome. Another question: is it intended for cray (sprk) activated by inwr to not recognise sprk(anyconductor) as a conductor? With how it is now, I think it is less intuitive and kind of doesn't make sense with some electronics configurations, eg.:

     

     

    With the above save, the first cray has tmp 2 so sparks the 2nd inwr and also the metl. However, because the 2nd inwr/cray pair doesn't recognise the sprk (firstmetl) as a metl that is simply sparked, it sparks the 2nd metl, even though the 2nd cray only has tmp 1. This might cause stray spark problems in saves which heavily uses inwr/cray (sprk) pairs, so it might be better to make it so that the cray recognises sprk as a conductor and ignores it?

    Edited once by Schicko. Last: 22nd Mar 2016
  • Sandwichlizard
    22nd Mar 2016 Member 0 Permalink

    it could be a good thing.  you could make it spark a different spot by sparking the initial spot.  I think you may be trying to remove a potential feature.  what problem exactly is this causing?  though your investigativeness is awesome!

  • jacob2
    22nd Mar 2016 Member 0 Permalink
    There is some kind of feature related to INWR sparking CRAY. I can't remember the details of how it works / why, but I think it was some kind of compromise. I will investigate more when I get home.

    This still might be unintentional, but I might leave it in anyway if it is useful.
  • Schicko
    22nd Mar 2016 Member 0 Permalink

    Ok so here is an example where I tried to use a lot of inwr/cray(spark) to reduce pixel count and make the sim run faster without realising that the cray thing occurs:

     

     

    So when I tested it, I sparked the pink pscn which activates the blue inwr mechanism (intended) which causes problems with the green decoed stuff due to the cray thing (not intended). Also sparking the red stuff will spark the yellow stuff (intended) which will spark the cyan stuff (not intended). There might be more issues with how I made it, but that's what I have noticed so far. If the cray thing doesn't happen though, I think the sim would work as how I planned it to.

     

    I suppose I could just use actual wires instead of using so much inwr/cray transmitters and this will also fix it.

     

    If this does get changed though, I suppose it might also be a good idea to use some property for cray(sprk) paired with inwr which can be set to make it so that you could either make it behave like how it does now or make it recognise spark as a conductor and skip it depending on the property value.

     

    As an alternative for the potential feature if the cray gets changed, I think you could just use multiple inwr/cray(sprk) pairs with different tmps and tmp2s on the crays to spark different conductors in rows/columns. Might be a bit bigger though?

    Edited 7 times by Schicko. Last: 23rd Mar 2016
  • jacob1
    24th Mar 2016 Developer 1 Permalink
    @Schicko (View Post)
    I think you are right that it is a bug. CRAY(SPRK) has a special mode when sparked by INWR where it will actually create sparks, not just delete everything. (You probably already knew this since you were using the feature). Normally CRAY will only attempt a create when there isn't a particle in a location (which should succeed). When sparked by INWR though, it will always attempt to create a particle (apparently regardless of if it is creating spark? I didn't know that). If the particle creation fails, it doesn't decrease from the amount it has to create.

    It was intended to only create one SPRK in the first valid location. But I guess since existing sparks aren't valid, it will move on ...

    Maybe I could add it to my entirely unfinished electronics-compat branch, which intends to fix bugs like this without breaking older saves.

    Although, I guess it could be a feature, that would be a lot less work to code :P
  • Schicko
    24th Mar 2016 Member 0 Permalink

    That's it, I think your interpretation makes sense. So as you said, cray/inwr pairs skip spaces if there are already particles in the way (like how cray/inst pairs work), which causes problems with cray (spark)/inwr transmitters as they usually spark conductors in the same row/column as the plane of the transmitter. But because sprk (anyconductor) isn't a conductor, it is skipped instead and the next conductor is sparked.

     

    Like I said though, if you do decided to change the code, it might be a good idea to have the "fix" as a property for the cray (maybe life, as you said that it isn't used anyways and because new sprk always starts at life of 4 anyways and dlay can just be used to make it "higher" if needed) to toggle its modus operandi so that compatibility with older saves is maintained, instead of completely scrapping the current one.

     

    (Although tbh, I don't think anyone is using the current "feature" in the way that Sandwichlizard suggests as it seems to me to be an impractical way to spark other conductors. It is probably way easier to just use multiple transmitters (or even wifi and portals if the user is not averse to using them) to select which conductors need to be sparked.)

    ---

    Edit: On another note, is loop edge mode supposed to only work for moving liquids and gases? As in, how come pistons can't push things "through" the loop edge, aray can't make brays that go through it, crays can't make stuff past it and drays can't copy through it?

    ----

    Edit2: Just a thought which I will probably be shot down for: Now that we have tmp2 for cray which can be used to skip spaces with any conductor, having the special inwr/cray and inst/cray thing which allows them to skip spaces if there are things blocking the way is now kinda pointless. Maybe we could instead use inwr/cray pair such that cray won't generate particles diagonally (except sprk maybe?), which would be more consistent with how inwr/dray pairs work (these don't copy diagonally) and be more useful in electronics as pretty much all conductors do the same thing anyways now. Taking the idea further, perhaps all interactions from inwr pairings with all ray type particles (aray, cray, dray) could be made so that they only activate in horizontal and vertical planes, and not diagonally. It doesn't even have to be inwr, it could be any other conductor. Taking it even further, maybe it could be made such that another conductor can cause ray types to only activate in diagonals.

     

    Before anyone says this will break saves, I'll just say again that since tmp2 for cray skips anyways, users could just alter their electronics such that the current conductors they use are replaced and their tmp2s set, just like how when the layered pstn thing is fixed, users just deleted the excess pstns and changed the temp of the ones they need.

     

    Doing this would be beneficial as it could make electronics sims smaller by allowing compact ray particle arrangement and still be able to activate the required particles. This would also increase fps in more complex electronics sims dues to decreased pixel count. Eg., 

     

    1960001View Save 1960001

     

    Edit3: Sandwichlizard is right XD. Disregard edit2.

    Edited 6 times by Schicko. Last: 24th Mar 2016
  • Sandwichlizard
    24th Mar 2016 Member 0 Permalink

    I see your point.  however.

     

    Edit 2:

    the INST-CRAY interaction is differint from the skip aciton.  with inst it will fill every empty space up to the tmp value.  So if you say have a dashed line of DMND with 10 open spaces INST-CRAY with ctype INST and tmp 10 will fill all ten empty spaces with inst regardless of how far away they are if tmp2 is 0.  that is how some of my printers change elements.  if you remove that you WILL break saves as that wont happen without the INST-CRAY skip feature. 

     

     

    infact the 2 features work together.  you can use INST-CRAY with tmp2 to skip first then fill all the empty holes.  it works.  you are feature trimming.  example  id:1960072

     

    1960072View Save 1960072

     

    Edited 4 times by Sandwichlizard. Last: 24th Mar 2016
  • Schicko
    24th Mar 2016 Member 0 Permalink

    @Sandwichlizard (View Post)

    Whoops you're right, didn't think of that. I think it still might be a good idea to change the ray-particle interactions of one of the other conductors (tung, ttn, bmtl, metl or iron, etc.) to only horizontal/vertical or diagonal since they all pretty much do the same thing in terms of sprk conductivity and some are practically redundant anyways in that regard. The horizontal/vertical-only activation of dray with inwr is useful, so it might be good to have with aray and cray too?

  • Sandwichlizard
    24th Mar 2016 Member 1 Permalink

    I agree.  I keep advocating BMTL as an erase all function for CRAY (it would erase filt and dmnd)  IRON would be agood choice because I doubt many saves count on sparking CRAY with IRON.

    Edited once by Sandwichlizard. Last: 24th Mar 2016
  • DanielGalrito
    24th Mar 2016 Member 0 Permalink

    I don't know if I should report it here, but after I updated i saw in the changelog that stickman now has terminal velocity in loop mode and tried it, put a stkm in loop mode and then the game froze and my antivirus said that Powder.exe was dangerous, then i clicked to protect and powder.exe was removed.

    And now I'm reinstalling it :P

    Edited once by DanielGalrito. Last: 24th Mar 2016
Locked by jacob1: Old / not enough space in first post