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

Pages: [1] 2 3 ... 121
I already experimented with shaded arrows, cf

Unfortunately, I can't remember where I put these experimental arrows and will have to either recreate them or search a while through my backups.

NeoLemmix Main / Re: Questions about the default GUI
« on: November 29, 2018, 05:19:02 pm »
This is really a matter of taste: At the moment, we try to reuse as many sprites as we can (e.g. recoloring the lemmings sprites for climbers, zombies, ... as well), because this ensures that players will always see a consistent look. Otherwise one might forget to change some types of the sprites and suddenly when you do a certain thing in-game, you will be presented with a totally different sprite.
In short: While having separate sprites adds more flexibility, is is also more error-prone.

And if I remember correctly, we implemented the recoloring of the time digits in a halfway sensible way by exchanging the red and green values of the RGB-representation of the sprite, instead of just replacing a few fixed colors by others. So there is actually a pretty decent chance, that replacement digits don't look too bad. But please don't blame me if I misremembered this point :)

Here is the problem: We only have one standard L1 OWW sprite (apart from the fire one), and this one gets recolored depending on the main style selected for the level. In light of that, what you are suggesting is a pretty large change, that I am not sure I want to do.

NeoLemmix Main / Re: Questions about the default GUI
« on: November 28, 2018, 08:33:12 pm »
I wanted to bring the changes on my own, but it appears I couldn't find the red digits for the game timer, only the green ones. I assume it's something handled by the game code? Does that mean that it's not possible for me to customize it? :(
Yes, the red digits are just created in-game by recoloring the green ones. If you replace the sprites for the green digits, the red ones will change as well, but no guarantees that the resulting digits look even half-decent.

why does it use the standard VGA style for the GUI in-game (the skill bar especially)? Why not using the better High Perf style instead, or the Amiga style to some extent? Is it because of nostalgia? Simplicity?
Because it is almost impossible to reach an agreement on what is the best style for the skill bar. So keeping the current one is the best way to proceed, especially as everyone can now change the skill bar to their preferred one themselves.

Lemmings Main / Re: Lemmings Arcade Prototype
« on: November 20, 2018, 05:23:18 pm »
Thanks for mentioning the Arcade Prototype. Until now I had no clue somthing like this ever existed! :thumbsup:
Youtube (of course) has some videos of music and gameplay, e.g.
The most interesting aspect for me was the usage of instant bombers instead of the usual timed ones! :lem-mindblown:

Easy fix: I removed the "By" from the level select screen. It seemed preferrable to me to have no "by" in the author field compared to having two of them.

I now implemented the easiest solution (at least code-wise): On each frame, play every type of sound at most once.

While I really value your input and your points do make sense, I have to say one thing:
This situation is exactly why I wanted people to post mock-ups of their preferred preview screen up-front, so that we can discuss the best layout before I do any changes. Personally I don't really care about the layout and I don't really want to adapt it every version until we find a layout everyone is happy with.

Upshot is: Don't expect any further changes soon, unless a lot of people chime in and ask for the same things.

NeoLemmix Main / Re: Manual for NeoLemmix - Update to V1.43
« on: October 30, 2018, 05:56:48 pm »
So it's version 1.43 of just the manual, got it! :)
No, it was the manual for NeoLemmix version 1.43, which never got updated to any of the newer versions. That was when I wasn't doing any coding for NeoLemmix and still had a lot more time for stuff like this... :)

NeoLemmix Main / Re: NeoLemmix - Quo vadis?
« on: October 30, 2018, 05:43:08 pm »
Thanks a lot, IchoTolot! :thumbsup: Any help is very welcome, and C# is conceptually rather similar to Java, so it shouldn't be a big step to get used to C#. Delphi on the other hand is a bit more low-level and has sometimes rather weird syntax, but if you know some statically typed language, it shouldn't be such a big step. At least I could understand it without much problems and modify it by copy-pasting stuff. :P
I guess the larger problem will indeed be getting used to the overall structure and where the code is for what part of the application. But at least the NeoLemmix code got a lot better in the past few years in that regard. Anyway, I can always tell you the part of the code you need to look at and then you can start placing breakpoints and debugging through it to learn how that part works. Usually one doesn't need to know all that much code to start becoming productive. 

Bugs & Suggestions / Re: [Suggestion] Ghost as a skill
« on: October 30, 2018, 05:27:06 pm »
Sorry for being somewhat late to the party... :-[

closed v10 subforum
As far as I can see, the "levels for V10" subboard is not locked at all. Has someone opened it in the meantime? I am totally ok with it being open.

Ghost as a skill - Do we need less code or will it be better readable?
I really don't see the big difference between having them as a skill and as a feature like zombies from a code-perspective. As a skill requires marginally less code for reading level files, but all the other code would basically be the same. Especially the interaction code of ghosts with skills, objects, normal lemmings, ... would be exactly the same - and this part was the major cause of pain in NeoLemmix V10.

Ghost as a skill - Does it really act like a skill?
If ghost would be implemented as a (permanent) skill, then you would get lots of weird interactions, because currently no lemming can use two skills at the same time. Permanent skills are only used to change the skill state under certain conditions: So either we would have some state "ghost" for lemmings, which would mean that ghost could do nothing else (and would even transform to usual lemmings upon falling down). Or the permanent ghost skill would trigger some state change upon certain conditions, like finding some trigger area, but this has two problems: In all other states it would be a perfectly normal lemming (so we can't implement fear e.g. and there might be a lot of other more subtle issues) and secondly it is not obvious to what state it should transform to? Even if we add another ghost state just for that purpose, then it would simply stop doing any other skill when encountering such a trigger, which we certainly don't want. And even more problematic is transforming from the "falling" state to the "ghost" state... 
What I want to say with all of this: If we want ghosts as a skill, they will have to behave drastically different from the old ghosts. Otherwise the base assumptions about what a skill is will be violated.

Just copy-paste the code
Even in Python this wouldn't work nearly as well as you would think: There are a lot of other classes that tie in with the lemmings, which would have to behave differently when encountering a ghost. Even ignoring that lemmings currently aren't even honest objects and assuming you could just subclass them to create ghosts (which would be a LOT better than just copying the code and would fix most the copy-paste problems Simon mentioned very early on in this thread), you would have to:
- Of course overwrite all the object interaction code, as you already mentioned.
- Overwrite a lot of the recoloring code: First of all to create the usual ghosts sprites, then to get variations on special occasions like when hovering over them with the mouse cursor.
- Overwrite a lot of the lemming counting code, e.g. to determine when there are still enough lemmings around to complete the level, when to quit a level as there are no more living lemmings, ...
- Overwrite a lot of the lemming state change code, e.g. because ghosts will not drown when falling into water and will not splat when hitting from high above assuming they land in water.
- Add a lot of to the general skill-handling code: From displaying a skill image in the skill bar to checking for this skill in talismans, there are a lot of places, where new skills have some impact. Most of them will automatically adapt once you add the ghost skill to the correct enums, but there are a few cases, which need manual modifications.
- If you code the "fear" aspect (which was in my opinion the major point in favor of keeping ghosts in the first place, because it was something really unique), you would have to write a lot of completely new code to handle this, or you would have to copy all the zombie trigger area map and adapt to to the fear aspect. But this would mean copying a lot of code, which is distributed among a lot of different methods and is not at all in one place.
Even then you will have to make sure this code is bug-free. And given all the problems and glitches we had with getting static force fields working correctly, I really don't want to deal with moving ones...

Lemmings code is really stable now - Is it really?
Physics-wise it probably is, though you would still have to do a major change to the copied code once the shimmier comes out, because the shimmier requires changes to a lot of other skills to define the correct skill (state) interaction. If you then had modified any part in the ghost code, I wish you a lot of happy merging all the changes. ;P (or rather :devil::devil:)
However there are still quite a few bugs in the sourrounding code, which might require changes to the lemmings code: IchoTolot found a bug recently, that allows you to assign two skills on the same frame, if you edit the replay file. If you copy the ghost code, are you really sure that any fix for usual lemmings would automatically avoid assinging a skill to both a normal lemming and a ghost in the same frame?

TL;DR: I don't think "ghosts" will work as a skill in the gimmick fashion at all, due to the definition of a "skill" that NeoLemmix uses. Moreover the "fear" mechanic would be incredibly susceptible to glitches in corner-cases, so would need a lot of work.

PS: At the time when we were discussing culling the ghost gimmick, I initially argued for keeping ghosts as I felt it had even more potential than zombies. However due to the code mess and the possible glitch problems, namida and others convinced me that removing it was (and still is) the correct decision.

Tech & Research / Re: How does NeoLemmix handle fast-rewind?
« on: October 25, 2018, 08:15:15 pm »
When mass replay checking (F7 on the main menu), we do exactly that in NeoLemmix: No drawing to the screen and no buffering. As we print out the in-game time regularly, you can watch yourself how fast this would be. And the answer is: Not nearly fast enough. Especially with long levels streatching over 10 minutes or so, you would have to wait several real-time seconds until the replay is finished.

I haven't profiled this, but my guess for the most time-consuming tasks would be on applying the terrain removal masks: The solid pixels are still stored in a huge bitmap and when removing or adding terrain, the corresponding mask is just drawn onto this bitmap (or rather the corresponding data manipulations are made). Yes, there are certainly faster ways to get the correct physics map (especially when not having to render the level at all), but that would mean quite a big change in how the code is set up.

However it really depends on the way the game physics are implemented - LJLPM might be luckier there than Lix and NeoLemmix are.

Haven't yet tried to reproduce it, but here is already one change to the fix proposal:
While only the first assignment should be applied, the others should be queued instead of being ignored. This is more keeping in line with our desire to try to make the best out of a malformed replay file.

I thought we were already doing that, but perhaps some of the bug-fixes in the last two or three versions have messed with this... or I am just remembering dreams :P

I would like to make three more comments:
1) As namida said, having an extra check-box in the editor to select the skills that should be present is a very bad UI. At least I tended to rage about it privately, especially when I accidentally selected 9 skills and then one skill was suddenly missing when playtesting (and yes, the old editor allowed such things). While other solutions are possible, I found the "select all with at least one skill" to be the easiest - both to implement and for the user to understand.
2) When playing levels, I find myself using the "skill 0" display in the skill bar: This tells me that I can obtain this skill via pick-up skills and that I can plan (parts) of my solution around using this skill. Thus a simply decorative "skill 0" would be misleading me.
3) I can totally understand your desire when using just the traditional skills and no pick-ups, especially in the example levels you mentioned.

Given that NeoLemmix now has to support all kinds of levels with widely varying skill set, I currently think that the advantages of the current implementation outweigh the problems with the "X-of-all-traditional-except-one" levels. In any case, there are currently more pressing issues (like the still far from finished shimmier...)

Closed / Re: Extended builder foot check
« on: October 22, 2018, 03:33:00 pm »
Please check out the version 12.4., that I released yesterday. The exploder graphics bug should be fixed in there. :)

Pages: [1] 2 3 ... 121