Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Den

Pages: [1] 2 3 4 ... 23
what do you put in the art field?

it accepts http:// link on the internet pointing to png or jpg file.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 04, 2018, 04:10:03 PM »
FWIW if you're gonna substitute th with something for phonetic reasons you'll need two characters... for hard and soft th.

Sure as purely phonetics, the two sounds are distinct. However, in English the two are (mostly) interchangeable allophones. Thus, English only needs one new letter for TH. Then other languages can invent their own method (on top of the new letter, most likely) if they really need to differentiate between hard and soft.

Regardless, this is only an issue if a bigram appears too commonly in particular languages. Which is the case for TH and NG. One can also make the case for some vowels, such as ER.

P.S. There is certainly an uneven distribution of frequency among the letters. But is this actually problematic? That is, one might see this and then attempt to redistribute the usage of letters more fairly. But is this actually a good idea? How would that affect typing, and the position of the letters on the keyboard? That is, would a fairer frequency distribution of letters in a corpus lead to better, smoother typing experience?

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 04, 2018, 04:29:02 AM »
I noticed at one point in the thread, single keypresses for bigrams and words were looked at. The "th" bigram is more frequent than some letters, so in theory it might make sense to give it a key, and push 'q', 'z', etc. into a layer. Has anyone tried something like that?

I have it brought it up in the design of my phonetic script. ( Such that 'TH' and 'NG' should be their own new single letters. Where TH is common in European languages, and NG is common in Europe, Asia, and Africa.

As for how to implement it on a keyboard. What are some ideas without inventing a new letter? Macros? Autocorrect? Replacement? (e.g. typing z becomes th).

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 02, 2018, 06:11:42 PM »
I start with something like this:

Code: [Select]
  40123 76598
   <$>   [_]
 -\(")# %{=}|;
   :*+   &^~

This tops the punctuation torture test by far.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: April 01, 2018, 11:35:18 PM »
Does the punc layer take bigrams like all the comparison operators etc. into account? Or was it mostly designed by hand?
Either way I'm looking forward to a numberless version of it if that feels better. Still busy learning the default layer, myself.

I ordered an X-Bows keyboard plus numpad which is due in May. Here's an idea for the key mappings based on BEAKL 15.

I start with something like this:

Code: [Select]
  40123 76598
   <$>   [_]
 -\(")# %{=}|;
   :*+   &^~

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 31, 2018, 01:39:28 AM »
overall, moving the numbers back to the number row didn't affect the scores too much.

the analyzer is problematic for code and puncs test when it comes to repeating symbols. for instance, something like long string of ********** would account for a lot of same finger and hand penalties. but in reality, you just hold down the button, so it should be effortless really. however, if that finger was a weaker finger, it could accumulate substantial penalties.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 30, 2018, 03:56:37 AM »
The numbers on punc / altgr layer are only for KLA scoring. In reality, i never type numbers on that layer. I use number row or numpad. So i might move the numbers back to number row, then put other puncs in their place on punc layer, thus better slots for puncs.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 22, 2018, 04:49:03 PM »
Kinesis released a graphical app to customize layouts for Advantage2 (in beta test mode).

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 21, 2018, 07:37:27 PM »
reaching the inner column requires spreading the fingers. which is somewhat more effort and slightly uncomfortable. it's also further away for rolls.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 21, 2018, 02:01:53 PM »
so that puts us back with vowels and punc on left .... been there, done that :-)

or do you want to overload right with etanoisrh ? :-)... put zxkqj etc on left?

Feels like you are saying hand balance should not be 50/50 ...

We're not predicting or dictating the exact locations of all the characters. We are only prescribing the scoring criteria numericaly, according to studies and best practices.

Just as fingers have different strengths, so too each hand and arm. So that should be reflected in the analyses.

Study says more like left/right hand = 0.8887, or about 47/53. Compare finger usage of BEAKL9 is 38.7/43 = 0.9.

Index is slightly stronger and agile than middle. So we give both a high share of keys pressed. But index is also shorter, so needs more effort to reach distant keys. So distant penalty for index is higher.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 21, 2018, 03:31:54 AM »
Left and right hands have different attributes and inclinations. Thus the variables in analysis and scores should also be different, rather than mirrored.

Left is weaker and slower. Wants to stay in place. So more penalty for distance. Can't handle too many letters. Finger usage should be less, and higher penalty for same finger.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 20, 2018, 03:21:44 AM »
Uploaded BEAKL 11 to 15 on KLA test and 3, under BEAKL section when selecting layout.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 20, 2018, 02:19:51 AM »
I use Autohotkey to remap all the layers.

If you just want to rearrange the alphabet, then PKL could work. Or Autohotkey with simple remapping commands.

I have very complex AHK scripts that work on my Kinesis Advantage 2, along with some hardware remaps. It covers many layers and locks/toggles. So most likely these scripts won't work for anyone else.

If you're really into alternative layouts, ideally you'd want a keyboard with built-in firmware programmability, especially for multiple layers. Popular ones Ergodox, but there a few others. However, these are not cheap.

Reason I don't like BEAKL 8 is that I much prefer the common vowels on the home keys. H is not as common as these vowels, so I don't need it at home. Similarly, TNS are the most common consonants, so they should be the home letters.

On the contrary, BEAKL Mu creator prefers nice rolls, so H-R on the home keys is understandable--it's was designed for this purpose. However, it just doesn't fit my personal style; overall, rolls are not the top priority for me.

Also as he noted, the differences in scores between the BEAKL versions are very minute. So it's really a matter of personal preference at this point. That said, at this moment, I'd like someone to test out BEAKL 15.  ;D

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 19, 2018, 04:38:44 PM »
The downside of concave wells is not as effective for less-fingers typing (e.g. 6-finger style), versus flat keyboards. Thus concave keyboards fitted for 10-finger typing limit freedom of motions. ( and limits even creative optimizations of bigrams. Although with an ideal layout, such creative outliers shouldn't be necessary in the first place.  :-\ )

So the studies also suggest to reduce the pinky usage for optimal performance. But perhaps I went too far with pinky ban, and now under-utilized it? Same for KLA Den3, over-penalizing the pinky?

I'd like to move the K down from the far index-top-inside. So borrowing from BEAKL 11&14 and slightly modified the vowel district, combined with the consonant district unchanged from BEAKL 8&9:

Code: [Select]

qhoux gcrfz
yiea. dstnb
j/,k' wmlpv

Scores generally better than BEAKL 9. Very close scores to BEAKL 8, if not for extra pinky penalties. Generally better distance than both; definitely feels like less reaching to the far corners.

Arts, Literature, and Crafts / Lists of Plen, 12d, Twelve
« on: March 17, 2018, 01:31:49 AM »
Seems quite a few lists of metaphysical, astrological, psychological, and mythical entities end up with plen* items. Including Olympian gods, zodiac, archetypes. So below table is my attempt to match them up as best as possible.

Jungian ArchetypesOlympian GodsWestern ZodiacChinese Zodiac
Innocent  Artemis
Magician  Athena
Caregiver  Demeter
Companion  Hera
Ruler  Zeus
Sage  Apollo
Lover  Aphrodite
Explorer  Poseidon
Creator  Hephaestus
Warrior  Ares
Rebel  Hermes
Jester  Dionysus

*(Plen is word I made up to replace twelve in a base twelve numbering system. Because twelve is derived from base ten system, thus a base twelve system would demand a new word for its base. Plen derives from plenty, full, complete.)

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: March 17, 2018, 01:19:21 AM »
Finger typing and arm typing certainly employ different dynamics. Yet there could be similarities for the sake of measurement. So we must reason which metrics are important for either typing style, and how these metrics are same or different.

Metrics: Distance, same finger, same hand, rolls, home keys, home block, finger weights, etc.

Explication in later post.

Just found out about synesthesia and ideasthesia. Which immediately connected me with the original vision for Flownetic script--perhaps this is a phoneme-grapheme ideasthesia, if there is such a thing. That is, when I utter a phoneme, I would visualize the form of the grapheme or letter to represent that sound, in the simplest way possible, yet related to the phoneme's audio quality, tone, and oral expression. Especially when it comes to vowels. Unlike consonants, which have obvious connections with various parts of the mouth, tongue, lips, and throat. Vowels are more abstract and fluid, so their graphemes would also have to be visualized differently than for consonants.

Keyboards and Other Interfaces / Re: One-handed Keyboard Layout
« on: February 22, 2018, 03:02:24 AM »
If other hand is able, even staying at home keys to press modifiers would provides access to at least six layers. Base layer is unmodfied, then each offhand finger at home is another layer individually; if simultaneous modifiers is achievable, that's exponentially more layers.

Programming / MTGO collection.csv file format
« on: February 16, 2018, 05:22:22 PM »
MTGO collection.csv

Programming / MTGO deck.txt file format
« on: February 16, 2018, 05:22:09 PM »
MTGO deck.txt
No comments?
Code: [Select]
4 Maindeck cards
4 Sideboard cards
Code: [Select]
2 Halimar Depths
4 Creeping Tar Pit
3 Darkslick Shores
3 Drowned Catacomb
3 Tectonic Edge
3 Augury Owl
2 Trinket Mage
4 Grand Architect
3 Molten-Tail Masticore
3 Lodestone Golem
2 Wurmcoil Engine
2 Steel Hellkite
1 Brittle Effigy
1 Basilisk Collar
4 Duress
4 Doom Blade
4 Spreading Seas
3 Jace, the Mind Sculptor
4 Negate
3 Flashfreeze
3 Stoic Rebuttal
3 Deathmark
2 Thada Adel, Acquisitor

Programming / Apprentice.dec file format
« on: February 16, 2018, 05:21:51 PM »
Apprentice.dec / Magic Workstation (MWS).mwDeck
// Comments
Code: [Select]
// Name: Name of deck (optional)
4 Maindeck cards

SB: 4 Sideboard cards
Code: [Select]
// Name: Nebulagold's deck from
// Creatures
4 Enclave Cryptologist
2 Skywatcher Adept
4 Coralhelm Commander
2 Lighthouse Chronologist
4 Grand Architect
3 Sea Gate Oracle
4 Wurmcoil Engine
// Artifacts
2 Mindslaver
// Spells
3 Jace, The Mind Sculptor
4 Preordain
4 Mana Leak
2 Into the Roil
// Lands
4 Tectonic Edge
18 Islands
// Sideboard
SB: 4 Kraken Hatchling
SB: 2 Lighthouse Chronologist
SB: 4 Flashfreeze
SB: 2 Mindslaver
SB: 3 Steel Hellkite

Magic: the Gathering / Re: Autocard as Opera Extension and Userjs
« on: February 13, 2018, 12:39:18 PM »
alter to https as necessary
removed nonexistent domains

fix sites:,,,

fixed scraping from
added split cards from Amonkhet, Hour of Devastation
added transform cards from Eldritch Moon
Apprentice MTGO
 Split Cards
// Amonkhet
// Hour of Devastation

Apprentice MTGO
 Transform cards
// Front
Extricator of Sin
Lone Rider
Curious Homunculus
Docent of Perfection
Grizzled Angler
Voldaren Pariah
Conduit of Storms
Smoldering Werewolf
Vildin-Pack Outcast
Kessig Prowler
Shrill Howler
Tangleclaw Werewolf
Ulvenwald Captive
Ulrich of the Krallenhorde
Cryptolith Fragment
Bruna, the Fading Light
Gisela, the Broken Blade
Graf Rats
Midnight Scavengers
Hanweir Garrison
Hanweir Battlements
// Back
Extricator of Flesh
It That Rides as One
Voracious Reader
Final Iteration
Grisly Anglerfish
Abolisher of Bloodlines
Conduit of Emrakul
Erupting Dreadwolf
Dronepack Kindred
Sinuous Predator
Howling Chorus
Fibrous Entangler
Ulvenwald Abomination
Ulrich, Uncontested Alpha
Aurora of Emrakul
Brisela, Voice of Nightmares
Brisela, Voice of Nightmares
Chittering Host
Chittering Host
Hanweir, the Writhing Township
Hanweir, the Writhing Township

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: February 06, 2018, 01:19:06 AM »
Is BEAKL 9 "stable" or do you foresee more experimentation in the future to create a new recommended layout; basically, is this project done or is it still evolving?

BEAKL 9 is stable candidate recommendation for mass consumption. This leg of the project is on hiatus until new breakthrough.

Do you want to proliferate this layout, or is it mostly just for your own curiosity and satisfaction? It seems like a lot of layouts are just abandoned after they're completed, like MTGAP, Halmak, Workman, etc. It would be really interesting to see a community adopt BEAKL like has happened with Colemak (which is unfortunately a bit fanatical in my opinion).

I'm not good at promotion, but have done some seeding around the 'net. Apparently, there are a few enthusiasts who have heard of BEAKL and have adopted it to their custom keyboards kits (although I know not about their experiences with it.) I do recommend people looking for optimal layouts should give any of the BEAKL layouts a try, or adapt the BEAKL philosophy to achieve a layout to their personal comfort.

Which is the utilized effort grid for BEAKL 9? I've seen one that rates upper pinkies worse than lower pinkies with upper index better than lower index, and one with equal scores for top and bottom pinkies and index fingers.

I played around with the effort grid so much, I haven't really kept track of effort for older BEAKL Opted layouts. For 8 or 9, it's something like this:

Code: [Select]
Left Hand
 P      R       M     I     I
15     1.5     1     1.5   5
 5     0.5     0.5   0.5   1.5
 7     2       5     1     7

I'm particularly curious how "L" came to be placed on the lower middle finger position as it is a very common letter and I'm surprised it isn't placed where "F" is at upper ring finger as in both effort grids, that position is rated better than lower middle.

1. L is more often doubled. Tapping double middle finger is less punishing than double ring.
2. L is used more in bigrams with other consonants, so rolls with middle finger is preferred.
3. Middle finger intended to handle higher percentage of total effort.

Which brings me to another curiosity...were any of the opted layouts hand tweaked at all? Or are they purely generated by the algorithm? Is there anything you'd prefer to change?

Actually BEAKL 9 is amalgamation of 7 vowel district and 8 consonant district. Punctuation layer manually tweaked from Arensito.

Colemak scores very well in many tests. What do you think a computer-assisted layout offers that a human's intuition and testing cannot?

Human designs can consciously or unconsciously bias toward certain factors, without knowing how it affects other factors. Humans obviously cannot generate and test thousands or millions of layouts against each other in mere minutes. It's easier to have AI find the optimal layer per specifications, then have human test it for comfort.

The latest BEAKL layouts assume the use of a somewhat large ortholinear keyboard. The most popular is the Planck, which is 12x4 (48 keys). Do you have an adaptation of BEAKL that can fit in a 40% form factor board? If the main keys are limited to 30 (instead of 32) with no number row, how would the punctuation be set up? Is there a punctuation set-up if the only concern is English prose and programming is not taken into consideration? I've often thought about placing semicolon on comma, colon on period, and making the slash into question mark with shifted exclamation point, for example.

A few people have attempted to put BEAKL on Planck keyboards. (you can search the web for them.) Puncs you can do as you wish according to your usage. I set them up in order to have great scores on KLA, while still intuitively laid out. You can take out the digits from the punc layer if you have a numpad layer. Then the remaining puncs can fit better on the home block.

I'm just very curious to learn more about and possibly adopt such an interesting and efficient layout.

I hope you give BEAKL a try. But I also ask you to inform us of your experiences.

On a final note, I found it very intriguing that BEAKL 9 seemed to score comparatively poorly against other popular layouts in distance using the Keyboard Layout Analyzer. At first it put me off, but then I considered that if the fingers were moving up and down more then they might actually be less prone to fatigue (and indeed the same finger scores for BEAKL 9 were very good, especially for pinky), so what are your thoughts on distance as a metric of layout quality? Thank you.

The original KLA has the same effort for all fingers on distance scores. But BEAKL 9 favors moving around strong fingers. Also not as many common letters on the home row; in particular, no common letters on home pinky, which could save a little distance.

Magic: the Gathering / Re: Shena'Fu's Online Card Creator
« on: February 03, 2018, 10:51:13 PM »

added Playing Card frame

Playing cardOptions
 Rank  P/T
 Suit  Set Icon or Mana Cost
 Title  Subtype
 Art and Rules + Flavor Text  Overlap in the center

Thus you can use playing card frame for a card with nothing but a bunch of text. If you have art with transparent background, you can try to overlap the art and rules text for something fancy.

Arts, Literature, and Crafts / Re: [lang] Flownetic: The Phonetic Script
« on: February 02, 2018, 12:39:35 AM »
is left column supposed to be empty as this stage?

I wrote the opinion before making the changes.

The images and scripts on the site are done. The font file will be done soon.

Arts, Literature, and Crafts / Re: [lang] Flownetic: The Phonetic Script
« on: February 01, 2018, 08:00:52 PM »
I may remodel the romanization to be more in line with Latin/English roots.

IPA can be very confusing in their choice of glyph for certain consonants, particularly for base/aspirated/voiced. Especially since the foundation are Latin/Greek, but the switching is counterintuitive for languages that use Latin alphabets.

For instance, we read 'p' in English spelling as aspirated, but IPA's /p/ is not aspirated; their aspirated form /pʰ/. IPA denotes 'b' as voiced; but in practice, most people can't tell the difference from unvoiced. This juxtaposition is very confusing to speakers of Romantic languages. Furthermore, major Asian languages don't have the voiced version, but do have the unvoiced, and so the romanization for them is 'b', which is justified. If they followed IPA, those languages would be using 'p' and 'ph', with 'b' unused and omitted.

So really the base form of this group should be 'b' instead of 'p'. Likewise for other phonic groups t/d and k/g. It makes even more sense with k/g, considering that 'ng' is the gloabally accepted transliteration of the nasal sound, not 'nk'.

So the new romanization for Flownetic:
 b  b  /p/
 bb  Bb  /b/
 p  p  /pʰ/
 d  d  /t/
 dd  Dd  /d/
 t  t  /tʰ/
 g  g  /k/
 gg  Gg  /g/
 k  k  /kʰ/
 f  f  /f/
 ff  Ff  /v/
 v  v  /θ/
 vv  Vv  /ð/

 put  pUhd  PhUht
 the  vEh  FhEh

Magic: the Gathering / Re: [YMTC] GameFAQs CCCs
« on: January 31, 2018, 03:32:05 PM »
RCC #997: Design a card that interacts with the stack in some kind of original way, or uses it as a resource.

Barbecue Fries

Put each card in your library onto the stack (in the same order.)

Keyboards and Other Interfaces / Re: One-handed Keyboard Layout
« on: January 29, 2018, 07:51:40 PM »
Multi-layers for One-handed layout

Ten main keys: home block and inward index. Thumb for layer switching, and pinky for Enter and Tab.

Below layout matches the right hand.

Code: [Select]
Layer 0:
 st e

Layer 1:

Layer 2:

Layer 0 is base layer without modifiers. Layer 1 could be accessed by Caps Lock. Layer 2 could be accessed by AltGr. Uppercase requires Shift in down position; can also try macro to capitalize the previous word.

Typing a letter should automatically revert back to Layer 0.

Num Lock unlocks numbers and puncs (not shown here).

Keyboards and Other Interfaces / Re: One-handed Keyboard Layout
« on: January 29, 2018, 02:42:17 PM »
1st try

Right Hand Typing

Code: [Select]
1061.422 total effort 199.759 positional effort left right
,gy.jz 11.856 same finger rp 5.290 shift same finger top 0.0 20.5
psrimx 0.000 hand alternat. 0.000 shift hand alter. mid 0.0 30.1
ctealk 1.264 inward/outward 85.651 inward or outward bot 0.0 18.5
fdnohv 44.765 adjacent 7.152 shift adjacent sum 0.0 100.0
bwuq 95.767 no hand altern. 0.000 two hand altern.
0.084 seesaw 0.000 indir same finger
--.- --.- --.- --.- --.- 18.7 26.3 22.2 21.3 11.5 Sh 0.0 4.8

  • space should be part of letters
  • omit rows 0 and 4
  • need more layers
  • thumbs only move between layers

Music, Movie, TV, & Sports / Re: Song lyrics in Flownetic
« on: January 28, 2018, 02:01:09 AM »
漢文Flownetic - CantoneseTranslate
李白 - 夜思 lei bag ... jae si Lei Baak - Night Ponder
床前明月光qorng qin meng jyd gworng Bed front bright moon shines
疑是地上霜ji si dei serng serng Suspect that ground has rime
舉頭望明月guey tahu morng meng jyd Raise head watch bright moon
低頭思故鄉dahi tahu si gu herng Lower head ponder old times

漢文Flownetic - CantoneseTranslate
王之渙 - 登鸛雀樓worng ci wun ... dahng gun cerg lahu  Wong Zi Wun - Ascending the Crane Tower
白日依山盡bag jahd ji san cuen White day upon mountain end
黃河入海流worng hor jahb hori lahu Yellow River into ocean pour
欲窮千里目jog kong qin lei mog Desire persists thousand miles eye
更上一層樓gahng serng jahd qahng lahu Further climb up one floor

Magic: the Gathering / Re: Shena'Fu's Online Card Creator
« on: January 24, 2018, 08:29:58 PM »

blended trims and rules box for two-color cards (in classic, modern, and planeshift frames for now). takes into account mana symbols in both mana cost and rules text.


added Token supertype

Their 'solution' is to use kiddie-size keyboards

sure, if your solution is traveling all over the entire keyboard with one hand.  ::) but that's moot if you intend for the hand to stay relatively in place.

Keyboards and Other Interfaces / Re: I only use one hand...
« on: January 19, 2018, 01:38:27 PM »
Try the CLP model. Since it optimizes lowest amount of movement. But you need great locations for the modifier keys on the thumbs. Obviously ANSI/ISO will not work at all. (we all know that that form factor is just crap for advanced keyboard design anyway.) Split keyboard may be better, since you just need one half.

Get a mouse with many buttons. Assign them meta and editing actions that replaces any ctrl- stuff. copy, paste, select all, save, back, etc.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: January 17, 2018, 12:57:24 PM »
Sorry to hear that.

Are you now gonna devise the perfect one hand layout? For that, I suggest sticky modifiers--so you don't have to hold down shifts, which would demand dexterity.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: January 03, 2018, 11:40:14 PM »
Numpad revisited. Prioritize 1, 0 at the strongest fingers.

Code: [Select]

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: December 31, 2017, 03:56:26 PM »
You really put in a lot effort for this.

You're okay with Den3 at the current state?

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: December 30, 2017, 12:54:11 PM »
Didn't like the row jumping in BEAKL 9 (mainly the L in the bottom middle, "cl" "fl"). So messed around again to get something that feels better.

Code: [Select]

qhoux ,drcb
yiea. lstnp
j/'kz wmgfv

(BEAKL 11 to 13 not to my style.) BEAKL 14 is more like what I'm used to from BEAKL EZ & 9.

Now 14 has excellent inward rolls. On paper seems high same finger on the right index, but I don't feel it at all. Favors right hand even more by moving the comma to the right hand; this causes even higher hand alternation.

Won't score high on KLA, since KLA doesn't care about rolls and row jumping. Nevertheless, very comfortable to type in.

After spending some time in BEAKL 14, still can't get used to it and not picking up speed. As good as the rolls are, it seems too much sacrifice from individual letter placement and same finger rates.

Reverting back to BEAKL 9 and immediately see my speed improve.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: December 13, 2017, 08:25:23 PM »
Didn't like the row jumping in BEAKL 9 (mainly the L in the bottom middle, "cl" "fl"). So messed around again to get something that feels better.

Code: [Select]

qhoux ,drcb
yiea. lstnp
j/'kz wmgfv

(BEAKL 11 to 13 not to my style.) BEAKL 14 is more like what I'm used to from BEAKL EZ & 9.

Now 14 has excellent inward rolls. On paper seems high same finger on the right index, but I don't feel it at all. Favors right hand even more by moving the comma to the right hand; this causes even higher hand alternation.

Won't score high on KLA, since KLA doesn't care about rolls and row jumping. Nevertheless, very comfortable to type in.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: December 13, 2017, 02:33:12 AM »
Rolls are just finger alternation. Same finger is bad; finger alternation is good. QED Rolls are better than same finger. By induction, same hand is bad; hand alternation is good. QED Hand alternation is better than same hand.

Games General / Re: [LOTGD] Legend of the Green Dragon
« on: December 07, 2017, 05:03:17 PM »
Learning about the LOTGD engine made me rethink about what and how games I want to play and to make.

  • Mapless: Moving around a map is mainly a waste of time, tedious stretching of play time. Especially 2D overhead view has been falling out of my favor for some years.
  • Endless content: Content, especially story and world design, is not my forte, very time consuming, but doesn't last long for the player to finish. Better design-to-play ratio in time and effort is repeatable, random, extensible (e.g. mods, levels, whole rosters of creatures and items) content.
  • Meaningful activities: Without the player lingering on superficial story and wandering pointlessly, the game could refocus on deeper combat and other activities, like socializing, collections, and achievements.
  • Browser-based: using web standards, like HTML, JS, CSS, PHP, SQL reaches the biggest audience that can be accessed at any time, any place, any device. Graphics optional, but HTML5 canvas and <img> & <video> tags are there if you want to use them. There are many advanced tools and frameworks for each component, like angular, bootstrap, etc.
  • Mods: One person or team can only create so much content for any given time and resources. In the same time frame, Communities can create lots of content aggregate for different gameplay, markets, themes, etc. Even for individual developer, with a supportive core engine, content can be gradually added and feel accomplished. Players/admins can choose mods and customize the game to their liking.

The key is really just a lean engine that handles the minimum interface between components and allows mods to do the rest. All you need is install the basic frameworks and make them talk to each other. No game logic, no items or creatures, no themes, no content--these will be added via mods. The engine's entire purpose is to support mods, thus it cannot have any preconditions that limit what type of mods can be made.

For instance, LOTGD has a bunch of core files to support the gameplay. So while it allows mods, the type of mods are restricted and tied directly to the core game files.

On the contrary, with a indiscriminate engine, creators can create different mods that have different gameplay styles. The server admin will decide what type of mods they want. If you don't like it, install the engine on your own server and install your own mods. Some mods will become more popular, that could lead to other mods dependent on them. But that's for the market to decide.

Suppose the gameplay in LOTGD was instead packaged as a mod separate from the engine. This opens up great opportunities. For one, this mod can be forked and modified as befits the server admin. Two, creators can create totally new combat engine, character stat system, etc. without messing with the core files, which would be nightmare for admins. Instead, the admin can simply uninstall the old combat mod and install a different mod.

Games General / [LOTGD] Legend of the Green Dragon
« on: December 02, 2017, 05:04:25 AM »
Play my run of Legend of the Green Dragon at

version 1.1.3 from github, with many of my fixes in order to work on current PHP versions. Changed some names and parameters:
  • Violet => Seungyeon
  • Seth => Xay
  • Degolburg => HanSeung
  • new day => 4 hours real time
  • daily forest fights => 1000
  • daily travels => 30

I installed a bunch of older basic mods, but not all of them work. So expect some issues.

Learning to make my own mods, which can be found at my LOTGD page. Using classes for cleaner code. Including:
  • The Pubic Library - a dirty bookstore, focusing on erotica and dirty humor
  • YellowFour template (much cleaner HTML & CSS viable for any screen size. Uses grid, falls back to flex.)
  • New Races: Fairy (lower damage*, higher defense)
  • New Specialties: Idol (use the powers of your charms)

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 21, 2017, 05:32:10 PM »
Pressing, tapping buttons require precision and speed, both of which dominant hand does better. In case of joystick, the buttons need that attention more, so they are operated by dominant right hand.

Programming / Re: Versatile Separated Values (VSV)
« on: November 15, 2017, 07:58:13 AM »
VSV Usage examples and comparison to other formats

VSV as Tabular Data

Double Matching Brackets are header fields (optional)
Everything else are data rows

(When using the Comma , as delimiter, similar to CSV)

Code: [Select]
((Name)) ((Score 1)) ((Score 2))
,BEAKL 8, 104, 132
,BEAKL 9, 120, 144
,BEAKL 10, 44, 99

NameScore 1Score 2
BEAKL 8 104 132
BEAKL 9 120 144
BEAKL 10 44 99

(Can use any nonspace character as delimiter--lots of freedom)

Code: [Select]
[[Name]] {{Age}} ((Gender))
,Hammie, 20.5, F
-Chow, Vivian-40-F
*Shena'Fu *18+5/12 *F
|Grndr-1245|21 months||
Fairy Nuff 14 K N/A

Hammie 20.5 F
Chow, Vivian40F
Shena'Fu 18+5/12 F
Grndr-124521 months
Fairy Nuff14 KN/A

VSV as Linux password file

The Colon :  starts each line and separates each field

Code: [Select]
:smithj:x:561:561:Joe Smith:/home/smithj:/bin/bash

VSV as configuration file

Double Square Brackets [[ starts each section
Unclosed Double Brackets are comments and help
The Equal = starts each line and separates the setting key from its value

Code: [Select]
((display options: fullscreen, windowed, windowedmax

VSV as XML replacement

Double Angled Brackets << as tags
Close innermost tag with the Slash / inside double brackets
Data rows as attributes and content
Use spaces to indent

Code: [Select]
   ~txt~Don't forget me this weekend!

VSV as Objects and Arrays

Double Curly Brackets {{ as Objects
Double Square Brackets [[ as Arrays
Close innermost object or array with the Semicolon ; inside double brackets
Data rows as properties
Use spaces to indent

Code: [Select]

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 13, 2017, 06:06:47 PM »

What keyboard(s) do you use to type BEAKL 9 on?



Kinesis Advantage2 (cheaper elsewhere)

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 12, 2017, 12:08:01 PM »
Impressive. I'm probably around 30 wpm still. I think it's week 6 on BEAKL 9. Of course, I've only recently switched full-time. Ended up having to switch entirely as my typing on a dvorak kinesis advantage at work has seriously degraded. Due to the 'key confusion,' I'm about 30-ish on both layouts at the moment. Guess, I was unable to maintain both. Incidentally, that is what I wanted to know.

It helped that I had been using BEAKL EZ prior for a while. The 9 most common letters are in the same places between BEAKL EZ and BEAKL 9. So the transition is easier this time around.

After using Dvorak for years, it began to fit like a glove, second nature. So it'll take yet longer than a month or two to regain the same feeling of mastery with a new layout.

Programming / Versatile Separated Values (VSV)
« on: November 12, 2017, 06:05:20 AM »
Versatile Separated Values (VSV)

Proposal: A versatile, efficient, unambiguous, standardized, simple text format for creating tables and lists that's easily read and created by both humans and machines, that supports many variations for any personal style, preferences, and protocols. Can accept any nonspace character (including comma, colon, tab, asterisk, etc.) as delimiter automatically without user input (no annoying popups or options to fill in).

The same simple algorithm will accept almost any delimiter you want. You want commas like CSV? No problem. Or fields separated by tab (TSV)? Sure. How about *NIX files that use colons? We'll take it. Want to mix them up in the same table or file? Go ahead.

Exporting to VSV (creating files)

Rows are separated by newline. 

Header rows are optional. Each header field is enclosed by any of these double matching bracket types:
Code: [Select]

Different header fields may use different brackets types. Mixed bracket types may be employed on the same header row.

When exporting to a VSV file, characters that are found in a header field must not be used as enclosing brackets for that field. Choose a bracket not found in that field to surround that field.

Data rows (non headers) must be led by an explicit nonspace character, called delimiter. Values for that row are placed between two delimiters. The first occurrence of a delimiter on that row is not counted as part of the values.

A null value has zero length, signified by consecutive delimiters with nothing in between them.

A delimiter at the end of the line after the final value is optional, unless the final value is a null value.

Each row may have its own distinct delimiter. A text file may have different rows with various delimiters. Creators can use the same delimiters or mix them for different rows, as long as the desired values on that row are distinguishable (i.e. to prevent delimiter collision.)

When exporting to a VSV file, characters that are found in the values of a given row must not be used as delimiter for that row. Choose a character not found in that row's values as the delimiter for that row.
  • Space and newline cannot be used as delimiter. Any other single character may be used.
  • Letters and numbers may be used as delimiters, but are not recommended.
  • Avoid using header field brackets as data row delimiters. Nevertheless, single bracket at beginning of a row should be read as a legal delimiter.
  • Creators may have their own preferred delimiters. Common delimiters to use:
Code: [Select]

Importing VSV (reading files)

Rows are separated by newline. Leading spaces on each row are discarded and ignored.

If the first two nonspace characters of a row are identical opening brackets, this is a header row. Else it is a data row.

Header fields must be enclosed by both an opening and a closing matching double brackets. Any other text on a header row is discarded and ignored.

The first nonspace character of a data row is its delimiter. The values of this row are stored between two delimiters or the end of line. A value can have zero length, or null value. There is no value between a line-ending delimiter and end of line (it doesn't count as another value, not even null value).

In PHP, use the explode() function to store a row's values into an array split by the delimiter. For other languages, use a regexp to match the values separated by the delimiter.


See :


How to handle values that contain newline?
Can it be used for objects or hierarchy? i.e. in place of JSON, XML, HTML
Can it be used as configuration file? cf. INI, CONF files

Keyboards and Other Interfaces / Re: WordCount metrics
« on: November 11, 2017, 03:55:51 PM »
for comparison, the bottom end looks like this, with the worrying inclusion of Amuseum (and Plum Ergolinear, for that matter):

Don't be too concerned for Amuseum layout. It was designed for rolls. So in fact it doesn't mind the long one-hand sequences.

Keyboards and Other Interfaces / Re: WordCount metrics
« on: November 11, 2017, 01:55:26 AM »
Finally dawned on me the problem with the one-hand metrics, as regards AltGr layouts ... I was ignoring which hand the needed thumb was on.
So I need to see where the Shifts and AltGrs are, how they are used, and then only use letters accessed by them if on same hand.

Biggest effect is going to be on the SC layouts.

Dunno if Den is using same methodology, or doing what I was doing previously and just looking which hand is used to press the key ...

For SingleHand words, Shifts and AltGrs are transparent. That is, they don't add or subtract to the handed-ness. They are just helpers to access letters on different layers--even if they are opposite hand. Ultimately the letters are still typed on the same hand, including stuff like rolls, row jumps, same fingers, etc. are still happening with the non-thumb fingers. Therefore effort is expended likewise as if on the same layers.

Seelpy 1.5 still has good Words score on KLAtest despite that. The excellent HomeBlock score compensates for bad SingleHand score, but overall is quite competitive in this category.

re: overall Words scores

Some layouts really stumble on this category. Including Arensito, Colemak, BEPO, etc. As expected from low hand-alternation layouts, which leads to lengthy one-handed strings, up to 10, 12, 14 letters consecutively on the same hand (according to your chart)--that's ridiculously inefficient.

Keyboards and Other Interfaces / Re: Guilty as charged
« on: November 10, 2017, 09:30:00 PM »
Will the accused please rise?


Skip to the "Keyboard Design: Universal, Ideal, and Simplified" part.

Ya of course there's parties interested to maintain QWERTY as the standard.

It's also amazing that people were able to hit 140 WPM with those ancient typewriters with steep rows.

Keyboards and Other Interfaces / Re: Balanced Keyboard Layout
« on: November 10, 2017, 09:10:33 PM »
BEAKL 9 (Personal speed typing progress)

Corpus Sight Words (Easy-to-type)
Type Random Words
Test Results
Speed 76 WPM
Accuracy 96.3 %
Correct Entries 367
Incorrect Entries 14
Fixed Mistakes 14
Total Entries 381
Error Rate 0
Raw Speed 76 WPM
Key Speed 381 KPM
Complete Words 82
Total Time 1 min(s)

Corpus The Fox and the Goat
Author Aesop
Type Fables (Easy to type)
Test Results
Speed 74 WPM
Accuracy 95.7 %
Correct Entries 356
Incorrect Entries 16
Fixed Mistakes 16
Total Entries 372
Error Rate 0
Raw Speed 74 WPM
Key Speed 372 KPM
Complete Words 75
Total Time 1 min(s)

Only been with BEAKL 9 for around 40 days, and already up to 75 WPM (started at around 55-60). I think it's pretty good progress, and shows that this layout is easy and has low learning curve. I don't practice and hone speed typing, but naturally improving by using it for everything. Still make too many errors, though.

I seem to type faster when leaning back, arms stretched out. Elbows at right angles can feel too stiff and not as mobile.

Pages: [1] 2 3 4 ... 23