See also: This topic on the NX1 board.

So, it's already been decided that one-way arrows will no longer be considered objects as such, but will instead be implemented more similarly to steel areas (already an option in NX1, but generally the less-recommended option due to that, among other factors, no animation support exists for such one-way arrows).

Some things I'm wanting to consider are:

How to handle them graphically? There'll be a "default" graphic for them (so, graphic sets aren't obligated to contain graphics for them), with the optino for a graphic set to override it with custom ones; that much is established. The questions are - should support for animation be included, or should they at most move (similar to how most current ones do) - this would require a redesign in a few graphic sets that don't simply give them continous movement in one direction (eg. psychedelic, which has constant arrows which light up periodically; or Lab or Clockwork, where the arrows oscillate backwards and forwards rather than continously advacing). Supporting both is of course an option. EDIT: While I'm not ruling out offering the option (for graphic set designers) to just provide one graphic and have that move, it's not going to be enforced; full animation support will also be retained. (As such, this could simply be some kind of "autogenerate animation" option in the editor, rather than an actual feature of the game.)

Should changes be made to certain graphic sets where currently one-way arrows move in a different direction to how they point? This - in particular with the Fire graphic set, where all one-way arrows move in the same direction (towards the left), has been criticized in the past.

What about positioning of the graphics? Should it essentially function like a huge tiling of one-way arrows over the whole level (perhaps with an offset rather than always starting at 0,0), only displayed in regions where they're actually used? Or should it be more similar to current, where they're offset from the top-left corner of the one way area - which would mean more difficulty for level designers, but could look tidier in some cases when multiple one-way areas are near each other (especially if they're in the same direction)?

EDIT: Another thought - should the option exist (for the user) to ignore a graphic set's custom one-way arrows (and most likely, pickup skills too, though this could be a seperate option) in favor of always using the generic ones?


Any other comments on this are welcome as well, of course.

While running backups of the site, I'm noticing that there are some very large private message attachments, in some cases from a very long time ago, still on the server. (If I'm not mistaken, they're only removed when everyone has deleted the message - including the sender if they've saved it in their Sent Items).

These do add to site storage costs, and seeing as they're unlikely to be downloaded again (compared to those in regular posts, which new users might want to download), I'm considering whether to implement a system where PM attachments are removed from the server if:
- They've been downloaded at least once
- They haven't been downloaded within the last 30 days (but I do need to check whether SMF actually tracks this; I don't think it does)
- They've over a certain size, probably around 200KB (as small files such as levels have a negligable impact on storage costs; I'm referring to the larger, multi-MB files here)

This would not affect the messages themself, only the attachment. I could possibly also look into having the site send a warning message before this happens, if people are worried about possibly-important attachments they may have in their older messages.

(One alternative that people may suggest is limiting the total size of PM attachments a single user can have; I don't like this idea, as I'm perfectly fine with someone having multiple large attachments in their inbox/outbox; if they're there because they're actually being sent to the person, and not just sitting there, taking up space, from a PM several months ago.)

Implementing such a measure could also mean I'd be more comfortable with increasing the size limit a bit; this has been mentioned in the past.

Just to be clear, no such system has been implemented yet, and it will not be implemented without a warning significantly in advance. It's just something I'm considering.

So - something that I believe can be done in (Super)Lemmini and Lix. When the user has more screen space available, rather than using it to zoom and/or display higher-resolution graphics, should there be an option to use it to display a larger part of the playing area (in the case of a level that's not large enough to make use of this, it could either fall back to zooming it, or place a border around it)?

I don't see much downside to such an option, so the only real question is how many people think they'd use it.

This topic is for discussion of the levels, feedback, posting replays, etc. For creators wishing to post updates, or if you're looking for the latest updates, please check this topic instead.

Alright, so we didn't get so many entries this time - but nonetheless, we have some, so let's start playing!

All of the submissions in this contest are for NeoLemmix. The entries are:

<V3> "Quartic Egress" by bsmith
<V4> "Stonecrest Bay" by Crane
<V1> "The bURns of DrEAD" by GigaLem
<V1> "Lemmings in Unison" by IchoTolot

NOTES:
IchoTolot's level has a custom graphic set (you might already have this if you have the L2 / L3 Styles Pack) which is included in the download. It also has a custom music file; as this is a large file I have uploaded it seperately. If you do not wish to download the music file, you will need to modify the level file so that it does not use a custom track (set the music number to zero). These should be placed in the same folder as NeoCustLemmix (EDIT: Due to a bug, the music file needs to be placed in the same folder as the level file, rather than the same folder as NeoCustLemmix itself. This will be fixed in the V1.35n-D update. The graphic set should be placed in the same folder as NeoCustLemmix.)

The levels are attached in a zipped file. To play them in NeoCustLemmix, press F6 (load single level) on the title screen and select the level.


Update phase will end at whichever comes last - 9th Oct 2015 2:07 PM, or 72 hours since the last update.

As a reminder, the available prizes are:
- US $5.00
- One month's advertising on the forum's news ticker
- Your choice of rules for the next contest

Attachment updated 10/6/15 02:25 PM

This topic is for entrants to post updates to their levels only. Any posts in this topic, other than for the purpose of entrants posting updates to their levels, will be deleted. If you are simply wanting to discuss the levels, please use this topic instead.

Please follow these rules when submitting updates:

1. Please don't leave multiple versions of your levels in this topic. When posting a new update, remove the attachment from the old post.
2. Don't edit your old post to attach the new update, even if there have been no other updates since. Make a new post for a new update.
3. Any posts that have had the attachments removed (due to being superceeded by a new update), I'll delete eventually. (Any other mod/admin is also free to do this.) So don't leave any important details in them (or if you must do so, copy the details into the newer post).

These won't be enforced as strictly as the "official" rules of the contests; but I do still ask that you follow them to keep things simple for me updating the entries, as well as others trying to find the latest updates.

Note: Update phase has now ended; no further updates may be made.

Final decision: No; not enough interest for it to be worthwhile.

So - while I'm sure the majority of users prefer to stick to a mouse - I'm wondering if there's any interest in having gamepad support as well? And if so, what suggestions you have for how it should work?

With this sub-forum getting larger and larger, I think it's about time to have a single post briefly listing everything that's been discussed; both for easy reference for anyone who's interested, and for me myself to easily keep track of things in one place. So... yeah, here it is. To keep this organised, I'll post the lists / etc in replies sorted by category.

Semi-final decision: Sticking with the original plan, of physics remaining at 1x, with an option for rendering the graphics at 2x (and possibly even higher in the future). This will remain open for discussion, but it's probably not likely to change, unless someone comes up with a really good argument for it.

So, something that was asked about recently - and I had considered this idea to some degree - was a full-blown change to physics based on high-resolution graphics. Currently, the plan is to support high-res display, but still with underlying low-res-based physics.

Some thoughts on this:

Consistency between resolutions
If the physics were to be changed to high-res-based, then low-res would not be a display option. There'd simply be no point in it; it would mean the full detail isn't visible, and I don't think there's many (if any) potential users whose PCs couldn't handle at least 640x400 resolution. However, where this could be a problem is in the event of a future decision to support even higher resolution graphics. I would think that display at a non-integer multiple of the physics resolution would be somewhat unusual and user-unfriendly; meaning that any step up from high-res (2x) physics would have to be to 4x; which would mean a minimum screen size of 1280x800; beyond what some people here actualy use. Whereas, 3x (960x600) is more viable as an option, but would likely need 1x (or, of course, 3x) for the physics resolution in order to really be practical.

On the flipside, it is somewhat questionable whether or not resolutions beyond 2x are likely to be supported. Currently, none of the clones we use go beyond that; so we don't exactly have 3x or 4x versions of tiles, meaning they'd need to be made. The majority of custom graphic sets are either 1x resolution (Cheapo, NeoLemmix) or 2x resolution (Lemmini sets). And creating higher-resolution graphic sets would end up being more work; so perhaps there's no real need to consider supporting beyond 2x.

Backwards compatibility
Other engines (in paritcular Lemmini; but also WinLemm and Lix) have shown that existing levels can work when put into a high-res context. But of course, there's always the occasional level that gets broken by it. One of the reasons for sticking to 1x-based physics, therefore, was to ensure minimal problems for existing NeoLemmix content. However, since a lot of other physics changes/fixes are being suggested for V2.00n; there may be issues anyway, in which case it might make more sense to change the physics resolution at the same time.

Graphic set design
As touched on above, lower-resolution graphic sets are generally easier to make. Only supporting high-res may lead to less new graphic sets being made; compare the number of Lemmini sets to the number of Cheapo sets, for example. With that being said, there isn't really anything preventing someone from designing for low-res, then simply doubling the size - it might not look quite as neat; certianly I would want to put a bit more effort than that into my own sets, but the point is that the option is there.

Details of new physics
Any new physics would of course still be as closely based as possible on the existing ones, but adapted for high-res. But even with minimal changes, this still means (a) coming up with the exact details of the new implementation, and (b) players getting used to them, all over again. For that reason, non-change may be preferable.

Zooming
This could be a significant one. If high-res is the "base" resolution, then just a 2x zoom would need 1280x800 of screen space. Which comes back to similar issues as with supporting even higher resolutions in the future; although in this regard it's not as big a deal, as 1.5x zoom doesn't strike me as being as prone to issues as actual 1.5x resolution (relative to hi-res).

Any thoughts here? Would you rather see NX2 abandon low-res altogether, or would you prefer low-res-based physics simply with an option for high-res display? And on that note, if we lean towards abandoning low-res - the next question is whether to maybe make the jump directly to 3x (personally I'm somewhat against this idea due to the effort that'd be needed in regards to making 3x resolution versions of the graphic sets, but if some people were willing to help out with that, at least for the official sets (while I could take care of the Lemmings Plus ones), I could consider it)? The other downside of such an option though, being that all other current engines / notable past engines run at either 1x (Lemmix, NX1, Cheapo) or 2x (Lemmini, Lix); so going to 3x may present problems when trying to convert content, especially from engines that natively use 2x. This is something I'd like to get decided on fairly soon, as I'm probably going to be doing the graphic set code very soon - which is something where this decision will matter.

Just to be clear - this does not mean that importing low-res NX1 graphic sets won't be supported (although with that being said, most non-official NX1 graphic sets other than those I made myself are conversions from Lemmini anyway, which means they're technically high-res graphic sets already, which NX1 simply scales down at runtime - the files themself contain the full high-res images; as for my own graphic sets, I'll take care of making high-res versions of those).


For the reasons I mentioned above about graphic assets, I'm not too keen on the "go straight to 3x" idea, but as I mentioned - if there's a lot of interest in this, and some people would be willing to help out with the graphic sets (doesn't have to be right away, I'd rather wait until closer to release time before getting anyone else to do anything), it's a viable option. Between the other two options, I'm not entirely sure which idea I prefer - certianly, everything running at 2x would be easier to implement (apart from having to come up with physics for high-res), but even that would obviously entail changes from NX1 (which uses 1x for both the display and the physics).

I guess now that Doomsday Lemmings II's demo has been out for a while, and as such you've all had a chance to experience the Ghosts gimmick, it's about time I started allowing use of it in custom levels.

Note - before using it, please be aware of:

> the ghost-digger bug (see the Player Bugs topic). This is going to be fixed in a near-future update (not the big V2.00n update, a V1.35n-D update). If you plan to make levels that involve the kind of situation that triggers this bug, please be prepared to re-test this level after the update to ensure it still works as intended (it should unless very precise timing is required, but you never know).
> that from V1.35n-D onwards, ghosts will not ignore one-way walls

In future updates to the editor, I'll make the ghost gimmick selectable without any extra steps. In the current update, it can already be selected but it's a hidden option. To reveal it, follow these steps:

1. Open the Gimmicks window
2. Click "Activate this gimmick" (it doesn't matter what gimmick you have selected at this point)
3. Press Shift+F5, then Ctrl+F5, then Shift+F5 again. A counter should appear that starts at 1 and increases to 3 as you press these keys.
1. Update to Editor V1.35n-E or higher.
2. Once that's done, Ghosts (and Ghosts-on-death), as well as a lot of unused placeholder gimmicks, will be added to the list of selectable gimmicks.
3. Marking a lemming as a ghost is done the same way as zombies / permanent skills; the number to use is 128. And yes, you can combine this with various permanent skills; and yes, you can apply it to entrances rather than pre-placed lemmings.

Ghosts and zombies can co-exist in the same level (one of the DDII demo levels, "Guardian Angels", already showed this), but a single lemming cannot be both a ghost and a zombie. For this reason, "Ghosts on death" and "Zombies on death" cannot both apply in the same level - IIRC, zombies-on-death takes priority in this case, but I'm not 100% sure.

The signs used to indicate "ghosts on death" and "zombies on death" in levels are additions to the Horror tileset; they've been in there for a while now so if your version of the editor / player aren't new enough to have those in the tileset, they're probably not new enough to support the gimmicks themself anyway. In other levels, you'll need to make VGASPECs for the signs (or modify the graphic sets themself).

With a major rewrite, which even if designed to be identical is probably a good time to re-test packs before releasing them on the new engine, I'm wondering if some inconsistent physics details should be tidied up?

In recent times, I've tried to shy away from major changes where possible. A few have been unavoidable to fix otherwise-exploitable situations, as well as others that relate to very recently introduced behaviour so aren't likely to break a lot of levels (eg. the fix to ghost digger + normal walker interaction), but for the most part, these have become rarer and rarer recently.

Some of the still-existing ones are, at least as far as NX1 is concerned, remaining unfixed for now not so much because they shouldn't be fixed, but because the impact on existing levels - either in terms of invalidating existing solutions, or opening up new backroutes - is disproportionate to the severity of the bug itself. One example would be the bug that carried over from Lemmix and went unnoticed all this time, of that traps (and by extensions, teleporters, which function very similarly to traps apart from relocating the lemming instead of removing it) skip the first frame of their animations when triggered - while this is probably not how they should behave, it is how they always have behaved in NeoLemmix so far, and thus levels have at least been designed (even if not conciously so) with this in mind. Another recently-noticed one which I'm opting not to fix for now, is closely related to the trick (whether or not it counts as a glitch is debatable; NeoLemmix has never considered it to be one) of how in some cases - either via dropping in from overhead, or coming up from underneath on a very steep slope - a lemming can slip by a blocker unaffected. While this is acceptable and even generally considered to make sense in the case of a blocker, a similar situation occurs with zombies, where a non-zombie lemming is placed on a slope as a blocker, and a zombie comes down towards it from above - the zombie will turn around, but will not infect the blocker.

As mentioned before, these all fall into the category of "bugs that are better left unfixed due to the potential impact on existing NeoLemmix levels being more severe than the exploitability or illogical-ness of the bug". But, should these kind of things be tidied up for NX2's initial release - which is probably a very good time to re-test any content anyway? Or should it be left until a later revision (if touched at all), which means further checking of the content - something that cannot be relied on as much with a "one program loading data files" setup, compared to in NX1 where (at least in the case of larger packs made with Flexi, which has been the dominant method of content distribution so far) a pack is tied to a specific EXE version (and thus a specific set of physics) until / unless the creator updates it to a new version, at which point they have presumably tested it with the new version?

(On the other hand, do keep in mind that NX2 will likely have more powerful tools than NX1 for checking packs' working with newer versions, such as mass replay testing.)

Final decision on "Disable direct drop": The option will remain.
There is no final decision yet on "Timed bombers"

Currently, NeoLemmix allows for creator's choice in regards to these factors on custom NeoLemmix packs. I'm wondering whether people feel these options should remain available in V2.00n, or if they're considered obsolete now.

In general, virtually all NeoLemmix content does not use the timed bombers option. The only exception I can think of off-hand is GeoffLems, which was originally a traditional Lemmix pack. On the other hand, I believe the "disable direct drop" option is a bit more frequently used, and unlike the timed bombers option, was specifically requested. However, either of these options does mean some degree of inconsistency between packs with game physics - of course, with that being said, it can always be displayed in a pack's info what the settings are, so the player knows in advance. It could also be argued that Cheapo Mode is a precedent for allowing such differences, which certianly is nessecary to properly support Cheapo content without requiring extensive modifications (especially because of the fall distance being significantly different).

What are your thoughts on these?

(Note: The "timed bombers" option actually affects Stoners too, but I'm not aware of any packs that use Stoners *and* have the timed bombers option on. Thus it's primarily thought of as being associated with bombers.)

Please see the general contest rules here.

Contest #7

For this contest, your goal is to make a level that has at least four exits. For an exit to count towards this requirement, it must be possible to save at least one lemming with (but this can be on seperate attempts; it doesn't have to be possible to reach all of them in a single play).

Initial Submission Deadline: 25th September 2015 (subject to general rule 4b)

The prizes available for this contest are:
- US$5.00 ($7.50 if at least 7 entries)
- One month's advertising on the forum's news ticker (month and a half if at least 7 entries)
- Your choice for the next contest's rules

---

Entries received so far: 4
bsmith
Crane
GigaLem
IchoTolot

Final decision: No content protection features. If it's released, it's free to be used (of course, the expectation of respecting authors' wishes still exist; NeoLemmix simply will not try to enforce this in any way, whether intentionally or as a side effect of something else).

Prompted by an IRC discussion, I'd like to ask how people feel about being able to protect their content from use outside of simply playing it.

In the past, NeoLemmix offered an encryption option for custom content. This is no longer usable for content, and the old encryption code is now used only on the savegame file. However, the primary form of distribution for NeoLemmix content now is everything-in-one EXEs, which have a similar ultimate effect of allowing other users to play the content, but not to, say, open the levels in the editor, or use any graphic sets, etc. In some cases, non-release or delayed release of this content has been used; for example with the Lemmings Plus IV graphic sets, where one of them was released for general use before release; another around the time of the game's release, and the last two not being made available until a while later.

By comparison, other engines don't really offer any such equivalent. Lemmix does have the possibility of making an all-in-one EXE, but unlike with NeoLemmix which has the dedicated Flexi Toolkit, it's quite a mission to actually do so, and as such there's only four cases I know of where this has been done - the pre-NeoLemmix versions of Lemmings Plus I, II and II Bonus Pack (which have now been replaced with NeoLemmix versions), and cLemmings Ultimate Edition. Lemmini, SuperLemmini and Lix offer nothing of the sort; any distributed content can be used by anyone in any way they like. (To be fair, someone determined enough could extract the content from a NeoLemmix all-in-one EXE if they really wanted; it's just not as straightforward as in other engines where the file is right there and can be opened with the editor / etc.)

So my question is - do people feel that this is an important feature of NeoLemmix? Or is it mainly used because "that's just what happens when the most common method of distributing content is used", without people really caring too much about this? I ask this because, I absolutely will preserve such a capability in some way in NX2 if there's demand for it, but if people aren't too interested, I probably won't do so.

Keep in mind that any such measures wouldn't be overly hard to defeat, especially given that NX2's source code will be available, so someone technically-capable enough could either examine that to work out what triggers such measures and modify the files to get around it, or alternatively, just produce a modified copy that does not comply with restrictions. But it might be enough of a deterrent for people to think it's not worth bothering, and also, generally speaking, the kind of people who'd be likely to want to bypass such restrictions in order to actually try and use the content are also likely to be the kind of people who wouldn't be able to work out how to do so.

Section 1 - Rules concerning entering levels
a. For each contest, each user is limited to one entry for each possible entry criteria.
b. Submissions must be made via a private message to the user hosting the contest during the initial submission phase, or in the update topic during the playing phase.
c. A level is not eligible if it has had a prior public release, even if that was on a different engine. Small-scale private releases (such as asking one or two people to test your level) will be tolerated. It is allowed to include the level in a public release after the contest's playing phase has started.
d. The user hosting the contest may enter a level.
e. Any user caught attempting to manipulate voting or otherwise cheat will be disqualified from the contest, and may be banned from entering future contests. For the avoidance of doubt, voting for your own level is not considered cheating.
f. The user hosting the contest has the final say on whether or not a level meets the contest criteria. If your level is determined not to meet the criteria, you may modify it so that it does then resubmit it, or submit a different level, if you like.
g. If your level is acceptable according to the letter of the contest's criteria, the host may still reject it if they feel it goes against the spirit of the criteria; or in other words, don't use loopholes in the contest's criteria.
h. If your level uses any graphic sets, music, or so on that are not included by default with the engine you're using or capable of being downloaded automatically by it, you must include a link to, or a copy of, said content with your submission.
i. A level that statisfies multiple rules can only be submittet to one. The author can choose which one though.
j. Levels for different rules need to be completely different levels and not just minor modifications of each other (if not the current ruleset strictly requires this).

Section 2 - Rules concerning updating submitted levels
a. Any updates prior to the end of the creation phase should be submitted via private message to the user hosting the contest.
b. Any updates during the playing phase should be submitted by posting them in a dedicated updates topic as a new post (not as an edit to a previous post). Posting updates to more than one level in the same post is acceptable, provided that they're both posted at the same time (not editing the post later to add a second one).
c. The newest version of your level at the end of the submission phase will be considered V1 of the level, with the first update being V2, the second V3, and so on.
d. If an update to the level causes the level to no longer comply with the contest's criteria, that update will be ignored.
e. The deadline for submitting updates will be slightly earlier than the end of the playing phase and start of the voting phase, to give some time for other users to get and play the "finalized" versions of the levels.
f. Failure to follow the guidelines on how to post an update will result in that update being rejected. Repeatedly doing so may result in the level being disqualified altogether.

Section 3 - Rules concerning allowed engines
a. Submitted levels must be for either NeoLemmix or Lix.
b. <no longer relevant as DOS / Lemmix is no longer allowed>
c. In the case of Lix levels, they should be single-player levels.
d. In either case, the levels should work with the stable version of the respective engine at the time of the contest's announcement, or a newer stable version.
e. For the avoidance of doubt, this means levels relying on experimental NeoLemmix features (unless the contest specifically states otherwise) are not allowed.

Section 4 - Rules concerning deadlines
a. All deadline dates and times are in UTC. If you are using the default forum settings, this is the same as the time displayed in the top-right of the page.
b. The deadline for initial submissions will automatically be extended if nessecary so that it is not less than 72 hours from the time the most recently-submitted level was entered. This no longer happens once a contest has at least six entries (the 6th entry itself can still extend the deadline, but no entries after that can).
c. The deadline for level updates will automatically be extended if nessecary so that it is never less than 72 hours from the time the most recently-updated level was last updated.
d. The contest will be cancelled if less than three entries have been received by the time of the initial submission deadline.

Section 6 - Rules concerning determining the winner
a. Contest winners are determined via a vote, which is open to all users to vote in (including those who did not enter the contest).
b. Voting is done in multiple rounds; the exact arrangement is at the discretion of the user hosting the contest, but the general formula is that the voting takes place for all criterias at the same time. Only the level with the most votes in each rule moves on. Each person only gets 1 vote for each criteria. Dertermining the top level in a criteria might result in a tiebreaker. The top 3 then consists of the top level of reach rule. The placement is then determined in a single voting round. Each person only gets 1 vote. A tie here simply results in a tied 1st or 2nd place.
c. There is no specifically designated criteria to consider when voting; it is simply a matter of which level(s) you like the most.
d. For the avoidance of doubt, the number of allowed votes is a maximum, not an exact number; and it is perfectly fine to vote for a smaller number of levels.

Section 7 - Rules concerning prizes
a. Unless the contest in question states otherwise, the authors of the top three levels will each get to choose a criteria for the next contest. If an author got multiple levels in the top three they get to choose multiple rules accordingly.
b. If the contest does offer multiple prizes, then the same prize cannot be chosen twice unless stated otherwise. In the event of an overlap between chosen prizes, the higher-placing winner gets first pick provided they choose within 48 hours of the winning being announced; after this it is strictly "first in, first served".
c. Any monetary prizes are payable via PayPal; or if you live in New Zealand, bank transfer. Other payment methods may also be considered upon request, such as Bitcoin, direct donation to a charity, or so on.
d. Prizes may not be put on hold for later use, except prizes of advertisement on the forum's news ticker. If you have not supplied the details nessecary to claim your prize (eg. a PayPal address for a monetary prize) within one month of choosing it; or have not chosen a prize at all within two weeks of your win being announced; it is forfeited.
e. If the user hosting the contest wins, they do not get a prize. Unless it is choosing the criteria for the next contest or the contest offered multiple prizes, their prize is passed on to second place.
f. If a prize can be put on hold, it must be claimed within 12 months, or else it is forfeited. This does not apply to prizes that were won before this rule was added, even if they weren't chosen until afterwards.

Section 8 - Miscellaneous rules
a. Although this will be avoided as much as possible, the host of a contest may choose to add / modify / remove specific prize options, or even cancel the contest altogether, for any reason, at any time.
b. This is not a legal agreement. The contests are for fun, the prizes are a bonus, and entry into the contest does not create any kind of contract that ensures you a prize if you win.
c. In the case that the rules of an individual contest contradict these general rules, the contest's specific rules override.
d. No discussion of the contest levels is allowed anywhere on the site, except via private message, during the voting phase. This does not apply to any levels which have been eliminated from the voting.
e. Discussion of contest levels during the voting phase via private message should be kept to a minimum, generally only for purposes such as sending solution replays to the creator.

Our 6th contest is ended, and with it, we have our winners!

1st Place: Geoffster's "Parking Garage"
Prize: Choosing next contest's rules

2nd Place: Crane's "Mind the gap!"
Prize: US $12.50

Congratulations to the winners, and in particular, congratulations to Geoffster for winning on their very first time entering a contest! This was definitely a tough one to choose my votes (at least for me), since there were a lot of great levels here!

A new contest will be put up once Geoffster's picked some rules (and I've given them the okay).

So - this is something that might actually end up being developed fairly soon, so let's discuss what it should be like.

Would you like to see something similar to the existing (DOS L1-like) menu, but expanded to support better level selection and multiple games (as well as non-game content; ie: small CustLemm-type level packs, and even individual levels)? Or would you prefer a more typical Windows GUI type menu? Or somewhere inbetween, or something else entirely?

Should packs (especially full games) be listed with a logo, or just a text name? And what about ranks within those games?

And, anything else in general anyone would like to suggest for the main menus (by this I mean not just the title screen, but also configuration screen; basically, everything in the player outside of preview/postview screens and actual gameplay).

Okay, you all know how this works by now.

Voting structure will be as follows:

Round 1: 4 votes per user, 4 levels qualify
Round 2: 2 votes per user, 2 levels qualify
Round 3: 1 vote per user, determines the winner

If there's a need for a tiebreaker, the following rule will apply (with some discretion, in case the option here wouldn't be feasible for some reason):
- If allowing all the tied levels to the next round would mean the qualifying limit is exceeded by only one level, then that is what will happen.
- If preventing all of the tied levels from advancing would mean the number falls short of the qualifying limit by only one level, then that is what will happen.
- Otherwise, a tiebreaker mini-round will be held, the setup of which will be decided based on the qualifying limit and the number of levels it'd be exceeded by.

(This does not apply if the tied levels have zero votes (eg. in the first round, if only 3 levels receive any votes at all). In this case, the tied levels are prevented from advancing; or in other words, no matter what, a level will not advance or be entered into a tiebreaker if it has zero votes, it'll just be eliminated.)

As always, the voting is simply a matter of which levels you liked the most - it's entirely up to you how you decide that. And it is perfectly permissible to vote for less levels than the vote limit - it's a limit, not an exact number.

Remember, discussion of the contest levels anywhere on the site (except via PM) is not allowed while voting is in progress. This includes posting replays.

So, in regard to musics... we all know there's several versions of a lot of tracks out there, especially the Orig ones. And we probably all have our favorite versions - which might not be the same for every track (eg. some people might prefer the Amiga version of Track A, but the DOS version of Track B and the Master System version of Track C).

With this in mind, I'm considering allowing multiple versions of the same track to be installed, and allowing the user to select their preferred version, which would be played on any level that uses that music (whether as a result of the general rotation, or because the level in question specifically is set to that track).

The current way I envision this working is that, for each track (not just each set, but each individual track), the user can choose their preferred version out of all installed versions of that track. They'll also have an option of how strictly to prefer that track - either "Allow a level to override the version selection", or "Force this version".

What's that mean? Well - at the same time, levels could either specify in general "just use this track, whatever version the user prefers", or "use a specific version of this track if available". So the user option would affect whether or not the level can override their preferred version.

So let's use "cancan" (from "orig") as an example. Let's say there's three versions - Amiga, DOS and SMS (of course there's way more than this, but just for the sake of an example...). The user in question has the Amiga and DOS versions installed, but not the SMS versions.

Case 1
User has "Amiga" set as their preference, but has not selected to outright force that version.
Level specifies "orig.cancan" as the music but doesn't specify any version of it to play.
> The level plays the Amiga version of orig's "cancan".

Case 2
User has "Amiga" set as their preference, but has not selected to outright force that version.
Level specifies "orig.cancan" as the music, and specifies to play the DOS version.
> The level plays the DOS version of orig's "cancan".

Case 3
User has "Amiga" set as their preference, and has selected to outright force that version.
Level specifies "orig.cancan" as the music, and specifies to play the DOS version.
> The level plays the Amiga version of orig's "cancan", since the user has chosen to override the level's version specification.

Case 4
User has "Amiga" set as their preference, but has not selected to outright force that version.
Level specifies "orig.cancan" as the music, and specifies to play the SMS version.
> The level plays the Amiga version of orig's "cancan", because the user does not have the SMS version installed, so it reverts to their preference.


Some possible issues:
- What to do if the user doesn't have *any* version of the specified track installed? While NeoLemmix would come with at least one version of all the official tracks (most likely Amiga versions, since they're the second most well-known after DOS, and are far smaller files than the DOS ones), this could be relevant if, say, someone makes a level and specifies an LPIII track for it.
- Should the "override level's preference" option really be there? My initial thought was against this, but then I realised someone who's really determined to get their preferred version could just delete the not-preferred version of it anyway, which would just create a mess and achieve the same end result.
- What about cases where custom packs have musics which could be considered variations of the standard ones? Two examples that come to mind here are Holiday Lemmings Plus and Lemmings Reunion, both of which have both completely new tracks and variations of existing ones. Should it be encouraged to install them as variants of existing tracks?

Final decision: This idea seems to be universally liked among those that voted. But it's also quite a lot of work to implement. So most likely, such a feature will not be in the first release, but all coding will be done with keeping in mind to allow for this to be easily added in a future update.

So another idea that's crossed my mind - and please be aware, I'm not 100% sure if I will be able to do this, it's just an idea really that I might look into if there's enough interest.

Should V2.00n (or more likely, V2.something-n; I doubt it'll be in the first release) be capable of directly accessing an online database of NeoLemmix content? This could simplify the update process; with almost everything being able to update just by clicking a "check for updates" type button - not only NeoLemmix and the "official" content, but also any fanmade packs. On top of this, it could alleviate the need for any manual setup of packs - just find it in the database, and click "Download" and it's done. Likewise, custom content could also be uploaded directly from NeoLemmix itself (or more likely, from the editor). Other potential uses is that, if (for example) it detected that you were missing the required graphic set for a level, it could try and find it through the content database.

Aside from the question of whether or not I'd actually be capable of implementing such a thing, I don't really see much in the way of drawbacks. However, I'm well aware that some people prefer a system of "keep everything offline / manual". Of course it would be possible to simply not use any online features (and of course it would be possible to download the content through traditional means rather than through NeoLemmix; and for that matter, to distribute it without doing so through NeoLemmix's online features); but some people may be touchy about the fact that such features even exist.

What's everyone's thoughts on this idea? Before any discussion of how it should be implemented, let's first see what the opinions are of the idea overall.

(And no, "multiplayer" is not something I am considering supporting among the online features. Sorry about that.)

This topic is for discussion of the levels, feedback, posting replays, etc. For creators wishing to post updates, or if you're looking for the latest updates, please check this topic instead.

So, entries have closed, it's time to play!

The submissions are (as usual, alphabetical by author name):

<V4> "Safe Descent" by bsmith (NeoLemmix)
<V4> "Mind the gap!" by Crane (NeoLemmix)
<V1> "Cogopolis" by DynaLem (NeoLemmix)
<V2> "Parking Garage" by Geoffster (NeoLemmix)
<V3> "Las Ranas Hermanas" by geoo (Lix)
<V1> "The Adventures Of Lemdiana Jones" by IchoTolot (NeoLemmix)
<V1> "House on a Hill" by mobius (NeoLemmix)
<V1> "Altruism" by Nepster (Lix)

NOTES:
IchoTolot's level has a custom music file to accompany it. This should be placed in the same folder as CustLemmixNeo.exe.
Nepster has recommended that his level may be more difficult on the 2015-08-09 release due to physics changes, and an older release should be used if possible. Geoo recommends the opposite for his level.

The levels are in an attached ZIP. To play the levels:

NeoLemmix: Run NeoCustLemmix, press F6 on the title screen, and select the LVL file. Alternatively, open them in the editor, then press F2 for playtest mode (requires a copy of NeoCustLemmix in the same folder as the editor).

Lix: Copy the level into the /levels/single/ subfolder, then select them from the "Single Player" menu.


Update phase will end at whatever comes last - 22/08/15, or when 72 hours have passed since the last time an update was posted (currently 22/08/15 15:50). The voting phase will begin about 5 days after the update phase ends.



As a reminder, the prizes available for this contest are:

The prizes available for this contest are:
- US $12.50
- One and a half month's advertising in the forum's news ticker for a project you are involved in, whether lemmings-related or not, and whether free or not
- Early access to the Ghosts gimmick in NeoLemmix <May be chosen by both winners>
- Your choice for the next contest's rules (within reason)

Note that in the case of someone who already has a one-month advertisement on hold, if they win the one-and-a-half-month one here, it is entirely up to them to choose which order they use them in.

Attachment updated 20/08/15 02:57