Re: Golly suggestions
Posted: May 2nd, 2024, 6:42 am
It won't be done by me, so perhaps you could have a go yourself. You'll need the stuff in the gui-web folder in Golly's source code, and you'll need to download and install Emscripten.
Page 18 of 18
Re: Golly suggestions
Posted: May 23rd, 2024, 2:33 pm
One thing I'd like to see would be Golly packaged as a flatpak to make it easier to install and update on most Linux distributions. However, I don't know if Golly's method of accessing text files for rules would clash with Flatpak's sandboxing.
Re: Golly suggestions
Posted: May 25th, 2024, 8:14 am
Multistate rules can be packed in a .zip file with the pattern that uses it, adding them to the Rules folder is not necessary.
(Almost all multistate patterns added in the recent few releases have their rule packaged along with it in .zip, i wonder why this method had stopped in the 4.3 release)
(Almost all multistate patterns added in the recent few releases have their rule packaged along with it in .zip, i wonder why this method had stopped in the 4.3 release)
Re: Golly suggestions
Posted: October 2nd, 2024, 10:13 am
I found I could not do that though Golly is open-sourcedislptng wrote: September 30th, 2024, 4:32 am I suggest dots to be replaced with hyphen, while I was planning a project, hacking Golly to make it support some rule like B3/S23|B38/S238 and Rychládrát. In my hacking project, the dots are used in some special cases.
Then I'll post here to tell the developers to do that for me.
My thought:
Add a new system, separated from the "algorithms", called "Rule Controls".
There are 3: "Stable", "Cyclic" and "CtrlLoader".
"Stable" just acts as Golly 4.3 works now;
"Cyclic" for some rule that switches(i.e. rulestrings with "|");
and finally, "CtrlLoader", loads from ".ctrl" file in a folder called "Controls".
a ".ctrl" file look likes (take that for example):
Code: Select all
@CTRL Rychladrat
Describe. It maybe no longer supports something like á, so use a instead.
@PART SignalPropagate
@TABLE
n_states: xx
neighborhood: xx
symmetries: xx
x,x,x,x,x,x,x,x,x,x # Yes, just normal .rule format
@PART GateCompute
@TABLE ...
@CONNECT
SignalPropagate RunUntilNoChange
GateCompute RunForGen 1
Code: Select all
+ x = *, y = *, rule = Rychladrat, part = SignalPropagate
xxxxxxxxxx!PLEASE! HEXAGONAL ISOTROPIC NOTATION SUPPORTION!
PLEASE! RULELOADER CUSTOM & RANGE 1-5 NEIGHBORHOOD SUPPORTION!
Re: Golly suggestions
Posted: October 2nd, 2024, 7:47 pm
can we have rules with random transitions? [a_1,b_1;a_2,b_2;...a_n,b_n] notation could be used where a_n is the state and b_n is the number of chances for this transition
Re: Golly suggestions
Posted: October 2nd, 2024, 8:09 pm
Writing ALL CAPS forum posts is unnecessary.islptng wrote: October 2nd, 2024, 10:13 am [...] PLEASE! HEXAGONAL ISOTROPIC NOTATION SUPPORTION! [...]
(Although I agree that it would be nice to see the existing rulestring notation for two-state isotropic cellular automata with honeycomb neighbourhood supported in a future release of Golly.
As a side note, unfortunately the notation is currently incorrectly attributed on the wiki, see viewtopic.php?p=193883#p193883 and viewtopic.php?p=193449#p193449 )
I think it would be possible to implement support for ruletables with arbitrary lists of neighbours and with arbitrary permutation groups for symmetries, in the same way (looking from the user's viewpoint) as already implemented in lifelib.islptng wrote: October 2nd, 2024, 10:13 am [...] PLEASE! RULELOADER CUSTOM & RANGE 1-5 NEIGHBORHOOD SUPPORTION! [...]
However, such higher-range ruletables would likely be slower than RuleLoader; such higher-range ruletables would likely be better implemented as a separate algorithm (as opposed to RuleLoader); and that might be too much work to implement directly without preceding refactoring / preparation work.
Re: Golly suggestions
Posted: January 29th, 2025, 9:11 am
I don't know which forum is adequate for this topic, so please move if it fits better in another forum.
This is topic for request for adding new features to Golly.
Please request only things that you really need, not for fun.
Edit by Sokwe: moved.
Edit by PiSpaceships: thank you.
Is it possible to implement the ability to change cell states using keyboard shortcuts while drawing? I know how to change keyboard shortcuts, but I don't see a similar option anywhere.
This is topic for request for adding new features to Golly.
Please request only things that you really need, not for fun.
Edit by Sokwe: moved.
Edit by PiSpaceships: thank you.
Is it possible to implement the ability to change cell states using keyboard shortcuts while drawing? I know how to change keyboard shortcuts, but I don't see a similar option anywhere.
Re: Golly suggestions
Posted: January 29th, 2025, 10:05 pm
You can assign keys to the actions called Next Higher State and Next Lower State. If you need something more complicated than that then you could assign a key to run a script that calls g.setoption("drawingstate",n) where n is from 0 to g.numstates()-1. To get the current drawing state you can call n = g.getoption("drawingstate").PiSpaceships wrote: January 29th, 2025, 9:11 am Is it possible to implement the ability to change cell states using keyboard shortcuts while drawing? I know how to change keyboard shortcuts, but I don't see a similar option anywhere.
Re: Golly suggestions
Posted: July 4th, 2025, 4:49 pm
I use Golly 4.2 and I know there are higher versions.
May be it is solved.
If I change the origin in Golly (i.e., key 0 on chosen cell),
then get the rectangle of the pattern in a script (i.e., g.getrect())
The X and Y coordinates have the old values (i.e., before origin have been changed)
It's not very good on my mind.
It stills possible to resolve the matter (wtf!) :
May be it is solved.
If I change the origin in Golly (i.e., key 0 on chosen cell),
then get the rectangle of the pattern in a script (i.e., g.getrect())
The X and Y coordinates have the old values (i.e., before origin have been changed)
It's not very good on my mind.
It stills possible to resolve the matter (wtf!) :
Code: Select all
# Trick : in case the origin was changed in Golly by user
r = g.getrect()
pat = g.getcells(r)
g.select(r)
g.clear(0)
r0 = [0, 0, r[2], r[3]]
g.putcells(pat, 0, 0)Re: Golly suggestions
Posted: July 4th, 2025, 11:52 pm
The origin changing feature is really only cosmetic and never meant to be used by a script (much like the "Y coordinates increase upwards" option in the View prefs). Now, I could add a new option like g.setoption("neworigin",1) that would tell all further commands like g.setcell, g.getcell, g.getcells, g.getrect etc etc, to use the new origin, but that would be quite a lot of work and I'm not convinced it's really needed. A simpler change would be to modify g.getpos to accept a special character that would return the modified origin offsets: xo,yo = g.getpos("o") . But I'd still need to be convinced that it would be useful. I suspect there are better ways to do whatever it is you want to do!Tawal wrote: July 4th, 2025, 4:49 pm If I change the origin in Golly (i.e., key 0 on chosen cell),
then get the rectangle of the pattern in a script (i.e., g.getrect())
The X and Y coordinates have the old values (i.e., before origin have been changed)
I don't really understand the point of your little script. It behaves the same (correct) way regardless of whether or not the origin has been changed.
Re: Golly suggestions
Posted: July 5th, 2025, 1:48 am
I'm agreeing with you, there's no needs to an option to change the origins in a script.
I'll try to be more clear.
Say the user pastes a pattern anywhere on an empty universe.
The user selects the whole pattern (i.e., key a) and change the origins by pressing 0 when the mouse is on topleft corner of the selection.
In this situation, if I launch r = g.getrect(), then I get the old X and Y coordinates.
So if I select (by the script) a region to delete it, I'm not at the good place.
Other : add a Block at (0,0), the Block will be at (0,0) of the old coordinates.
I think it will be good that a python script recognizes the new origins and uses it.
I'll try to be more clear.
Say the user pastes a pattern anywhere on an empty universe.
The user selects the whole pattern (i.e., key a) and change the origins by pressing 0 when the mouse is on topleft corner of the selection.
In this situation, if I launch r = g.getrect(), then I get the old X and Y coordinates.
So if I select (by the script) a region to delete it, I'm not at the good place.
Other : add a Block at (0,0), the Block will be at (0,0) of the old coordinates.
I think it will be good that a python script recognizes the new origins and uses it.
Re: Golly suggestions
Posted: July 5th, 2025, 3:51 am
Why not just use r = g.getselrect() to get the selection rectangle? The 1st two elements in r are the x and y coordinates of the top left corner of the selection.Tawal wrote: July 5th, 2025, 1:48 am Say the user pastes a pattern anywhere on an empty universe.
The user selects the whole pattern (i.e., key a) and change the origins by pressing 0 when the mouse is on topleft corner of the selection.
In this situation, if I launch r = g.getrect(), then I get the old X and Y coordinates.
So if I select (by the script) a region to delete it, I'm not at the good place.
Re: Golly suggestions
Posted: July 5th, 2025, 5:35 am
Ok, in case the user have changed the Origins, the X and Y coordinates aren't representatives.
The changed origins are just an offset for the GUI and are not applied on universe.
The changed origins are just an offset for the GUI and are not applied on universe.
Re: Golly suggestions
Posted: October 7th, 2025, 12:29 am
Golly needs a section that displays the current rulestring/ruletable on the right, just like that code in Ready.
Re: Golly suggestions
Posted: March 7th, 2026, 11:48 am
This seems like an oversight to me: icon sets for hexagonal and von Neumann [R]History, [R]Super and [R]Investigator rules don't appear to have the checkered even states that Moore rules have. Is this something that can be resolved?
- IMG_5795.jpeg (396.54 KiB) Viewed 4454 times
- IMG_5794.jpeg (393.3 KiB) Viewed 4454 times