Hi,

a frequent complaint by new users is how the skillset isn't sorted. Experienced users still have to look at the skillset at the onset of each singleplayer level. What shall we do now?

Sorting is generally nice, and custom sort-order dosen't seem worthy to implement. Maybe a sort-yes-or-no option that's on by default, that's okay. A full-blown sort order editor seems of too little use compared to its complexity.

[18:38] <SimonN> I'm considering dishing out a WIP version with mandatory sorting, and ask people to use that for a week or two
[18:40] <SimonN> thinking about it for several days now, the correct order in the right half is exploder-batter-blocker-cuber-builder-...
[18:40] <SimonN> and you and Clam make convincing arguments for why walker shouldn't come first [instead climber-floater-runner shall come first]; on the other hand, Fitts' law (button in corner is very easy to click) suggests walker first, and Neolemmix has it first also

But let's first see what you guys think.

I can post more considerations from IRC later.

geoo's proposal: climber, floater, runner, walker, jumper, batter, exploder, blocker, cuber, builder, platformer, basher, miner, digger
Clam's proposal
My proposal

-- Simon

Hi folks,

Ichotolot comes from Göttingen, the same German town where I live. We've scheduled a meetup at my place for the upcoming Sunday afternoon, 14:00 local time = 12:00 UTC.

Naturally, everyone is encouraged to suggest random ideas. We could surprise the community with another noodlish stew. We could do a youtube video of something -- Ichotolot has made at least one video with voiceover, I don't know how time-consuming that would be.

<SimonN> geoo: I'm planning noodles in a cream sauce with broccoli and ham; is this inappropriate time for broccoli?
<geoo> no, it is very appropriate
<SimonN> alright, this is gonna be a nice meetup

Stay tuned! For live mayhem, join IRC on Sunday, 2015-05-10 at 12:00 UTC.

-- Simon

Hi folks,

I would like to include the community pack in the main game downloadable on the Lix site.

• What's the current status of the pack? geoo, what do you think as its maintainer?
• What directory name should it get? lixlfpack is the current one, but only the lf carries information. It's obviously for Lix, and it's obviously a levelpack. I have once proposed lemforum.

There has been no activity around the pack for months now. It seems overdue to release it. A pack is never finished anyway, updates will be possible later on. Rubix and Clam have been fixing levels in their packs with many previous releases.

I'm planning a minor Lix update anyway, mainly for ccx's unicode support. I could include the pack with that release.

-- Simon

Edit in late April 2015: The community pack is now included in the main download. If you have further fixes to levels, let me know.

Hi,

rant rant rant, Simon has found something again with the site. :>

When writing a post, clicking a smiley above the textbox inserts <space>:smileycode: instead of :smileycode:. Why is this bad?

• Violates the user expectation: The button should insert exactly a smiley. It fails to do that. It inserts a space and a smiley.
  
• Leads to bad formatting: People generate posts with two spaces before the smiley. One they type themselves, the second comes from the button. This is very, very common:
  Recent example 1
  Recent example 2, at the end of the first line, and in the lines starting with smileys.
  Recent example 3, it happens even with many smileys directly in a row
  Recent example 4
  
• Even when you've forced yourself not to insert the manual space, if you want a smiley at the beginning of a line, you can't get around erasing the unwanted space. See example 2 above, that has the unnecessary space almost 20 times at a line-begin!
  
• Computer wants to be smarter than the user, but apparently fails.
  
• Two-fold inconsistence: The button doesn't have the space (only the image is clickable), but its output does, while the replaced string doesn't have it. (The replaced string is :smileycode:, not <space>:smileycode:, upon viewing the finished post.) Removing the space from the output makes all three things consistent.
  

I've considered to suggest the Javascript to check for whether there's a non-whitespace char in front of the cursor, and only insert the space on these occasions. This is also bad: Now the script must interpret whether BB-tags will be replaced or not. This requires the JS to include a full-blown BB-parser, which seems absolute overkill for probably unwanted complexity.

The sane solution is to ditch the inserted space. This is the simplest thing to do in the first place, and the simplest solution to the problem.

I hereby propose this. :-)

-- Simon

Hi folks,

[The Lix keyboard layout] is for people like you, not like me.
-- GigaLem

But once you make it second nature, SC2 feels smoother, snappier than ever before. Welcome to the world of enhanced control.
-- JaK (Starcraft 2 hotkey layout designer) about an advanced SC2 keyboard layout

We've had a lamenting discussion in IRC 2 days ago, and then in Lix in-game chat last night. Giga doesn't like the Lix hotkey system. Some definitions:

Skill keys: This is what Lix and Clones have. For each skill, you can map a key of your choice to it. That key will always select that skill.

Positional keys: This is what L2 and Neolemmix have, and L++ (= old Lix) had it until 2010. For each skill button on the screen, you have a key. These keys are arranged similarly to the on-screen buttons, in a row or grid. The key will therefore select different skills on each level. You can't remap them in any of those games, but remapping doesn't belong in this definition.

Matching keys: This is what L1 and old Lemmix have. It satisfies both definitions above: F3 is always the first key, and always climber.

I consider skill keys by far the superior solution. A modern game must use skill keys. Here is a ton of reasons:

• Muscle memory. You don't have to look at the skillbar. Each key is the same skill, always. That makes you faster.
  
• Comfort. You don't have to move the hand, you map skills to left-hand typing letters. If you mouse with the left hand, you map them all over to the right hand. That makes you faster.
  
• Ergonomic rolling motions. You want common composed actions as a smooth finger roll, like walker-jumper. The Lix default layout is not optimal for this, but the Lix layout can be amended (<-- link to topic). That makes you faster and removes human errors.
  
• Directional select. This must be in reach at all times!
  
• Extra surrounding keys. You can have pause on space, reload or fast-forward on the number row, ..., all quick to reach.
  
• The strong players all like speed/ergonomy-maximizing layouts, in both Lix and Clones. And Starcraft 2, see initial quote of this topic. And Quake, and, and, and...
  

What are the drawbacks of skill keys?

• It takes longer to learn.
  

About this drawback, I agree with the linked Starcraft article:

[Our custom layout] does thousands of actions, and every common action, faster than standard or grid [= positional/matching keys], giving you more actions per minute. It minimizes strain, increasing endurance. It is not what you are used to. It gives you the edge. It’s time for better mechanics.

The time has come to choose between what is right, and what is easy.

[...] It greatly depends on your natural ability to adapt to change, but players often report between the range of 30-100 games [each takes 20 minutes on average] for a basic understanding and feel of the layout and 100-200 games for a complete understanding and feel of the layout.

And that's for a game which has about 5 to 10 times more keys to learn than Lix. Learning the Lix layout is faster than learning SC2 layouts.

Your choice of hotkeys is printed on the on-screen buttons, to help you learn it.

Yes, learning a new layout makes you play worse at first. Nobody cares. :-) I've learned a different keyboard layout and ate 1 to 2 months of sucking at typing. I've remapped and relearned in Lix and Clones several times, and took the temporal suckage.

geoo likes skill keys so much that he hates Lemmix's default, unremappable keybinds. He has remapped them with an external program to match his Lix layout.

To compare, what happens with positional keys? Giga suggested the F1 through F12 for the 12 skill buttons. Maybe it's faster to understand at first.

Then, you will end up distracting yourself from the game by looking at the skillbar all the time. You must look at your hand while you move it in position, but looking at the hand shouldn't happen at all. You will never have more than 3 or 4 keys in easy reach. While you can do rolls, by setting the hand up for them before they happen, they will never feel nice!

<SimonN> anyway, he knows what he wants, but he doesn't understand what it would bring him
<SimonN> I know that he might be slightly faster than now, but can never have the good advantages of the clustered layout, and I'll have to implement it and support it as a user option
<NaOH> shh, pat pat
* NaOH ruffles your hair with her bunny paws

Making Lix keys matched?

That requires to arrange the on-screen buttons in a cluster similar to the keyboard keys. Probably not feasible, even with a higher resolution.

Making more skill keys (we have 12 at any one time, but there are more skills in the game than 12) doesn't solve the problem too well, when they're all aligned in a row. There is no good set of keys all in a long row.

A clustered on-screen display of the buttons is possible with a higher resolution, but it would look a little unwieldy. Also, a row of on-screen buttons is best for the mouse: Each button is at the edge of the screen, where the mouse cursor can't overshoot, making the buttons easy to hit.

More data from new users

When Proxima tried Lix for the first time, he wanted keys to move the skill selection left/right. This is also a positional system, and therefore slower than skill keys. Proxima, what is your current opionion on all this after using the game for a longer time?

NaOH's brother has tried the game once. He wanted a matching keyboard layout immediately.

Who has additional experience as/from a new user?

-- Simon

This might be of interest only to our small group of Lix source hackers.

I'm playing around with SDL 2. (EDIT: Using Allegro 5 for a rewrite attempt since March 2015. The remaining post here is not altered.) The grand idea is to port Lix from Allegro 4 (called A4) to this library. A4 is getting old, and porting Lix to the current A5 would be similarly elaborate.

A4's BITMAP* is a RAM bitmap. Optionally, it can be a VRAM bitmap, but I don't use that anywhere in A4 Lix.

SDL (by which I mean SDL 2.0) works with three datatypes instead of one: SDL_Surface*, SDL_Texture*, and SDL_Renderer*. The latter comes as a window renderer and a software renderer. From the documentation I've digested, these types are used in the following manner:

• Renderer is the pendant to A4 Lix's pre_screen, which gets drawn onto several times until it's done and ready to be copied to the visible screen. Typically, you draw many different Texture objects, full or in part, onto Renderer, then display it. Every SDL Window should have exactly one renderer. You can't draw from one renderer onto another. You can use drawing primitives (point, line, etc.) on a Renderer directly.
• Software Renderer similarly collects data to be drawn, but ultimately draws back on a surface instead of the screen.
  
• Texture is like a BITMAP* in VRAM or a compiled sprite, I'm not 100 % sure. They can be blitted onto a Renderer, which should be extremely fast. You can have blender modes while drawing, but can't do software pixel manipulation without locking the Texture in RAM and then unlocking it again. This is slow if it fetches the Texture out of VRAM.
• Surface is the same as A4's BITMAP* in RAM. They can be converted to Texture, and probably have to, because you can't blit Surface to Renderer directly.

Now, what are good replacements for the various data structures used in Lix?

• pre_screen -> Renderer
• Cutbit -> Surface. Probably not Texture, since they must be copied onto Torbits, and the idea of Texture is to be copied onto Renderer.
• Torbit (a bitmap that behaves like a torus when other things are drawn onto it: what's drawn out of bounds reappears at the other side) -> Surface, because you should only have one Renderer, which is pre_screen.
• Map (the landscape) -> ?

Alternatively, maybe this:

• pre_screen -> Renderer
• Cutbit -> Texture, and it still draws onto Torbit, which must therefore become...
• Torbit -> Software Renderer, making a Surface again. That surface will then become a texture to be drawn onto the screen Renderer.
• Map (the landscape) -> ?

Everything was easier when I wasn't caring about drawing speed, but this is one reason why efficient game programming is hard. :>

Image: SDL hello world with Texture

-- Simon

Hey folks,

I've compiled this list of LF.net user birth years.

Most info comes from the 2005 topic How old are you lemmings fan? The posts are from January 2005, for simplicity I've assumed everyone there not to have had their birthday in that year yet.

Quotes from IRC:

<SimonN> ccx considers 23 a ripe old age, oh my (this was in the 2005 topic, of course)

<SimonN> the spambots have birthday throughout the year

<Akseli> SimonN: You want to compile everyone's birth year into the same topic? :P
<SimonN> yes, so we can point and laugh at how we thought 23 was an old age
<namida42> heh, why, how old did you expect i'd be? :P

-- Simon