I'll play! Thanks for organizing.

-- Simon

Thanks!

Quote from: WillLem on July 26, 2024, 05:29:09 AM

QuoteYou count the number of designers who have shown (= placed 1st, 2nd, or 3rd) exactly once in the past n contests, and you value a high count for this. Let's assume Nessy did 50 % worse than he really did (2 showings), i.e., assume he showed only once. This will improve your metric by 33 % or by 66 %, depending on who takes the now-open slot. Is that desirable?

Apologies, but I'm not sure I understand the question. Could you rephrase?

My point was that you didn't pick the best metric (evaluation function) to turn your raw data into a snappy conclusion.

Your metric was: We count the number of different designers show exactly once across the first 3 places of the past ~20 contests. We want to increase this count.

My counterexample was: Nessy showed twice, and he's not so prolific. According to your metric, it would be better if Nessy showed only once instead of twice. That will bump your count (of designers who showed exactly once) from 3 to 4, i.e., we improve the metric by 33 %. This would suggest that we should somehow hamper designers from showing a second time in a later contest.

I thought: A better metric for your point is total number of different designers across the first 3 places of the past ~20 contests.

Quote from: IchoTolot on September 01, 2024, 07:22:55 PM

Quoteunbalanced in favour of only the most prolific and popular designers

This I would 100% call not true!
The best/most popular levels win. The author is second fiddle here.

I'd only give it 95 % to be untrue. :-) The voting system has indeed a slight tendency to favor the same designer within the same contest.

This is because the initial voting buckets aren't random. You make three buckets, one per rule, and vote within each bucket. Later, survivors enter one big bucket for the semifinals. Assume designer X's level from bucket 1 survives. This doesn't affect buckets 2 and 3, but it makes all other levels from bucket 1 less likely to enter the semifinals. Now, because every designer can only enter once per rule, you have a correlation: Each of X's other levels (which cannot be in bucket 1) are individually more likely to enter semifinals than designer Y's levels individually (because Y can have one of his levels in bucket 1).

I don't think this slight tendency is a problem. If you still want to eliminate this slight tendency, don't make a bucket per rule. Make random buckets across all rules. Or change the voting system altogether.

-- Simon

Quote from: WillLem on September 02, 2024, 12:56:04 PM
this isn't something I want to pursue any further.

Please don't lock it nonetheless. There will be more useful discussion.

-- Simon

What do you expect to do with a replay search? You'll find 10 to 100 matching replays. Should the search print dates, players, ...? For each hit, there is not that much room to preview that hit. What are your use cases?

In a networking game, the client doesn't know the map filename. The level selector sends the level file to the server as raw bytes without a filename, and the server distributes that. When the client saves the replay after the match, the client still doesn't know the selector's map filename and can't use it (unlike in singleplayer) to generate a replay filename.

I've resorted to the date. Do you want the level selection to transmit the filename instead?

It's also conceivable to let the receiving client guess a filename from the level title or from looking through his own level tree, but that's dubious design. Never does the current Lix 0.10.26 guess level filenames.

Yes, external search tools can help. How exactly do they help you? For what do you search? Only ever for a level title? Or do you search for particular replays in a more specific way?

-- Simon

The black squares were a hack before I made the proper nuke icons in the big graph.

The advantage of the squares was, as you say, that they appeared on both the small graph (always in the panel) and the big graph (that appears only when you hover over the small graph with the mouse cursor).

The downside of the black squares is that they're not self-explanatory. That was why I removed them when I added the nuke icons. I didn't expect the loss that big, but it is. You're not likely to hover over the big graph to reveal the nukes. It's much better if the nukes always sit somewhere visible.

Even showing, e.g., "(nuke icon) 4/6", would be better than showing nothing (like now).

-- Simon

Thanks for the quick feedback. Looking forward to seeing you all!

I'll post as soon as we have more info.

-- Simon

Yeah, all of the following are long-missing features. Implementing all of these is considerable work. But it will be better to just start implementing some of them than having none at all.

Cursor-left to move leftward by one character.
Cursor-right to move rightward by one character.
Home to jump to the beginning.
End to jump to the end.
Ctrl+Left to move leftward to the next beginning of a word.
Ctrl+Right to move rightward to the next end of a word.

Click into the text to make the cursor jump there.

Add support for text selections in the first place.
Click and drag across text to mark the dragged-across section.
Hold shift and move the cursor to mark the moved-across section.

-- Simon

Hi,

This October, I'll visit the UK.

I'll be up for a forum meetup on Saturday, October 26th, 2024 around the area of Manchester or Leeds.

There is nothing specific planned yet for that Saturday, October 26th. I'm staying with WillLem. I expect WillLem or Flopsy to pipe up here soon, but I'm sure others from the UK have good ideas, too. Where should we meet? One loose idea is to meet in Leeds where the UK forumers met in August 2023; after all, many of you had the chance to come together there.

I have the Sunday, October 27th, free, too, and will fly back to Germany on the following Monday. I believe the Saturday is easier for whoever can spend only a single day, therefore I'm proposing to meet on Saturday and keep the Sunday as an optional second day.

Edit after Flopsy's 1st reply: Reason for why I am in the UK in the first place: WillLem, Flopsy, and I will take a road trip to Dundee, to see the Lemmings statue and the DMA office. The meetup on Sat, Oct 26th is after we return; we'll then be back in the Manchester/Leeds area.

-- Simon

Right, the main point is that many styles are "modern" in the sense of requiring more recent technology than we had in 1991. The most popular style is solving puzzles in engines that reduce execution difficulty.

There is indeed a range of execution difficulty removal. You can play in DOS with F-key skill selection and pause all the time. This is neither the nowadays popular playstyle nor is it pause-free. Golems doesn't offer single-frame rewind; Golems offers only a faster rewind where you must time the assignment afterward.* kaywhyn plays Lix without the tweaker, but with everything else.

*: Golems has individual frame rewind: Pause first, then tap rewind.

-- Simon

Quote from: Silken Healer on August 25, 2024, 07:55:45 PM
differnces between solobattle and single-player:
Timed bombers (or lackthereof)

Sure, battle physics have the timed exploders/imploders, puzzle physics don't. Or what do you expect?

QuoteHearing every team sounds (can give you a headache if it's a level where the other teams immediatley die if they do nothing)

Yes, known bug: Play assignment sounds only for local tribe, not all tribes, in multiplayer replay

I'll take this as a prod to fix that sound bug.

QuoteCan't acsess clear physics mode

Yes, because splat ruler and trigger areas are on the same button. I'll take this as another prod to fix the UI in solobattle.

-- Simon

In current Lix 0.10.26, there is nothing you can do here.

Looks like the room owner finally needs more power.

There is one band-aid solution idea that doesn't touch the networking protocol: If player X enters a room where 1 or more players have already pressed ready, X will enter in observer mode and not disturb the readiness. I can investigate whether this is possible as a pure server-side change, then it will be compatible with all of 0.10.x.

Even under this band-aid, X can still re-select a color immediately and thereby disturb everybod's readiness. The hope is that absolute newbs will not re-select a color.

-- Simon

Yeah, prod me from time to time to add those. Those are useful bugfixes on their own.

Your frequent practice is another argument for them.

-- Simon

What problems do you see with solobattle?

Solobattle is when you play a multiplayer map from the singleplayer browser. You control every team. You should be able to ignore all teams but one.

-- Simon

Thanks everybody for reminding me that Dan's original suggestion was not to autonuke, but to to show the nukings more clearly. I too think we should show them more clearly. We can fit this into Lix without changing physics, too, which is handy. (Adding autonuke rules would change physics.)

I have a soft spot for those irrelevant endgames where 4th and 5th place can be the star of the show.

The problem is the UI. I don't like showing things only by color, and it's fairly important information that 4 out of 6 players want the game to end.

-- Simon

Quote from: namida on August 22, 2024, 11:08:35 PM
Perhaps enforce "auto nuke if position cannot be improved" once more than half the players have nuked?

More than half of the teams, yes, that sounds appropriate. I'm wavering between more than half, or at least half, or at least one. Making it more than half will be in line with Icho's wish for nuke by majority vote within the team (github #408), where he also requires strictly more than half.

-- Simon