Luveelvoom's scripts and ideas

[LuveelVoom]

hello welcome to luveelscript thread
!! warning: vibecoding ahead !! the scripts will probably be buggy !! you have been warned !!
my overall goal with this is to make ca search programs more accessible and also expand life-specific searching programs to int rules

PLEASE PLEASE PLEASE TEST FOR BUGS AND GIVE FEEDBACK. in particular, help with making the guides not sucky and AI slop would be amazing.

LUVEEL PLEASE FIX THE TERRIBLE AI GUIS AND GUIDES PLEASE DO IT AAAA

here is the github:
https://github.com/LuveelVoom?tab=repositories

the scripts!!!!

Colors:
Full release, fairly well made and easy to use
Beta, functional but has serious flaws, particularly in guides (which are ending up a big problem given how in depth the programs are. I may need community help on them.)
Alpha, exists but is complete garbage
Not yet started, planned for the future

ntCatForce+: ntCatForce fork which is actually usable, featuring: the ability to change the rule in the infiles, multithreading, reasonable qol changes, and uhh yeah thats basically it there's a few other things

drift: dr2 port to all INT rules with additional features to make it faster and easier to use

LLS-gui: GUI for LLS inspired by JLS, currently sucks beyond belief. In fact it doesn't even deserve alpha in my opinion...

LLSSS Partial Cutter: Fun HTML element for producing LLSSS .in files from partials. The guide currently lies to the user about how LLSSS works, which is bad, and I do not want to release it because it would make me and amling very unhappy if the guide lied to people about how LLSSS works. Beta testing will open soon (tm) whenever I rewrite the guide

APGmanager: Automatic Performance Generalization Manager, which will let you queue searches and distribute them across threads; images of my doodles on it shown a few posts below

qfind performance fork: colloquially known as "qlaudefind", it's qfind but featuring a speedup of about 30% and also BASICALLY ZERO MEMORY USAGE (no actually it uses like a gigabyte of ram at width 14 it's actually insane). I put this in "full release" because Sokwe is actively planning to implement modified versions of the features into base qfind, so this will be obsoleted in the near (weeks to months i guess) future, so it's not really relevant if the guide is good (which it sure isn't).

Crawler search script: It's a crawler search script, it's in the misc life stuff repository


Attached are ntCatForce+ and qlaudefind. ntCatForce+ comes with a terrible "infile builder" gui which is extremely WIP i would recommend not using it. Edit: These are not the most recent builds, please use the github instead.

Have fun (or more realistically have lots of bugs and problems)

current development plan:
please luveel get around to fixing the partial cutter guide so you can release it please please please
Put this shit on github for the love of gol [DONE]
Make ntCatForce+ smoother and add more qol features and bugfix
Quickly summon up a crawler searching script, this should take like 10 minutes [DONE]
Start work on APGmanager
Look into INT drifter search (assuming speedydelete hasn't beaten me to it) [DONE]

[NNlk05]

I wrote a Python module for that a while back; it works like this:
C1.py

Code: Select all

from catastdin import *

def gen_soup():
    soup = Soup()
    sha = get_sha(256)
    for _ in range(16):
        soup += (sha[16])
    return soup

main(gen_soup)

1x256.py

Code: Select all

from catastdin import *

def gen_soup():
    soup = Soup()
    sha = get_sha(256)
    soup += (sha[256])
    return soup

main(gen_soup)

D2_2.py

Code: Select all

from catastdin import *

def gen_soup():
    soup = Soup()
    sha = get_sha(256)
    
    for _ in range(16):
        row = sha[16]
        row = row.mirror_x(0) # Mirrors the row across y = 0
        soup += row
    
    return soup

main(gen_soup)

Usage:

Code: Select all

python3 -m catastdin C1
python3 -m catastdin 1x256
python3 -m catastdin D2_2

The code is unfortunately not ready for publication yet.

[LuveelVoom]

Does this allow including initial on cells?

[NNlk05]

Does this allow including initial on cells?

Yes

Code: Select all

from catastdin import *

def gen_soup():
    soup = Soup()
    sha = get_sha(256)
    bhep = Cells("bo$3o$ob2o!")
    soup.place(bhep, 0, 0)
    soup. set_cursor(0, 3)
    for _ in range(16):
        soup += (sha[16])
        
    return soup

main(gen_soup)

[LuveelVoom]

Does this allow including initial on cells?

Yes

Code: Select all

from catastdin import *

def gen_soup():
    soup = Soup()
    sha = get_sha(256)
    bhep = Cells("bo$3o$ob2o!")
    soup.place(bhep, 0, 0)
    soup. set_cursor(0, 3)
    for _ in range(16):
        soup += (sha[16])
        
    return soup

main(gen_soup)

Hmm, very interesting. I wonder if there's a way to make a script that converts an input RLE file into this.

[LuveelVoom]

This is my amazing idea that would take several years of dev time and an absurd amount of testing and messing around. It might be useful though I guess

A fully integrated pattern editor.

Some examples of what I think it could do:

You have complex operational controls (as an example, you can perform a kinetic symmetry movement and then send the new pattern off to a subspace where the patterns are kept separate, like a "use later" area; then, you can place location points for each of the patterns to be placed and it will fit them together based on where they are specified to interact), this makes editing patterns extremely easy and fluid once you learn how to use the keybinds (to do that, there could be some sort of practice mode where you are given random puzzles and have to quickly solve them)

You have the ability to call search programs and scripts easily as well as with specified orders. Two examples:

You could have a script that lets you: open a GUI, draw in the specified initial and final positions of objects, call EPE to find the rulespace where that works, select random non-explosive rule in the rulespace and quickly look at them and skip or keep them, then call VLS to scan the low-period ships and find easy small solutions, then call another program to scan natural common ships and collide them with each other and still lifes and output that as a pattern, then call apgsearch to run for a bit;

You could scan the positions of two branches of a crawler and determine where to connect it to have the correct parity and output and place it there...

There could even be some sort of sharing system. An example of this is an idea I had on the discord a long time ago:

have just had an awesome idea
website called "[username]'s ruliad" and whoever has the website
it like
you have these nodes which each correspond to a rule type
and they expand into subtypes
and each subtype has rules under it that the person with the ruliad has found and classfied
and those rules have pattern collections and descriptions under them
and, like, you can position rules and stuff and it would be really cool i would make it if i could make websites
and you can have links to like forum posts and catalogue and it would be soooo useful for organizing and also you could just put a link to yours in your forum signature instead of shit like this
for example.
you are looking at LuveelVoom's Ruliad
you go to node which is catalytic rules. big purple circle or smth
click on it
under it you see the "squarish" subcategory, description is "rules that have ooo$obo$ooo as main catalyst"
you click it
under it one of the rules is B2cei3-ij5i6c7e/S1c2ace3-i4aij5iqry6c
is near rules like B2cei3-i4a6c/S1c2ace3-i4i5y and such
is smaller pinkish circle
u click
under it is "oscillators" as another subnode
click it
under p12 is link to catagolue of this:
x = 7, y = 6, rule = B2cei3-ij5i6c7e/S1c2ace3-i4aij5iqry6c
3bo$7o$o5bo$2b3o$2bobo$2b3o!
boom !!!! u have the explore the luveelvoom ruliad !!!
awesome idea right
it would make easier to come back to rules you explored a while ago
and let people find new rules you make

Et cetera, et cetera, et cetera... this is never happening, but I thought it would be fun to post...

Mockup:

Screenshot 2026-09-27 at 13-31-45 Untitled presentation - Google Slides.png (133.86 KiB) Viewed 462 times

[LuveelVoom]

I wonder if one could have some sort of curve-fitting or neural net program that predicts how long a search is going to take based on the current output logs. You get a sort of intuition for these things after a while, so what stops a machine from doing so too?

[LuveelVoom]

If anyone would like to be a beta-tester for "my" in-development partial cutter script and ntcatforce fork, please DM me. Don't publish the programs yet or claim any exhaustive results (publishing partials and full results are fine). I'm going to put the programs on GitHub soon, and if you want the beta versions then you will be able to download them from there, but I don't want them to be spread around a lot while they're still in development since the vast vast majority of the code is LLM-generated and thus likely to have serious bugs. Until final versions emerge you will have to manually go to the GitHub and download them yourself.



unrelated:
I've noticed many search programs get stuck on the frontend and then complete the rest of the ship much faster. I wonder if there's a way to avoid this and obtain a frontend very quickly (perhaps at the cost of backend speed). Scorbie mentioned these two algorithms:
https://en.wikipedia.org/wiki/Best-first_search
https://en.wikipedia.org/wiki/Beam_search

Has anyone looked into this before?

[LuveelVoom]

Some thoughts on an APGsearch management/queuing tool, and how it shall be vibecoded (Sorry for the weird BG, I had to remove the background to avoid leaking parts of my house and then compress it to make it fit in phpBB):

IMG_9666.jpg (1.57 MiB) Viewed 330 times

IMG_9665.jpg (1.67 MiB) Viewed 330 times

Also, yes, I used a red pen. What are you going to do about it?




Edit: Random braindump. A lot of searches take forever to do the frontend and then speed through the backend. I wonder if an algorithm could be constructed to find good frontends, perhaps through best-first search, and then another program/algorithm could do the back?

[LuveelVoom]

I've updated the first post to actually be an introduction to the thread!

[LuveelVoom]

They're on github now

[LuveelVoom]

Some new scripts have been thrown out onto the github. All of these are very experimental and suck at the moment. My ADHD keeps making me jump around between scripts, so partial-cutter and ntcatforce+ polishing keeps getting delayed.......

In the Misc. tools repo you will find a crawler search script.

In the new "drift" repo you will find a (very buggy) port of dr2 to INT!!!

Have fun with these and the other scripts these are all very early development though (except partial cutter and ntcatforce+ which are mostly developed featurewise and just need frontend polishing) so be careful. Also the guides suck a lot. Like a lot. This is what happens when you vibecode, folks... the majority of the devtime is spent actually making it a real project and not slop, and in this case that means making the guides (or at least the important parts) human-written.

[hotcrystal0]

I'm surprised and amazed by how drifters found by drift managed to prove two different rules omniperiodic within a 24-hour timespan.

[LuveelVoom]

I'm surprised and amazed by how drifters found by drift managed to prove two different rules omniperiodic within a 24-hour timespan.

Yep, that's what happens when you throw a powerful tool designed specifically for Life at a rule that's never had any sort of low-hanging fruit sweep (like Life has)... partial-cutter was my initial project and it's a little helpful, but I'm now realizing just how powerful INT versions of CatForce and dr2 are. I would do barrister as well, but speedydelete is already doing that with VLS at the moment (and I don't want to throw vibecoded shitcode out just to try and beat them to a catalyst searcher.)

Anyway, partial-cutter and NTCF+ are mostly complete (Although feature suggestions would be GREATLY appreciated!); dr2 is still under development; qlaudefind is going to be deprecated whenever Sokwe integrates changes into base qfind; and crawler-search is a basic script.

What I need help with now is the main barrier separating these three-and-a-half actual programs (p-c, ntcf+, drift, and maybe crawler-search) from being effective public tools: the guides SUCK. They're really, really bad. They're almost entirely AI written, are nearly impossible to read, teach the program extremely badly, sometimes don't mention useful information, and every so often even mislead the user.

Please, please, please, this is a cry for help. If you are willing to help me with cleaning up the guides for the programs, please reach out through the forums or Discord.

Also, please beta-test and stress-test these programs and report any bugs.

[Katrina]

14% speedup of qlaudefind

[LuveelVoom]

14% speedup of qlaudefind

Awesome! How was it implemented?

[LuveelVoom]

I'm surprised and amazed by how drifters found by drift managed to prove two different rules omniperiodic within a 24-hour timespan.

Now 3!

[TheWayOfTheCon]

Now 3!

It doesn't look like Katrina mentioned the search program she used.

[LuveelVoom]

It doesn't look like Katrina mentioned the search program she used.

On the discord she posted a drift infile when I asked how she found the turner so I assume she used drift

Unrelated: drift currently has an "autoscanner" mode that tests a bunch of different basic infiles to try and find anything. I find it very ineffective, however. Should I keep this or should I just remove it? It's a little helpful in finding new oscillators and occasionally a wire, but it's really irritatingly weird. The whole program is a complete mess at the moment...

[Katrina]

Now 3!

It doesn't look like Katrina mentioned the search program she used.

I used Luveel's script for it.