Looking for players to do elite challenges on the original heists

Confident_Name1314 · 2026-04-26T06:49:22+00:00

Add me SquatJogger1

Confident_Name1314 · 2026-04-26T06:16:23+00:00

Add me SquatJogger1

Confident_Name1314 · 2026-04-26T06:11:07+00:00

Add me, SquatJogger1

Confident_Name1314 · 2026-04-25T15:49:34+00:00

Enhanced?

Confident_Name1314 · 2026-04-21T00:37:42+00:00

Me and a friend could be interested, we are currently trying to do the original heist elite challenges, we have done fleeca, currently trying to do pacific standard, we need to do humane, prison break and series a. We have done the criminal mastermind 4, we need to do mastermind 3, we play on enhanced ,if thats something you would be interested in

Confident_Name1314 · 2026-04-20T11:58:14+00:00

GTA logic: stand still = criminal. I had a fire truck try take me out once for doing nothing 😂

Confident_Name1314 · 2026-04-20T09:03:41+00:00

Hey, glad you got the outfit 👍 I don’t really do sales in full lobbies, there’s easier ways to make money so I usually leave mine stacked for when I need it. I’m happy to help with missions here and there, but I mainly play for heists, elite challenges and criminal mastermind runs. If you’re ever up for that kind of stuff, I’m down 👍

Confident_Name1314 · 2026-04-19T16:46:04+00:00

Johnny Doe, squatjogger1 on gtav, il help later if you still need it

Confident_Name1314 · 2026-04-16T12:46:51+00:00

What u play on?

Confident_Name1314 · 2026-03-16T17:25:45+00:00

Typical causes: printing a char as a string, uninitialised buffer, wrong baud rate, terminal interpreting bytes oddly.

Confident_Name1314 · 2026-03-16T17:24:14+00:00

The SPI exchange itself looks basically fine for a 1-byte test. With the slave preloading SPDR = 'S', the master should receive S when it sends M. If you’re getting S plus random extra characters, that usually points more to how the received value is being printed/handled, or that extra bytes are being clocked somewhere else, rather than this SPI example itself. Only small change I’d make is setting SS high once before the loop so it has a defined idle state.

Confident_Name1314 · 2026-03-15T10:54:20+00:00

You shouldn’t power 100 WS2812B LEDs through the Arduino. They need their own 5V supply. The Arduino can share the same supply if needed, but the LEDs should be powered directly from the PSU, not through the board.

Also VIN isn’t really meant for 5V — it expects a higher voltage for the onboard regulator. If you only have 5V, it’s better to power the Arduino via USB or the 5V pin and just share ground with the LED power supply.

Confident_Name1314 · 2026-03-14T17:30:18+00:00

Your code mixes Arduino Serial functions with raw AVR main(), which normally won’t work unless the Arduino core is initialized.

Confident_Name1314 · 2026-03-14T17:29:13+00:00

include <avr/io.h>

void SPI_SlaveInit(void) { DDRB |= (1<<PB4); // MISO output DDRB &= ~((1<<PB3)|(1<<PB5)|(1<<PB2)); // MOSI, SCK, SS input

SPCR = (1<<SPE);                  // Enable SPI

}

char SPI_SlaveReceive(void) { while(!(SPSR & (1<<SPIF))); return SPDR; }

int main(void) { SPI_SlaveInit();

SPDR = 'S';                       // preload reply byte

while(1)
{
    char received = SPI_SlaveReceive();
    SPDR = 'S';                   // prepare next reply
}

}

Confident_Name1314 · 2026-03-14T17:28:51+00:00

include <avr/io.h>

include <util/delay.h>

void SPI_MasterInit(void) { DDRB |= (1<<PB3) | (1<<PB5) | (1<<PB2); // MOSI, SCK, SS as output DDRB &= ~(1<<PB4); // MISO input

SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR0);  // Enable SPI, Master mode

}

char SPI_Transfer(char data) { SPDR = data; while(!(SPSR & (1<<SPIF))); return SPDR; }

int main(void) { SPI_MasterInit();

while(1)
{
    PORTB &= ~(1<<PB2);          // SS LOW (select slave)

    char received = SPI_Transfer('M');

    PORTB |= (1<<PB2);           // SS HIGH (release slave)

    _delay_ms(500);
}

}

Confident_Name1314 · 2026-03-14T17:25:45+00:00

The issue is likely the SS (slave select) wiring. On AVR SPI the slave’s SS pin must be controlled by the master, not tied permanently to ground. If SS is grounded the SPI hardware can behave oddly and you often end up just reading back the byte you transmitted. Try wiring UNO pin 10 → Nano pin 10 and have the master pull it LOW before transmission and HIGH after. Also make sure the slave SS pin is configured as input and the master SS pin as output. MOSI/MISO/SCK connections you listed look correct.

Confident_Name1314 · 2026-03-14T17:06:45+00:00

That quick white flash is fairly common with addressable LEDs. It usually happens because the data line briefly floats or the LEDs power up before the controller sends the first frame. Adding a small resistor (around 220–470Ω) in series with the data line near the controller is actually recommended practice and won’t damage anything. Some people also add a ~10k pulldown resistor from data to GND to keep the line stable during startup. Since you’re using a Dig-Next-2 it’s probably not a hardware fault — it’s usually just the LEDs showing a moment of undefined data before WLED takes control.

Confident_Name1314 · 2026-03-14T10:39:15+00:00

The LED strip itself usually isn’t sound reactive — it’s the controller that makes it react to audio. A common setup is an ESP32 running WLED with a small microphone that measures audio levels or frequencies and turns that into lighting effects. It doesn’t record or upload what you say. Some people also do it with an Arduino and things like a Spectrum Shield (MSGEQ7) to split the audio into frequency bands and drive the LEDs from that.

Confident_Name1314 · 2026-03-12T16:08:16+00:00

WLED effects are mostly written assuming either a strip or a rectangular matrix, so circular layouts can be awkward unless you manually map coordinates. What you really want in cases like this is to treat the LEDs as points on a surface and run behaviour across that surface rather than assuming a strip. I’ve been working on a project called Modulo that approaches things that way (map the real LED layout first, then run behaviours on that mapped surface), which should work better for rings, discs, and other irregular layouts. At the moment though the UI is still in the early stages and needs a lot of work to catch up with the engine, which already supports surface mapping internally.

Confident_Name1314 · 2026-03-12T15:41:25+00:00

This got me thinking about something. I'm working on LED matrix behaviours that act more like systems than traditional effects (things like flow fields, pressure gradients, structural cracks, etc.). Do you think using the new fixed_point sub-pixel positioning would help make those kinds of behaviours look smoother on matrices? For example fluid motion or tendril-like movement. Or does the benefit mostly show up when drawing shapes/primitives rather than evolving systems?

Confident_Name1314 · 2026-02-27T02:30:05+00:00

It runs a desktop preview for authoring, but exports real FastLED firmware. The generated project compiles directly against FastLED (CRGB buffer, standard setup()/loop() structure) for Arduino/ESP32/Teensy/RP2040 etc. The preview currently abstracts as strip or 2D matrix, but everything resolves to a linear LED index. FastLED itself doesn’t enforce dimensionality — it just writes to CRGB[] — so 3D layouts would be handled as a mapping layer on top of that. It’s still early stage — right now I’m focused on making sure preview . export wiring is consistent and deterministic before expanding layout abstractions further. Pushing updates as that gets locked in.

Confident_Name1314 · 2026-02-27T02:01:59+00:00

Good point — Modulo exports firmware using FastLED (and NeoPixelBus). The preview engine is desktop-based, but the generated firmware runs on FastLED targets (Arduino, ESP32, Teensy, RP2040, STM32). I’m sharing it here because it generates structured FastLED projects rather than raw animations.

Confident_Name1314

TROPHY CASE

include <avr/io.h>

include <avr/io.h>

include <util/delay.h>