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 ... 228
1
SuperLemmini / Re: [SuperLemmini] WillLem's SUPERLEMMINAS
« on: October 18, 2021, 08:19:08 PM »
Quote from: WillLem on October 17, 2021, 05:22:01 PM
player to remember where the trap

For this, the engine (which we assume fosters execution difficulty) should reveal all hidden traps at start of play, with big flashing marks, and then hide them during play.

-- Simon

2
SuperLemmini / Re: SuperLemminiToo v1.10
« on: October 17, 2021, 11:16:38 PM »
Charles: As helpful as the Sunday may have been, it's beginning to derail your release announcement topic. And I'm derailing it further here. >_>; Should we split the topic?

Would you like mod rights for the SL board here, so you can split topics in the future, too?

We can also split the entire board for SuperLemminiToo, or we can split it later if the interest continues.


Quote from: WillLem
Are you a Windows or Mac user?

No. :P (Linux.)

Quote from: WillLem
I'd be happy to help with the dogsbody of this task in exchange for some Java lessons!

I feel like we have just the right thing:

Quote
number for the timed bombers appears slightly offset to the left.
might be worth adding it to the next update.

This bug is an ideal way for you to get into the project. One possible place to start might be GameController.java, after line 1810. (Or maybe it's to change the font images that getCountdown() returns. Or...)

Get the source and a JDK, edit the code, compile, and see what happens. When you get stuck, which is normal when trying to compile other people's larger projects, ask.

It's either this kind of jump into cold water, or hammering out your own sizeable practice project from scratch, coming back after a few months, and then jump. Consider: You have the maintainer right here for quick questions, the bug is exactly about your die-hard interests, and I see at least one plausible attempt for a fix.

Sure, Charles might beat you at fixing it, but where's the fun in not trying? :D

-- Simon

3
SuperLemmini / Re: SuperLemminiToo v1.10
« on: October 17, 2021, 06:57:52 PM »
Quote from: WillLem on October 17, 2021, 06:32:24 PM
What exactly is meant by "full rights"? When I go to Properties>Security, there are green ticks for all Permissions. Is this correct?

What I mean is: I remember that Windows grants you, as non-admin, read/write access only to some directories. You want to have SLT and root.lzp where you have such read/write access. Maybe write access is already enough.

I don't use Windows. >_>;; Thus I don't know what those checkmarks would be for.

Quote from: Charles
I've patched the error message, but if your path is being interpreted as having %'s in it, then there's probably going to be a whole host of other related places I'll need to patch.

Yeah, I've seen a couple similar such constructions in your Core.java, but didn't check every single one for whether the runtime string might end up containing '%'.

At least you know about this kind of bug now, and can catch it by eye. :) But if you already have doubts, then I think it's worth sanitizing the codebase for such unchecked formatstrings in the medium term.

Ideally, all your formatstrings are known by compile time -- some other languages can even typecheck the remaining arguments at compile time based on such a formatstring, and give you compiler errors on format specifier mismatch. Even in Java, which doesn't do that, you can strive to have only string literals, no + or other runtime arguments, in the formatstring.

(I'm no expert about best practices when you can't have that so easily, e.g., when you want to translate formatted error messages into different human languages. It's probably okay to let format throw a runtime exception in those cases, and catch it.)

-- Simon

4
SuperLemmini / Re: SuperLemminiToo v1.10
« on: October 17, 2021, 04:36:42 PM »
Check if root.lzp exists in your data tree. Ensure that you have full rights in that directory.

Reason: SLT source at the given module and line number. Looks like the exception isn't the LemmException, but it's already flying out of the formatting, which is a (separate) bug that obscures the better error message that you should have gotten.

Reason for obscured error (click to show/hide)

-- Simon

5
Engine Bugs / Suggestions / Re: [SUG][EDITOR] Levels with no exit
« on: October 13, 2021, 04:27:01 AM »
Right, I meant two separate use cases. I didn't write clearly, good catch. I've edited for clarity.

In addition, for the sandboxes, i.e., exitless maps that have save requirement 0 set by the author, you can employ (d) on top of (c). Here, (d) is really good. This also clears the confusion, (d) is so natural for sandboxes that it explains why namida began thinking of (d) in the first place.

But for normal puzzles with author's requirement ≥ 1, (d) is still weird.


Reminder:
(a) nothing changes
(b) after capping save requirement, if it is 0, never autosave
(b') after capping save requirement, if it is 0, autosave on saving ≥ 1.
(c) exitless map won't cap save requirement to exit capacity
(d) empty replays never autosave

-- Simon

6
Engine Bugs / Suggestions / Re: [SUG][EDITOR] Levels with no exit
« on: October 12, 2021, 05:50:29 PM »
Quote
However - I feel it is wrong to assume the player doesn't want to save replays in the case of an incomplete level.

Yes, sometimes, the player wants to save replays of incomplete levels. Then he will save manually.

Quote
On the other hand, nothing is lost by not saving an empty replay.

First, I call this (d): When a replay would be autosaved, if it is empty, we don't autosave.

And then I'm thoroughly confused ??? because implementing (d) seems entirely orthogonal to the original issue, or to (a)/(b)/(c). Consider: We start playtesting the exitless map, we win immediately, we assign some skills, then we exit. We have a nonempty replay that solves the map, and it should be autosaved according (d), but I doubt that we want that.

Also, there are levels where the intended solution is empty. Under (d), the player ends with incomplete pack coverage after solving the entire pack.

Quote
(c) a special case is introduced where the "save requirement gets capped to number of lemmings that there's exit capacity for" rule doesn't get applied on levels with no exits.

Still, I feel like this is the best. If the level is a sandbox, author sets the save requirement to 0 and whatever the player does, player will solve and game, enacting rule (c), will autosave replay. Edit: Here, you can additionally filter the empty replays with (d), which is very good.

Edited for clarity: If an unfinished puzzle with author's requirement ≥ 1 gets playtested without exits, (c) won't cap, therefore the replay is never solved because the save requirement is unreachable, and replay will never autosave under (c).

-- Simon

7
Lix Main / Re: Lix 0.9.39 released
« on: October 12, 2021, 05:16:19 PM »
Lix 0.9.39 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)
  • Added the dedicated end-of-singleplayer screen to show stats of the finished attempt, to offer the immediate next level, and to offer the next unsolved level in case the player has already solved the immediate next level.
  • Darkened the labels "by" and "Goal:" in front of level nameplates in the browser and in the end-of-level screen. They're now darker than the normal text color. Title, author and goal stand out better in their normal text color now.
  • Re-added 3 levels -- Fill the Floor, Interval Training, Chaos Theory -- to single/clam/Outtakes. Fill the Floor and Interval Training originally needed variable spawn intervals during play; now, they employ floaters and runners at fixed spawn intervals. Chaos Theory originally needed the nuke to solve; now, it employs manually assigned exploders to fling.
  • Updated the Lix source code to comply with the future meaning of the "in" keyword. Updated Lix for package optional 1.3.0 instead of 0.6.3.
It's been months, but it's done and released! Go forth and test, and blaze through the packs with the appropriate feeling of progression. :lix-grin:



-- Simon

8
Lix Main / Re: End-of-singleplayer screen
« on: October 12, 2021, 05:05:54 AM »
This is how the end-of-singleplayer screen looks in 0.9.39, which I released 2021-10-12.

There are stats at the top-left, similar to what appeared in the browser in ≤ 0.9.38.

Below the stats, there is the usual feedback on replay autosaving and the button to save the replay manually. It should have the same functionality as in ≤ 0.9.38, but we can improve it in the future. E.g., Proxima (?) has always wanted to type an arbitrary filename on manual saving, and I'm contemplating to add quick backroute judging.

At the top right, we have the level that we just played. The caption changes depending on whether your attempt was solved; it says "Try again:" if unsolved. The area is really a huge button, you can click that level to play again, without replay. There isn't a way to resume the just-played replay, let me know if that becomes a problem.

This means that the top half of the screen is about the just-played level.

At the bottom, we have one or two next levels. These appear even if you didn't win. Until today, that survey got 3 yes, 0 no, 1 don't mind. We'll see how it feels!

Performance of the next-level finding code: I haven't looked into it further yet. Let me know how long the screen takes to come up when you get to it for the first time after running Lix. If it takes too long, I'll make the bottom area empty first, parallelize the file searches, and add the next levels when they're found.

I'm looking into a small library dependency issue to make stuff easy for Linux package maintainers. Otherwise, this is all good to go.

-- Simon

9
Lix Main / Re: Backroute-judging feature when saving replay?
« on: October 12, 2021, 04:53:58 AM »
This won't be in 0.9.39 with the end-of-singleplayer screen yet. It's time to get the solid screen out of the door as it is; a lot has been cooking since early 2021.

I'll keep this backroute judging in mind.

-- Simon

10
Lix Levels / Re: ClamLix
« on: October 10, 2021, 12:08:06 PM »
Thanks, will include in 0.9.39!

-- Simon

11
Engine Bugs / Suggestions / Re: [BUG][PLAYER] Inconsistency in climber head-hitting
« on: October 10, 2021, 11:36:44 AM »
Lovely bug.

Surprising that the bug slept in the game for so long. The climber raises by at most 1 pixel per frame. I would have assumed that if there were different climber-to-faller behavior in the different frames of the cycle, we would have run into the inconsistency much sooner.

Normal fall heights are ≤ 63 pixels safe, ≥ 64 pixels splat. The faller from the ceiling will fall less than the full air distance, so we get some survival bonus distance.

Are you sure that 69 air pixels between floor and ceiling should already be deadly? That would mean that the falling lemming is only 5 or 6 pixels tall (69 - 64 ± 1 for nasty off-by-one). Normal lemmings are 8-10 pixels high, therefore (69 pixels are correctly deadly) would mean that the lemming starts falling with its entire head in the ceiling.

-- Simon

12
SuperLemmini / Re: SuperLemminiToo v1.00
« on: October 08, 2021, 01:10:03 PM »
WillLem should need JRE for Java 15 or newer. JDK shouldn't be necessary.

Reason: You can get a more informative error when you run SuperLemminiToo on outdated Java from the command line:

$ java -jar SuperLemminiToo.jar
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: lemmini/LemminiFrame has been compiled by a more recent version of the Java Runtime (class file version 59.0), this version of the Java Runtime only recognizes class file versions up to 52.0

... and class file version 59.0 is Java 15, exactly as Charles wrote in the readme in OP. It even tells us that we need JRE. It doesn't mention JDK.

On Windows, yeah, it's probably best to sell your soul to Oracle and install their JRE or JDK. Arch Linux's officially packaged OpenJDK goes only to Java 8 (class version 52.0), newer stuff needs either AUR packages or manual cobbling of binary packages. More complicated than what I was able to sort out during lunch break. >_>;;

-- Simon

13
Engine Bugs / Suggestions / Re: [SUG][EDITOR] Levels with no exit
« on: October 07, 2021, 06:18:00 AM »
Quote from: WillLem on October 06, 2021, 05:25:13 AM
levels with no exit have a save requirement of 0, but can never be "solved", as such (I'm not sure what actually triggers the replay

I assume: The game doesn't care about the specific moment where the physics become solved. The end-of-level screen merely looks at the stats of the finished attempt and concludes that it is solved.

Quote
(c) a special case is introduced where the "save requirement gets capped to number of lemmings that there's exit capacity for" rule doesn't get applied on levels with no exits.

Weak preference for this (c). Then, the game displays the proper value of the level field during no-exit playtest. Or do you want to allow sandbox maps with a save requirement 0 in non-playtesting?

-- Simon

14
Lix Levels / Re: Lemforum pack changes, Lix 0.9.x
« on: October 06, 2021, 09:45:32 PM »
Reason to uprank Another Funeral: I haven't solved Another Funeral after spending a total of 5 hours across several days. I've solved the next 5 levels. I'll see where I'll get stuck the next time.

I feel that Another Funeral (late Cunning) should uprank by 20-80 levels. But Forestidia thinks that Another Funeral should uprank to early Daunting at most, e.g., swapping with Round Trip, that would be upranking by 5 levels.

-- Simon

15
Editor Bugs / Suggestions / Re: [SUG][EDITOR] Keyboard shortcut to locate the originating style
« on: October 04, 2021, 07:34:48 PM »
Warmly recommended, yes.

I built this feature in Lix 1-2 years ago, and it's a solid broccoli feature: Hard to think of it at first, but you grow fond of it.

When you open the tile picker, if you have a tile in the level selected, the picker will start with your tile's directory, it will scroll the selection to centor on your tile, and even highlight the tile in the list. It's quick to pick similar tiles.

In Lix, I rarely switch tile directories any more with the normal directory navigation. I only do that to place a tile from a new directory for the first time in a level. It's far nicer to select a tile from the desired directory in the level first and hit the picker hotkey. It feels like I'm asking the editor: I have this tile here, I want to build more similar things, please inspire me with similar tiles.


NL's tile picker is always open, so it makes sense to introduce an extra key/click/action to trigger the feature. In theory, you could always scroll the picker to whatever tile you select in the level, but I have a weak hunch that this will be distracting. Hard to tell.

-- Simon

Pages: [1] 2 3 ... 228