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

Pages: [1] 2 3 ... 727
Lix Main / Re: Undo in the editor
« on: July 09, 2020, 10:43:04 pm »
Deleting an arbitrary selection is undoable as a unit. Undo re-adds the tiles. They aren't selected after getting added. Should they be selected? This will be a doable but nontrivial task; ideally, we'll decide later.

I would personally think it desirable but non-critical for them to be selected.

But how? Complex scenario: You drag 3 tiles, and mid-motion, hit the hotkey to rotate them. Should this generate 1 undoable, or 3 undoables (move, rotate, move)? I'm leaning towards 3.

I would not have expected this situation to be possible in the first place - I would expect the rotate either terminates, or is ignored during, the drag. To be fair, I wouldn't even attempt it in the first place.

I should note that I tend to follow the opposite workflow of this, though. I would likely be using the clickable buttons to rotate / etc, while using the keyboard to move pieces. This is due to the keyboard movement being more precise. I may occasionally move a piece a long distance with the mouse; I would not try to rotate / etc it while doing this (I'd most likely do so afterwards, if I were going to do so at all, though I'm not 100% sure it would never be "before" - I am sure it would not be "during"), and would almost certianly follow up with some keyboard movement afterwards to get it to the exact desired spot.

Make the tile moving non-undoable, i.e., cut this half-baked feature. Undoable moving can happen in a future version. I haven't released in months, it's time to release something.

I would consider undoing a move to be almost as important, perhaps even more so, than undoing a delete. Accidental moves, or accidentally including something in a move, etc, are far easier to do than an accidental delete, in my experience.

Empty the undo stack whenever we do something yet non-undoable in the editor. This will keep the undoing always consistent. No more crashes from detected inconsistency.

Unsure about this. Perhaps valid if the intent is "this will never be undoable", though perhaps preferable there is to make the thing in question outside of Undo / Redo altogether, rather than making it clear the stack. For things that will be undoable in the future, perhaps instead of clearing the stack, it should give a warning when the user attempts to undo, then allow them to continue undoing from the last undoable action?

General Discussion / Re: Armani's Blog
« on: July 09, 2020, 07:47:54 pm »
not sure if it's actually 100% correct to be honest though because I used Google translate!

It probably isn't, unless you translated from Japanese. Machine translation into / from Japanese and Korean, except for between each other, tends to be good enough to understand what's being said but usually quite far from accurate. Although maybe they've gotten better in the last few years.

General Discussion / Re: Armani's Blog
« on: July 06, 2020, 08:36:00 pm »
It took more than an hour to write this post so far and I know there are many grammatical errors and incorrect expressions. I have no idea how to improve my English but I will try my hardest anyway. I have memorized a lot of English vocabularies so far, so I have no problem in reading and listening English but speaking and writing English is too hard for me. Do you have any good idea?

나의 한국어보다 훨씬 좋아요. ^^

Learning a second language, unless you learn it as a child, is a very difficult thing - I say this having learnt two myself (the other one is Japanese). I've also done some basic study of language teaching. From what I can gather, between that study and my own experience - simply trying to use it as much as you can is the best way. With that being said: Always remember, the point of a language is to convey information. Unless you're taking a test, what's most important isn't "is my grammar perfect?", it's "can people understand me?" - and so far, I haven't seen any of your posts that are hard to understand.

In old-formats, a pack could come with tilesets and music built into it (in the NXP file). Either could also be put into the global installation. To do this in old formats, the creator must have released the music / styles standalone; they could not be extracted from an NXP file (or rather: no tool to do this was provided; someone with sufficient coding ability could of course extract it).

In new formats, both are always globally installed and there is no "prevent anyone else from using this" mechanism other than asking nicely.

NeoLemmix Main / Re: Plans for V12.10.0
« on: July 05, 2020, 04:20:53 am »
No luck on that one. I don't have the faintest clue what I'm looking for in this case.

In the case of the level data, I knew from previous discussions that Amiga uses the same LVL format as DOS. I also figured, given the age of the game, that it probably stores the decompressed LVL data in memory verbatim, so I simply searched for something I knew would be in the LVL file (specifically, the level's title) to locate where in memory it was. Figuring out the rest from there was just a matter of knowing the LVL file format. In this case, I neither know the format of the graphics nor any "known data" that I can use to look for.

On the other hand, when I feel up to it I can very likely extract the DOS version's one from MAIN.DAT, as the format for that is well documented.

Just to confirm: You are clicking "Add requirement" after selecting the condition / quantity, correct?

I spotted this as a potentially unintuitive aspect of the UI, but otherwise can't reproduce this, even using that exact level.

Site Discussion / Re: [SUG][FORUM] Native dark mode
« on: July 03, 2020, 08:29:53 pm »
It's technically feasible in the sense of, SMF supports custom themes and this could be done by creating one.

The issue is that I'm not really sure where to start on doing so, nor do I see it as anywhere near a top priority. However, if someone else is willing to create one (or find an existing suitable one and make the necessary customizations to Lemmings-ize it), I'm more than happy for it to be added to the site.

I'm not sure what the proper terms for each actually are, but there's "how many bits is each sample made up of?" - this is the 8 bit, or 16 bit, or 24 bit. Then there's - for compressed audio formats (you could measure this for uncompressed ones too, but it's kinda meaningless there except in terms of calculating file sizes from quality / length or vice versa) - "how many bits or bytes are used for each second of audio?"

In uncompressed audio, each sample really is equivalent to a pixel. The sample is a single value, which could be an 8 bit value (-128 to 127; or 0 to 255), a 16 bit value (-32768 to 32767), a 24 bit value (-2^23 to 2^23-1). In for example a 44100Hz audio file, one second of mono audio would be made up of 44100 of these samples (double this for stereo - one for each speaker - etc). Similar to how if you had an image file where 44100 pixels would make up 1 metre when translated into physical space, one metre would - of course - be made up of 44100 pixels. In such a case, the bit rate would just be (sample depth) * (frequency) * (channels) - for 44100Hz, 16 bit, 2 channels (stereo) that'd be 44100 * 16 * 2 = 1411200 bits per second (~1400kbit, or about 175KB for every second of audio).

In compressed audio, this gets reduced to the target bit rate - whether this is a hard and fast "always hit it exactly" or just a "use it as a guideline" depends on the specific format - by using a combination of data compression algorithms, and reducing the quality to make the data more compressible (for example - let's say we have a sequence of samples "100, -100, 99, -101, 99, -99" - changing this to "100, -100, 100, -100, 100, -100" is almost indistinguishable to the human ear, but can compress much better). This is why, even at equivalent bit depth and frequency, a lower bit rate compressed audio file sounds worse - and why, other than by changing those factors, you can't get a lower bitrate on uncompressed audio.

I've had to learn / figure out a lot of this while working on Tiel Attack, as a significant portion of its sound code is custom. In particular, the data files only contain a list of notes + durations + "sound type" + loop points for the music, with the game itself generating actual audio data from this. (The sound effects on the other hand are prerecorded, though due to the exact implementation Tiel Attack does work with their data at a relatively low level.)

Okay so, it seems to be quite inconsistent as to whether or not this occurs, but I seem to have found steps that consistently reproduce it for me - and have confirmed it still happens in V1.25 (the experimental).

If I create a new Marble level, and first select the background, then add two terrain pieces, then an object, and then open "Just Walk" from LPI, it seems to consistently trigger this issue. This is the only sequence of steps, so far, that has managed to reproduce the issue for me - including that opening other Dirt levels doesn't seem to trigger it.

EDIT: Okay, I think I've found the key detail that was missing. There is an additional requirement for this bug to trigger: The level with the background, and the level that you load, must be the same size (or at least the same width - haven't tested differing heights yet). EDIT 2: Yes, it applies to height as well. Expected as much, but always good to test.

allows multiple packs ... to share music.

This is actually a big part of why music isn't stored with packs.

It's known that this is possible. While this is definitely a "don't do this", I kind of feel it's one of those ones that isn't worth making a special effort to prevent. Absolute paths have no explicit prevention either - it's simply that the way the code is written in general (in particular, that upon startup NeoLemmix figures out the absolute path of the NL folder, and it looks for music files by combining this path + "Music" + the music name) doesn't work with an absolute path. In fact, relative paths working was initially an unintended side effect too - then when I realised the usefulness of it, I instead decided to make it an explicitly supported feature.


Drawn on my Toshiba Portege Z10T using Krita. Layers used heavily, but only two brushes at their default size: one of the erasers, and one of the pencils.

The two girls are a lix and a lemmina.

To those wondering what piece grouping is: it basically means you can select a few terrain pieces in the editor, "group" them, and they now act as a single piece. This can be useful when you've created a complex structure out of smaller pieces, and want to ensure it's only moved as a large group, not as individual components. It can also be useful when trying to do particularly tricky stuff with erasers.

Note that a piece group cannot mix steel and non-steel (but erasers are exempt from this rule). It must be either all steel, or all non-steel. Similarly, it won't become a mix of one-way-capable and not-one-way-capable terrain - there's only a single one-way flag for the whole group. Keep these limitations in mind.

Okay so, I've often mentioned the reason terrain grouping is missing in NL is because the editor's file parsing code is written in a way that could lead to it being unable to load perfectly-valid level files that use terrain grouping, depending on how they're structured.

I've finally gotten around to writing new file parsing code for it that averts this, and as such, been able to enable terrain grouping (the underlying functionality of which has been there for ages - it's just loading and saving that was missing).

However, as this is a very major change - and I don't know how well-tested the grouping feature is (although it's Nepster's code, so I'd guess probably pretty well tested) - I feel an experimental build is a must here.

So - here you go. If you want to try out piece grouping, or just help test in general, download this editor. Save often, and be prepared for the risk of data loss. If a file does seem to have data loss when you load it, try loading it in the old editor or in NL - if it works fine there, it could be a bug in the new version's loading code.


If an existing level isn't loading properly, run it through Cleanse Levels. When writing the new level parsing code, I have not bothered to maintain backwards compatibility for pre-V12.7 NXLV keywords. So, any levels that predate this won't open.

And to be clear - you do NOT need a new version of NeoLemmix to go with this. NeoLemmix itself has supported piece grouping for a while now - it just never had the corresponding editor support. Use this experimental editor together with the current stable version of NeoLemmix.

NeoLemmix Main / Re: NeoLemmix V12.9.2, Editor V1.24 Released
« on: July 02, 2020, 01:57:14 am »
Uploaded editor V1.24.

This fixes some issues relating to the level ID, as well as a bug relating to deleting talismans.

(For those of you following Discord - this update does not yet enable piece grouping. That should be coming, now, but it isn't here yet.)

Okay so - deleting is purely a matter of the list not being updated to reflect the deletion. It is in fact deleted, but the list doesn't get updated until something else causes the talisman list to be regenerated (such as editing a talisman - even if you cancel out of it).

I can't reproduce your issue with not being able to add the basher restriction.

Pages: [1] 2 3 ... 727