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 - Simon

Pages: [1] 2 3 ... 195
Contests / Re: Level Solving Contest #5
« on: August 22, 2019, 01:58:41 am »
Sorry, I've had little time since August 2019. Good luck to everybody else!

-- Simon

Beautiful corner case, very nice find.

(c) is good, prevent assignment to whoever has been oh-noer. Reasoning: Oh-noers can already exit, therefore oh-noers should drown and trigger traps.

Oh-noers should not descend to the bottom of the well, bypassing all water, and bomb holes in the bottom.

Need (b) too, apparently, ignore swimming ability when oh-noer enters water.

-- Simon

Lix Main / Lix Proof Collection (replay database)
« on: August 18, 2019, 07:35:41 am »

...offers at least one solving replay ("proof') for every singleplayer level in the main Lix download.

Install: Follow above link -> Clone or download -> Download as Zip -> Extract within replays/ of your Lix installation.

Usage: Lix's main menu -> Replays -> navigate to the extracted directory -> Verify Dir.
Alternatively, run from the command line: lix --coverage replays/<theExtractedDirectory>
Alternatively, watch individual replays from the Replay browser.

A solving replay is called a proof of solvability for its level. A level with at least one proof is called covered. Ideally, the proof shows the intended solution. When somebody else than the level author covers the level, it's usually close to the intended solution, but it might be a backroute.

If you're a singleplayer level designer, it's good style to cover your levels. If you would like your levels included in the main Lix download, please send me both the levels and their proofs, so I can include your proofs in the proof collection.

-- Simon

lemming is building a long stair and you have 5 builders, assign the builder five times to the lemming quickly and fast forward a couple of times, voila! Your long stair is completed! 8-)
Skill queueing like in Lix is a desired feature that I am totally 100% in for!

Lix queuing will affect physics. NL 12.6 requires one frame of shrugging between two builders; player may only re-assign builder during this shrugging frame. Queued builders will skip this frame. Replays with such queuing will fail on NL 12.6. All NL 12.6 replays will play perfectly in (NL with queuing).

Invalid skill assignments that were not wanted before and that are now distrupting solving replays.

First hunch is that this should fail fast and noisily. NL should refuse the replay when opening the file. Nastily, such early detection would require a complete physics simulation; also, viewer would get no information about what the problem is, and would have to guess.

Thus, I have no proposal yet.

I still believe that it is correct for NL to disallow two assignments during same physics update.

-- Simon

NeoLemmix Main / Re: User interface for modifying hotkeys
« on: August 15, 2019, 05:32:39 am »
Very nice, yes, there is lots of UI improvement potential in the hotkey dialog. Proxima and namida have the big points already.

If we keep Find Key button, remove the one-time message box on the Find Key button, and instead put the msgbox's text on/besides Find Key.

-- Simon

General Discussion / Re: Simon blogs
« on: August 06, 2019, 04:50:46 am »
With regard to Lix specifically, which color tends to be the most visible? Perhaps every player should see their own lixes in that color?

Lovely idea for future projects. It would also obviate GUI to pick color. Fewer choices. I took (Player A's color on A's machine is same as player A's color on B's machine) unquestioned from physical board games.

I draw local player's lixes on top of everybody else's. Often, that's exactly want we want. Downside: Lone enemy attackers are invisible in an own dense crowd. Although (automatic color choices, local player gets best color) would have same problem.

I really don't think that's a good idea. Players tend to get attached to their favourite colours and want to keep playing as them :)

Yeah, I believe I don't want (fixed color that each local player uses for themself) in Lix.

#1 reason: people really care about the color. Raymanni even wants extra colors (8 -> 12) and would be happy to keep the player limit at 8; then, extra colors would be completely irrelevant to physics.

#2 reason: People in voicechat refer to other players by color. Opponents' colors must be clearly visible.

#3 reason: The replay format identifies teams by color.

#2 and #3 would work with server-side (for each team, fix a color across all machines). But since some color has to be picked and transmitted anyway, we can let the people pick it, they love it.

To be clear, this is mostly a solved problem for Lix, correct?

Right, unless Raymanni wants extra colors. Mainly, I wanted to write about the abstract problem, less about Lix.

Hard to imagine how you'd do better for 8 with rainbow + black & white. Basically the 8 corners of the RGB-space cube.

Neither the 1-metric nor the 2-metric in the RGB cube agree with the human visibility metric. Red (255, 0, 0) and black (0, 0, 0) are 255 apart and are clearly distinguishable. Bright green (0, 255, 0) and bright cyan (0, 255, 255) are also 255 apart, but far less disginguishable than red and black.

Sorry for late answers! More on ccx's ideas later.

-- Simon


Indeed, the Lix algo tries to have savestates of useful phyus (= physics updates = moments in gametime).

In particular, there is always a savestate younger than a second, and another younger than two seconds, for quick take-backs of the most recent error.

Memory for savestates is not as cheap as the article might make it sound, but still cheap enough to carry several savestates of larger maps. The trick is to throw away most older savestates: The older the savestates are, the larger is the required phyu interval to keep them, and all others are discarded.

2015 Lix offered no takeback at all in singleplayer, which is perplexing because the infrastructure already existed from multiplayer, to recompute whenever laggy game packets arrived.

2015 NL had no savestates at all and recomputed from the beginning for every takeback.

2019 NL is grained looser than Lix, but keeps more overall savestates. 2019 NL is slightly less performant for undoing recent mistakes.

-- Simon

General Discussion / Re: Simon blogs
« on: July 31, 2019, 12:14:48 pm »

Christmas tree problem

You have a fir tree and want to decorate it with christmas lights.

The fir tree's green bushy "surface" is cone-shaped, with a circular boundary at the bottom.

You also have n candles. These are about to be placed on the fir tree.

In reality, the candles would be connected by electrical cable, which would restrict the candles' distribution on the tree. Assume that the candles need no electricity, or that the cable between any two candles is arbitrarily long.

Task. Distribute the n candles on the fir tree such that the candles are nicely spaced apart from all other candles. You may place candles on the boundary.

Precisely: Given a distribution D of the candles, compute the minimum of all distances d(k, k') between all candles kk' of D. We call this minimum f(D). We want to maximize f. Thus, denote by M the supremum of the minimum distances of all distributions, M = sup { f(D) : D is a distribution }. Finally, find an arrangement of the candles D that attains f(D) = M. If no such arrangement exist, instead find a sequence (Di) of arrangements such that the sequence of minimums f(Di) converges to M.

In a variations of the christmas tree problem, you're encouraged to avoid the boundary, too. Then, for each distribution, don't merely compute the minimum of all candle-to-candle distances, but also the minimum of all candle-to-boundary distances, and use the minimum of these two minimums. Across all distributions, maximize this value.

Example. Given only one candle, put it anywhere you like. If you'd like to avoid the boundary, too, then put the lone candle at the top of the tree.

Example. Given two candles, even if distance to the boundary doesn't matter, the best distribution depends on the shape of the cone. If the cone is very tall and thin, put one candle at the top and one on the circular boundary at the bottom. Otherwise, if the cone is squat and low-risen, put both candles on opposite points of the boundary.

Example. If your christmas tree is not a tree at all, but rather the unbounded real line, you can space the candles arbitrarily far from each other. This is very nice.

Application. If your christmas tree is instead the space of all colors, and you have 8 Lix player colors, find a distribution of 8 colors such that no two colors look more similar than necessary. This is hard, especially if you, in addition, want to avoid black because black lixes looks too much like the boundary level background.

End. The christmas tree problem is really about abstract metric spaces, not christmas trees, but christmas trees inspired me to first think about this problem in detail. I don't know whether this problem is known by other names in mathematics. I don't know whether it's more common to avoid the boundary or not.

-- Simon

In Development / Re: ArtLems (Cancelled)
« on: July 27, 2019, 06:45:43 pm »
35 satisfying levels is still strong. Absolutely no shame in releasing the 35 as they are. Not every release must be a pack, and not every pack must have 100 levels.

-- Simon

I think all of these forum captchas are solvable by robots, and higher difficulty merely makes it annoying for humans.

I found no link to prove claim. I'm fine trying the difficult captcha until I find proof that the difficulty doesn't hinder robots.

It's good style to change the security question frequently.

-- Simon

11 :thumbsup:

Ideally, your program already loads and writes UTF-8 without any assumptions about the encoding. I.e., store everything as bytes, don't store text as WideChar/WideString that is 2 bytes in Delphi, the only use for WideChar is for filename arguments passed to Windows API, see utf8everywhere.

No need to render all of unicode, most fonts offer only a subset. Paint glyphs for the most common characters, and accept submissions for more. Did people tell you what characters they want the most?

-- Simon

General Discussion / Re: Crane's resignation
« on: July 24, 2019, 10:26:34 am »

-- Simon

Lix Main / Re: Lix 0.9.29 released
« on: July 18, 2019, 11:57:15 pm »
Lix 0.9.29 released.

:lix-cool: Download for Windows 64-bit -- recommended
:lix: Download for Windows 32-bit -- fallback for ancient machines
:lix: Download for Linux 64-bit
:lix-evil: Source code
:8(): Changelog
:8:()[: Issue tracker

How to update (click to show/hide)
  • Observers in a networking game begin zoomed out; they see the entire map without any extra input.
  • In multiplayer, there are no more black boxes on the score graph after a nuke. The black boxes obscured the bars of low-scoring players. The black boxes were a hack solution before we had the nice score board when you mouse over the score graph. Now, to see who nuked, mouse over the score graph.
  • Partially fix #385: The replay tweaker displays only the first 18 plies (= assignments or nukes) instead of painting the 19th, 20th, ... ply over the remainder of the panel. In the long run, the tweaker needs a scrollbar.
  • The tweaker explains itself with short text while it has no plies to show yet. This is better than presenting the tweaker as a completely blank GUI widget.
  • Fix #327: After you save a replay manually from the replay browser, the browser reloads the directory and immediately shows the newly saved file.
  • Fix: The splat ruler draws properly again when the mouse is on the map (i.e., off the panel). 0.9.28 had a bug where the ruler would only draw while the mouse was on the panel instead of on the land.
  • Fix: In multiplayer battles, you can zoom again, even though there is no GUI button to zoom. By default, zoom is bound to the mouse wheel.
  • Fix #317: In a deeply nested directory hierarchy, the browsers' breadcrumb navigation condenses some higher-level directories into a single button. The top-level directory keeps its exclusive button at the very left.
  • Removed a default keybinding duplication: Highlight goals and splat ruler were both bound to Tab. Now, only the splat ruler is bound to Tab, highlight goals has no default hotkey.
-- Simon

Lix Main / Re: Observers should start level zoomed out
« on: July 17, 2019, 07:57:24 pm »
This will be fixed in 0.9.29. Observers will start zoomed out to see the entire map.

-- Simon

This is really 3 issues now that should not be confused.

Easy pack. Make easy NL12 pack that is harder than tutorials. Icho already takes care and plans a project, Isolation, in the middle term.

Porting. Port NL10 packs to NL12. Icho's proposal is to let volunteers to this. This seems to be the correct approach. Normally, the author should maintain their work and has, by unspoken agreement, exclusive rights to publish modified versions.

If the author loses interest, community members should step forward to maintain and publish ports, taking certain liberties when NL10 levels aren't trivial to port. This is a service to both the community and to the original author. The most recent NL10 version by the original author should remain available. The original author may return and reassume maintainership.

In Lix, the content is overseeable at ~800 singleplayer levels across 4 big and many more small packs. I include most packs in the main download and maintain the proof collection for everything. NL is more decentralized, it shouldn't copy what Lix does.

Long-term preservation. You want to guarantee access to the NL10 and NL12 packs for 20 years. This is a separate issue than porting the NL10 packs to NL12. Proxima links to the NL pack list, but that is merely an index, not an archive. What happens if random authors' Dropbox links or Google drive links rot?

It's good that NL offers some packs for download already from within the installer/main pack. Does the NL site mirror these auto-downloadable packs? In general, should the NL website server mirror most packs and their replay proof collections? Should such mirroring merely be backup, or should it become the sacred central place to get packs? What happens if the pack author releases in quick succession and the (manual) mirroring is outdated? Very interesting problems.

-- Simon

Pages: [1] 2 3 ... 195