• Start composing a private message to another forumer here.
  
• Attach a file: Click Browse, pick a file from disk, and wait for it to have uploaded successfully.
  
• Click Preview.
  
• Click Preview a second time.
  
• Click Preview a third time.

Expected: The attachment is still ready to be sent. It should be listed below the composed message text, and its checkbox (where you pick which attachments you want to send) should be checked.

Observed instead: The attachment is gone.

• In the first preview (= after step 3), it's ready to be sent, as expected.
  
• In the second preview (= after step 4), it's still listed, but its checkbox is off. This unchecking is the bug, because we won't send an unchecked attachment.
  
• In the third preview, the attachment isn't even listed anymore under the text. And again we won't send the attachment now. This is technically correct because step 4 unchecked the attachment.

Now I had to send a second PM and look like a dunce who announces attachments and then fails to attach them. :-P I compose bottom up: Attach first, then type the text, then type the subject line, then add the recipients. It's near-impossible to forget it this way, and I investigated and found this repro. Happy Simon.

-- Simon

Verdict by SiegeLord (Allegro 5 maintainer): Yes, bug in Allegro 5. He wants to fix it.

-- Simon

Thanks for testing and for the logfile!

I've filed this against Allegro 5 directly:
#1661 Windows: ALLEGRO_FULLSCREEN Should Open on Primary Monitor, not on Monitor 1

-- Simon

I'll focus on the hardware fullscreen monitor choice.

• In Windows, configure your monitors such that monitor 2 is the primary monitor.
  
• Download this example program: prim-moni-hw.
  
• Put it into a Lix directory. (Or into any other directory where you have Allegro 5.2 DLLs.)
  
• Run it. (It will run for 4-5 seconds, then self-close.)
  

On which monitor did it create its hardware fullscreen display? On the primary monitor 2 or on the nonprimary monitor 1?

Source code

My source code for prim-moni-hw, both in D and in C++. The above download is from the D version. For asking the Allegro 5 devs or for filing a bug, I'll have the C++ source.

The idea is: The simplest-possible code to request a hardware fullscreen display from Allegro 5 is the following. In an ideal world, it should heed your primary monitor configuration on Windows. But I expect it to ignore your configuration and pick the unwanted monitor 1.

Code Select Expand

al_set_new_display_flags(
    (al_get_new_display_flags() | ALLEGRO_FULLSCREEN)
    & ~ALLEGRO_WINDOWED
    & ~ALLEGRO_FULLSCREEN_WINDOW);
auto display = al_create_display(640, 480);

-- Simon

User-configurable color for the filled fectangle, okay.

1. This is both for game and for editor, right? Giga says "least favorite to keep turned on while making levels" and "most apt issue in editor". But WillLem is talking about builders that build into the trigger area.

2. You'll push a design task to the user that we should instead solve for the user. At least reconsider the default then, too. Is the pink default still good for 95 % of the levels?

3. You'll inflict Schopenhauer's porcupines:

• If user picks too bright a color, he runs into eye strain (OP's problem).
  
• If he picks too dim or too transparent, edges will be harder to see (where exactly does the water start behind multicolored terrain). Giga said: "needs to contrast from the level".
  

The first hunch is to combine both ideas: Fill the rectangle at 10 % or 20 % opacity, and draw an 80-%-opaque 1-pixel-thick rectangular outline.

-- Simon

I don't remember a specific reason. (But I don't know all NL design history by heart either.)

Pre-placed lemmings will already start walking before the hatch opens. You can build a meaningful level with a 2-second time limit.

It's harder to make a 1-second level because lemmings take 9-10 physics updates to exit, and they'll score only at the end of exiting. But it's theoretically possible to have meaningful play in the remaining 7-8 updates. If you allow 2 seconds, you should allow 1 second.

-- Simon

You've noticed Cookie's changes in behavior. That shows your good relationship.

Take good care of her now. 16 years is a proud age for a cat. All the best to both of you!

-- Simon

Quoteprocess more than 1 keypress per physics update.

Hmm. Do you really mean 1 per physics update, and not 1 per graphics frame, or 1 per program loop? Surely we can pause and select several skills during that (rather: between these same two) physics updates?

Quotehow often does this come up, and is it a major issue?

I habitually rewind (number 2 key in the number row) and scroll (right mouse button) at the same time, and it's niggling every time my input overlaps. It's never hugely annoying, but it's nagging a couple times every session. It's annoying enough that I'm willing to inspect the code with you. Every time I had tried to provoke it conciously, it had a 50 % chance to ignore input, and a higher chance to ignore on huge levels.

I'm busy this weekend, but we can find an evening in August/September. Focus on other bugs first. I'll play more CE when the contest levels release in September/October.

The better the software is, the more people will use it, and the more bugs they will file.

-- Simon

Congratulations to all the authors!

Wonderful sceneries and some excellent puzzles. I've played more NL than in many years before, enough to finally file some annoyances against CE that I had known for years from NL.

kaywhyn's videos helped me judge the remaining levels that I didn't play. Thanks!

Pieuw's A Tad Rad: I expected this to make it to the final round. Privately, I discussed with Icho:

Spoiler

Simon: I liked the long bashing at the left side, very nice routing.
Icho: What? The basher on the left side is old hat. The magic is about the blocker on the right side.
Simon: After the nice basher, I didn't pay attention anymore!

Strato's The Lem-Catcher's Song wins the prize for the best counterintuitive moment among the levels that I solved myself:

Spoiler

The digger must be as long as possible, even though you need only the top of the hole later and lemmings keep splatting until the digger has finished.

-- Simon

QuoteShall more than one vote be granted in the voteoff of the single rules depending on the number of levels inside a rule?
Yes
No

"No" means what exactly? Always one vote? Always multiple votes? Different system (e.g., instant-runoff system where each voter submits an ordered list) instead of first-preference?

-- Simon

Sorry, this one is on me, I confused practically everything in OP. I should have consulted my notes.

Correct bug description is now in first post, or in here

The correct repro is:

• Play any level.
• Fast-forward 5 minutes.
• Press and hold the 1-physics-update-rewind hotkey.
• During this rewinding,
  • start to right-click scroll (press and hold),
  • or zoom with the wheel (rotate several notches),
  • or select skills by hotkey.

Observed for right-click scrolling:

• You have a 50 % chance that the starting click for hold-to-scroll fails. If this click fails, the subsequent holding also fails, guaranteed. You have to release right mouse button and re-click-and-hold.
  
• Rewinding continues correctly, it doesn't depend on the scrolling's failure or success.
  

Observed for zooming with the wheel:

• For each of the mouse wheel notches individually, you have a 50 % chance that it will fail.
  
• Rewinding continues correctly, it doesn't depend on the zoom's failure or success.
  

Observed for skill selection by hotkey:

• The skill has a 50 % chance to get selected.
  
• Rewinding stops. It doesn't depend on the skill selection's failure or success; it always stops.
  

Expected: Rewinding always continues, and the second input always succeeds.

The 50 % probability is on small levels: Automaton Maintenance, or Save Our Souls. On big, laggy levels, the probability of failing increases. I fail to right-click scroll with 70 % or 80 % on Space Program 10,000 BC.

The probability of failure increases during in-game times such as x:x9, x:x8, x:x7. It's lower immediately after an internal 10-second savestate around x:x1, x:x2.

---

I'll copy I have copied this into OP.

As WillLem says: Who can repro this on Windows?

-- Simon

I still think that this is important. I don't build NL levels; if others see potential problems with these ideas (outline instead of filled pink rectangle), please bring up those problems.

It's conceivable to draw the areas of only some gadgets as outline. When a gadget affects terrain (e.g., one-way arrows), you can, e.g., fully fill the matching terrain, and not paint the air. The important fix will be that huge water areas don't generate huge pink blobs that are hard on the eyes.

I'd like to prod WillLem to consider this. People activate these helper tools when they need to know the details, therefore you want maximally clear helpers.

-- Simon

CE 1.0.1
NL 12.14

Clear Physics Mode shows the silhouettes of all gadgets in rotating colors. There is a global timer, and the color of the silhouettes is that timer modulo N in the circle of fully-saturated colors (red, orange, yellow, ..., cyan, pink, red).

Enough with that! I use Clear Physics Mode when details matter, and I don't want this distracting color clashing.

In 1.0.1 Clear Physics Mode, lemmings are dark-blue (0, 0, FF). Instead, make lemmings medium-blue (80, 80, FF). That's easier to see than dark blue (this alone will be an improvement!) and it will remain sufficiently different from the cyan athletes (0, FF, FF).

Now you can make gadgets dark green (0, 80, 0) and you won't step on any toes.

Pick other colors than what I propose, I'm happy to try other choices.

-- Simon

CE 1.0.1
NL 12.14 and other versions from years ago.
Wine 10.6

• Play any level.
• Fast-forward 5 minutes.
• Press and hold the 1-physics-update-rewind hotkey.
• During this rewinding,
  
  • start to right-click scroll (press and hold),
  • or zoom with the wheel (rotate several notches),
  • or select skills by hotkey.

Observed for right-click scrolling:

• You have a 50 % chance that the starting click for hold-to-scroll fails. If this click fails, the subsequent holding also fails, guaranteed. You have to release right mouse button and re-click-and-hold.
  
• Rewinding continues correctly, it doesn't depend on the scrolling's failure or success.
  

Observed for zooming with the wheel:

• For each of the mouse wheel notches individually, you have a 50 % chance that it will fail.
  
• Rewinding continues correctly, it doesn't depend on the zoom's failure or success.
  

Observed for skill selection by hotkey:

• The skill has a 50 % chance to get selected.
  
• Rewinding stops. It doesn't depend on the skill selection's failure or success; it always stops.
  

Expected: Rewinding always continues, and the second input always succeeds.

The 50 % probability is on small levels: Automaton Maintenance, or Save Our Souls. On big, laggy levels, the probability of failing increases. I fail to right-click scroll with 70 % or 80 % on Space Program 10,000 BC.

The probability of failure increases during in-game times such as x:x9, x:x8, x:x7. It's lower immediately after an internal 10-second savestate around x:x1, x:x2.

-- Simon

---

For the record only: WillLem's first reply (= reply #1) was for my old and wrong report:

Quote from: Simon

• Start a level.
• If it's a small level, zoom in until you can scroll.
• Scroll with the hold-to-scroll feature. E.g., map this to the right mouse button in NL's options, then scroll by holding the right mouse button.
• While you hold-to-scroll, press a skill hotkey to select a different skill.

Observed: You have a ~50 % chance to select the new skill. Otherwise, the skill key has no effect and the old skill remains selected. (The hold-to-scroll will always continue to scroll correctly, whether the new skill selects or not.)

Expected instead: The new skill gets selected for certain. (And the hold-to-scroll will always continue to scroll.)

Saturated Addition

Here's some small talk from board game night this weekend. Consider the following mathematical operation, which I'll call a saturated sum, or saturated addition.

• Input: A finite list (x₁, x₂, ...) of real numbers. It's okay if the list is empty. Order doesn't matter, but the list is not a set nonetheless: We allow multiple copies of the same number in the list, and it makes a difference.
  
• Output: A real number.
  
• Steps:
  
  • If the list is empty, return 0. Otherwise, continue with the next step.
    
  • Compute the sum s of the list, i.e., compute s = x₁ + x₂ + ...
    
  • Find the maximum max(x₁, x₂, ...). If the sum s is bigger than this maximum, return this maximum. Otherwise, continue with the next step.
    
  • Find the minimum min(x₁, x₂, ...). If the sum s is smaller than this minimum, return this minimum. Otherwise, return s.
    

Very nice. Examples:

• The saturated sum of (3, 4, 5) is 5.
  
• The saturated sum of (20, −1, −2, −3) is 14.
  
• The saturated sum of the empty list is 0.
  
• For x fixed, the saturated sum of the nonempty list (x, x, x, ...) is x.
  

Questions:

• How common is saturated addition? E.g., I would like to use this in Lix to add the speed of overlapping flingers/batters. Where else does this appear?
  
• We made up the name "saturated addition". Does it have a more canonical name?
  
• In higher dimensions, is component-wise saturated addition base-invariant? No, see below.
  

---

We can lift saturated addition: Lists(ℝ) → ℝ to a multi-dimensional saturated addition Lists(ℝ^d) → ℝ^d. Conduct saturated addition component-wise, i.e., in each of the d dimensions, conduct saturated addition separately. You'll get a point in ℝ^d as final output of the d one-dimensional saturated additions.

This depends on the choice of base of ℝ^d.

Proof: Consider the two-entry list ((1, 0), (0, 1)) of points in ℝ². The component-wise saturated addition yields (1, 1).

Now we recompute that in a rotated base. First, rotate (= express in the rotated base) both list entries counter-clockwise around the origin by an eigth. We get the list ((1/√2, 1/√2), (−1/√2, 1/√2)) of rotated points. The component-wise saturated sum is now (0, 1/√2). When we rotate (0, 1/√2) back clockwise by an eigth, it becomes (1/2, 1/2), which fails to match the earlier result (1, 1). End of proof.

Lix physics are on a two-dimensional space, but there is a clear choice of base: the gravity axis and the horizontal axis. It's natural in Lix to depend on this base and not worry about it.

-- Simon