Lemmings Forums

Lix => Lix Main => Topic started by: Simon on April 05, 2014, 08:08:24 PM

Title: 2014-04-04 released
Post by: Simon on April 05, 2014, 08:08:24 PM
Hi folks,

Lix version 2014-04-04 is available. Download Lix or view the changelog.

If you've designed things for inclusion in the release, you might check if everything is where it should be.

There have been physics changes. The older versions can't be played on the central server anymore. If you would like to play online, the update is mandatory.

-- Simon
Title: Re: 2014-04-04 released
Post by: RubiX on April 05, 2014, 09:38:22 PM
Hooray for update day!

Lix now has a very professional looking titlescreen background image also, pretty polished game now. 
Check it out people!   :thumbsup:
Title: Re: 2014-04-04 released
Post by: Nepster on May 01, 2014, 11:45:55 PM
I found a bug in the current version allowing you to "create" new builders and platformers:
You turn on slow motion and then assign during one frame several builders to a lix. It seems essential that you do all these assignments during exactly one frame. Furthermore you have to (try to) assign more skills than you actually have left at the moment. If the builder then hits a wall, you will get back all the builders you tried to assign, which may be more than you had previously!
I attached a replay showing this behaviour: One gets 4 builders out of 3 by using one (http://www.lemmingsforums.com/Smileys/lemmings/tongue.gif).

Mod Edit: Restored attachments.
Title: Re: 2014-04-04 released
Post by: RubiX on May 02, 2014, 11:23:06 PM
very interesting bug you found.   
I saw the extra builder ability gained in your reply.

I've tried to replicate it happening on one of my own maps i randomly loaded but can't get it to happen.
Basically i used all my bridges leaving only 1, so i could easily click more than a couple builders during the 1 slowmotion frame, but when i hit a wall I do not get any return of bridges, down to 0 as it should be. 

Definitely saw it happen in your replay though.
Title: Re: 2014-04-04 released
Post by: NaOH on May 02, 2014, 11:33:29 PM
RubiX: maybe examine your replay to check if your assignments actually did occur on one frame? I was able to replicate this bug.
Title: Re: 2014-04-04 released
Post by: RubiX on May 02, 2014, 11:57:23 PM
! 70 0 SKILL 11
! 84 0 ASSIGN 0
! 134 0 SKILL 7
! 134 0 SKILL 8
! 134 0 SKILL 1
! 134 0 SKILL 8
! 142 0 ASSIGN 2
! 169 0 ASSIGN 3
! 198 0 SKILL 7
! 246 0 ASSIGN 0
! 246 0 ASSIGN 0
! 246 0 ASSIGN 0
! 246 0 ASSIGN 0

^ had 2 bridges, tried to assign 4 of them and hit my head after a few steps, 1 bridge remained.
Title: Re: 2014-04-04 released
Post by: Simon on May 03, 2014, 12:36:50 AM
Thanks for the bug, will look into it at some time!

-- Simon
Title: Re: 2014-04-04 released
Post by: namida on May 03, 2014, 04:50:51 AM
The game still doesn't work at all for me. Same story as before; freezes on the language select screen, switching between fullscreen and window unfreezes it for about half a second.
Title: Re: 2014-04-04 released
Post by: Nepster on May 03, 2014, 10:22:20 AM
It seems that there are at least two other requirements for this bug:
- The builder has to be a runner as well.
- Number of Builders returned + 1 <= Available builders at the beginning of the level.
So far I have only managed to get this bug for "Circular Ruins" and "Go ahead and Help Yourself", but not for "Crimson Room", "Don't Look Back" or "Just Stop the Bleeding".
Hope this helps for reproducing the bug.
Title: Re: 2014-04-04 released
Post by: RubiX on May 03, 2014, 02:56:51 PM
Yes thats it.   Thanks for the additional info.  With turning the lix into a runner I was able to immediately replicate it on a small test map.

NaOH , you mentioned replicating the bug earlier too, so was your Lix already a runner, or you may have found other additional circumstances that the bug can occur.
Post a replay if yours was a walker and not a runner at the time

thx
Title: Re: 2014-04-04 released
Post by: RubiX on May 03, 2014, 03:18:10 PM
Still I have never seen Lix not load after playing it on win XP,vista and win7 machines.

@Namida

run as admin
vid drivers updated
try compatibility modes
Possibly windows aero settings (disable it if its on)
color bitrate settings
monitor refresh rate ?

Just throwing out ideas. 





Just wondering , if you skip the language menu will the game load, or then crash at the name input screen

goto
\lix\data\user
edit your .txt file in that folder so the first line is
#LANGUAGE 1

Then when the game is next opened, it has a variable saved for English language, and then should automatically be at the main menu screen, unless the
option for changing name on every startup is automatically always on.  I don't remember.   (then it might crash at the name input screen)



Maybe its certain video cards.
Maybe we should start making a list of video cards that people are using who can't load the game after trying all these things for windows.

Title: Re: 2014-04-04 released
Post by: geoo on May 03, 2014, 03:36:11 PM
I've heard of all kinds of issues with Lix on Win 7 and other systems and had a few myself...when I'm over at Simon's I'll try to compile a 64 bit version of Lix for Windows and see whether that solves anything. Eventually, we probably need a port to Allegro 5 or SDL at some point to fix all the issues though.
Title: Re: 2014-04-04 released
Post by: namida on May 04, 2014, 01:42:06 PM
Nope, doesn't help.
I have a laptop, so it's got the Intel HD / NVidia GeForce combo setup going. No matter which one I try running Lix with though, same result.
Title: Re: 2014-04-04 released
Post by: Simon on May 07, 2014, 11:14:10 PM
I found a bug in the current version allowing you to "create" new builders and platformers:

Found the bug, it's fixed in the next release.

All runners reimburse builders/platformers twice in the current version. You assigned 3, with one carried out and 2 queued, and it reimburses 4.

namida's problems should require porting to a newer library, yes.

-- Simon
Title: Re: 2014-04-04 released
Post by: RubiX on May 07, 2014, 11:42:20 PM
yay Simon  :thumbsup:
Title: Re: 2014-04-04 released
Post by: Simon on May 11, 2014, 02:31:54 AM
Here's the preview of bugfixes for the next version:

    Chat between lobby and game isn't erased
    Transmit directional force over network
    Jumping through platformer bridge from below
    Reimburse too many builders
    Don't display hotkeys on esoteric skills
    Editor jumbles grid alignment on dragging selection
    Cancelling digger by assigning miner/blocker during mid-stroke
    Remove the anti-blocker field
    Bracketed checkmark doesn't vanish

Information about unclear summaries is in the Lix bug tracker on my site.

-- Simon
Title: Re: 2014-04-04 released
Post by: RubiX on May 11, 2014, 04:43:54 PM
Very nice to see  :thumbsup:
Title: Re: 2014-04-04 released
Post by: NaOH on May 12, 2014, 02:11:48 AM
Yep, these are basically all the bugs I've ever noticed, other than alt-tab. :thumbsup:
Title: Re: 2014-04-04 released
Post by: ccexplore on May 28, 2014, 10:41:16 PM
This feature may have been around long before the 4/4 release, but I'm not a fan of having the hotkey text displayed (overtaking the usual display of time, number of lemmings, etc.) when mouse is over one of the non-skill buttons.  Would like an option to turn off that text.  A better default may be have that text only display for a second or two, and then go back to normal display until the mouse have left the current button to some other one.  But I understand it's kinda a bit of work to do all that (and even then I'd rather not have the text at all anyway), so just an option to turn it off altogether would be fine.

I understand that the workaround is using hotkeys instead of mouse and maybe that's part of why those hotkey texts are so in-your-face, but that's not good enough an argument for me.  As a primarily singleplayer-mode player, the case I'm frequently running into where the hotkey text is actively being a jerk is using the fast-forward and pause buttons.  Using the mouse to invoke those buttons shouldn't penalize me from not being able to see the far more pertinent information like number of lemmings in the level, or force me to have to move the mouse cursor away from the buttons just to see those information (and then have to move the mouse back onto the buttons when I want to unpause or un-FF).
Title: Re: 2014-04-04 released
Post by: geoo on May 28, 2014, 10:53:03 PM
Yeah, me, Proxima and mobius have complained about that too in the past. Right now there's an option in the menu that turns off these hints, but it also turns off the hotkey display for the 12 skills. Even worse, right now there's a bug so that the game doesn't remember that you want them turned off upon quitting, so you'd have to do this at the beginning of each playing session. I suppose the latter bug will likely be fixed by the next release.

Needs discussion how to solve the main issue at hand.
I simply suggested separating the option for skill hotkey display from hint text display.
Though maybe there could be yet another option for hotkey display for the non-skill buttons, or just one single option that pertains to both skill and non-skill hotkeys.
Title: Re: 2014-04-04 released
Post by: ccexplore on May 30, 2014, 07:20:55 PM
Quick update:  I found the option (it was actually a few days ago) but it wasn't exactly intuitive to find either, it is under "graphics" which I thought was only stuff like screen resolution and fullscreen/window.  I think I first tried looking in "hotkeys" and "general".

Separating the option makes sense to me.  The skill hotkey display works since it's never blocking you from viewing other information, unlike the hint text display.  Both may serve effectively the same purpose but they look different enough that people may not realize one setting controls both.  I can understand a desire for consistency so that by default we can automatically teach the user about hotkey assignments for all the buttons, but in practice this has proven more trouble than it's worth I think, and the skill hotkey display is arguably the more important of the two anyhow.  (Though I'd say pause button also deserves a skill hotkey display and can readily accommodate one.)

========

I heard "burner" being mentioned multiple times in recent IRC, what is that?  A new hazard object?
Title: Re: 2014-04-04 released
Post by: geoo on May 30, 2014, 07:55:36 PM
Lix can be in other states than in the process of performing one of the 15 main skills. E.g. they can exit the level though the goal (exiter), burn in a sawblade (burner), shrug after done building (shrugger), fall on their nose (stunner)... Lix is coded in such a way that all of these are actually assignable skills that you can put in the skill panel by editing the level file manually.
Title: Re: 2014-04-04 released
Post by: ccexplore on May 30, 2014, 11:14:23 PM
Hmm, so you mean someone came up with a level (or backroute) that actually requires intentionally "burning" a lemming? :o  That is indeed a little surprising.

How are such skills displayed in the panel?  Or maybe you can just share out the level and/or solution in question.
Title: Re: 2014-04-04 released
Post by: geoo on May 30, 2014, 11:35:41 PM
Some of those esoteric skills have an image in the skill panel, like the burner, but for most of them it is blank. You can see data/images/lix.I.png for the preview images of each skill.

The level in question is attached. It's solvable without the burner.

Mod Edit: Restored attachments.
Title: Re: 2014-04-04 released
Post by: ccexplore on May 31, 2014, 05:09:44 PM
My solution/backroute(?) attached.  Nice level, is it for inclusion in community set?

And even though it's left unused, I do get the idea now of a burner, you can use it for example to do skill-interruption moves without any unwanted side effect (besides the death of the lemming) from the skill assignment.

Mod Edit: Restored attachments.
Title: Re: 2014-04-04 released
Post by: ccexplore on June 06, 2014, 07:24:23 AM
I might have whine about this before, and this is admittedly a lower-priority quibble, but I'm recently reminded of this again:

Cuber is the only skill in the game where the graphics don't make it clear which terrain pixels get modified throughout the motions of the skill.  Compare to other skills:

- Skills like builders, platformers and exploders add/subtract terrain pixels all at once, so the final result you see is exactly what you get.
- Skills like bashers, miners and diggers take multiple frames to remove terrain pixels.  In theory (ie. ignoring the graphics of the Lix itself somewhat obscuring what you see), at all times during the motion, which pixels you see gone are exactly the ones that are removed during that frame.  Moreover, because those skills are interruptible, you can alternatively do that to learn exactly which pixels get removed when, eliminating the issue with the Lix obscuring what you see.

In comparison, even watching in zzz motion, I'm not convinced at all that I can confidently discern which pixels are added when during the motions of a cuber.  Perhaps you can say in that case, the animation graphics is too effectively obscuring the actual changes of the terrain, certainly more so than the case with bashers/miners/diggers.  At least to my eyes, it feels like throughout the animation (except the final frame of course) there are more yellow pixels displayed than are actually terrain--it looks like that to me while watching in zzz mode another Lix ascending up an in-progress cube for example.  Moreover the cuber is not interruptible, so you can't do that either to learn exactly how terrain pixels are added.

Is what I'm seeing correct, or is there some sort of optical illusion at play?  If former, then seems like it should be possible to remedy by slightly highlighting the pixels (or equivalently, dimming the other pixels) within each animation frame of the cuber that corresponds to added terrain pixels during the frame.  This should make it more possible to observe the exact terrain changes in zzz mode, hopefully without affecting the graphical quality of the animation by much.  That also seems like a simpler change than redoing the graphics to actually make it more accurately reflect the terrain pixels being added in each frame.

I suppose failing all that, I can also settle with guideline pieces depicting all the intermediate cubing stages.  Of course I have no means of actually making such pieces right now other than reading the actual source code to find out which pixels they are. :XD:
Title: Re: 2014-04-04 released
Post by: geoo on June 06, 2014, 10:32:39 PM
In all frames except for the final frame, we have int height = 2*l.get_frame()-2. Here 5 is the final frame (containing the full block), see data/images/lix.I.png for the actual frames. In a table linking frame number and height it should look like this:

00
10
22
34
46
516

In the animation, the cube grows diagonally so obviously it doesn't correspond to what's really happening. Mostly I just drew it like that so it looks decent and somewhat smooth. The issue with your suggestion of dimming/highlighting the respective pixels is that the lix animations are paletted (so they can be recoloured for multiplayer), and there are only three shades of yellow. Though you're welcome to draw a replacement animation the conveys more closely what happens (e.g. cube growing from inside to outside shaped like a hill, with the parts of the cube at the left and right border having the same height as the terrain that is created internally. You could e.g. use the next animation from data/images/lix.I.png as template and overlay the cube in some fashion to get the individual frames.
Title: Re: 2014-04-04 released
Post by: ccexplore on June 07, 2014, 01:19:08 AM
Thanks for the information.  It's nice to know that the terrain changes are far simpler than the animation would suggest. 8)

I think for now I'd just look at maybe creating guideline pieces to depict the in-between states, now that I know how simple they actually are.  If I feel particular ambitious I might try updating the animation graphics some day.
Title: Re: 2014-04-04 released
Post by: ccexplore on June 08, 2014, 12:35:54 PM
I've seen multiple recent mentions on IRC of "digger can be cancelled with miner due to its pixel removing pattern" issue.  But I don't understand why it's made out to be so hard to fix somehow (at least it sounds like that on IRC, maybe I'm just reading too much into things?).

I've attached a replay (level contained) which I believe illustrates the problem(s) at hand and my suggested solution, which is simply to tweak the pixel removing pattern by 1 pixel (sorry, 2x2 hi-res pixels more accurately, but you know what I mean).  It's best to view the replay zoomed in.  The left entrance illustrates the problem.  The right entrance, the reddish square block is replaced by steel so that one of the key pixels do not get removed by the digger.  The result is that the miner can continue on mining at the right entrance (ie. issue fixed), unlike the left entrance (original issue, if I understand correctly).  I jumped the diggers merely to allow the removed terrain pixels to be more easily viewable, obviously (or just verify within the level) the results are the same if you assign the miner directly to the digger on that specific frame.  You can compare side-by-side and see that with the steel, all I really did is to kept a single 2x2 hi-res pixel-block from getting removed by the digger, and that tweak is enough to allow the miner to not stop.

There is also a second problem which is illustrated at a later point in the replay.  When the digger has removed exactly half the full-width worth of terrain, assigning most skills (not just miners, but also blocker, batter, and maybe a few more I forgot) will immediately trigger a fall and revert to walker.  This doesn't happen if the assignment is made one frame after instead.  So I think what must be happening is that the lix should be positioned one pixel (ie. 2 hi-res pixels I guess) lower already at halfway, rather than doing so on the frame after like it is now.

Is that all, or are there some other aspects to this problem that I'm not seeing or understanding?

Mod Edit: Restored attachments.
Title: Re: 2014-04-04 released
Post by: Simon on June 08, 2014, 08:07:36 PM
The second problem (assignment in the exact halfway frame) is fixed in my local code and on github, but I haven't released since, because the first problem remains.

I will look into the replay, thanks! Maybe a small sprite amendment is enough instead of a full redraw to match a different digging pattern.

-- Simon
Title: Re: 2014-04-04 released
Post by: ccexplore on June 09, 2014, 12:19:20 PM
Maybe a small sprite amendment is enough instead of a full redraw to match a different digging pattern.

Ah, due to my arbitrary choice of a light-blue block for the terrain, I didn't quite clearly see the white "broom" of the digger and didn't realize the terrain removal pattern is matching the graphics of the broom.

That said, the proposal is such a small change that making the corresponding change in the sprite graphics should be mostly unnoticeable I think, especially during animation.
Title: Re: 2014-04-04 released
Post by: ccexplore on June 11, 2014, 03:30:07 AM
Double-clicking on the spawn rate buttons automatically set rate to max/min, which is very handy.  The problem is that sometimes you are really just doing two (or more) single-clicks to get the spawn rate from "around the ballpark" to a particular specific number, but happen to do the clicks fast enough to trigger an unwanted double-click behavior instead.

namida mentioned in another thread that he recalls an IRS, possibly Cheapo, where right-click is used instead to trigger the "instant min/max" behavior.  While perhaps less discoverable than double-clicking, it definitely does not suffer from the annoyance of unintentional double-clicks.  It is at least worth consideration as an option (ie. right-click vs double-click, and possibly other sensible methods) the user can choose.
Title: Re: 2014-04-04 released
Post by: Simon on June 20, 2014, 11:18:32 PM
Good idea against the double-click spawn rate buttons, I've already taken that into the bugtracker.

There will be something about the tooltips that obscure number of lemmings.

[00:11] <SimonN> making a game was a childhood dream, and now that it has users, it's all bugfixing
[00:11] <Proxima> Still. It must feel awesome to have got this far :)
[00:13] <SimonN> hmm, yes, it's weird :)
[00:14] <SimonN> at one time I must apologize to cc because I answer his posts so rarely, and his bugreports are always excellent and ideas are also very worthwhile


-- Simon
Title: Re: 2014-04-04 released
Post by: mobius on June 21, 2014, 02:33:31 AM
I second the  right-click spawn rate button idea.
Title: Re: 2014-04-04 released
Post by: ccexplore on June 21, 2014, 03:02:00 AM
Thanks and no hurries, after all the SDL stuff is far, far more important anyway, as it is addressing the far bigger issue of the game not running at all for some users.
Title: Re: 2014-04-04 released
Post by: ccexplore on June 26, 2014, 07:33:49 AM
It's somewhat my fault for throwing so many levels and replays into the same directory.  That said, in the UI for selecting levels/replays, I should be able to go back one page in addition to going forward one.  Replace the single "(more...)" with two buttons "Page Up" and "Page Down" maybe?  Or if you really must keep the UI the same, then at least make it respond to keyboard input so I can literally PageUp/PageDown.

Also, I'm wondering if anyone has suggested a "force queue" hotkey?  As you may have surmised, from time to time I've hit the case of trying to queue multiple builders to one lix but end up with the opposite (ie. multiple nearby lixes all become builders, understandably desirable for multiplayer but less so in singleplayer). I guess most of the time the priority invert hotkey should work though so perhaps it's not that necessary?  Would be curious to see if other people have encountered this and what their thoughts and practices are.
Title: Re: 2014-04-04 released
Post by: Simon on June 26, 2014, 09:19:06 AM
Page up/down: There are hotkeys configurable in the options that move the currently selected level by 5, and switch the page accordingly. This is slightly slower than moving an entire page, and does something different than the proposed page up/down if there is no level selected on the current page.

If that's not satisfactory, I'll write it down.

Queueing builders should always be possible with priority invert (right mouse button). Assign the first builder without invert and then queue while holding invert. I'm not sure if there are scenarios that require more precision.

-- Simon
Title: Re: 2014-04-04 released
Post by: ccexplore on June 26, 2014, 10:53:33 PM
Thanks for the hotkeys tip, I keep forgetting there are separate tabs in Options for hotkeys in different areas of the program. :XD: They are sufficient for my needs.  Though I have to ask why the editor and menu hotkeys' defaults seem to be deliberately avoiding arrow keys and the like even when they would be the most obvious defaults.  (Or was it perhaps just some old defaults that I'm carrying over by copying my current settings files over across updates?)

I've tested queuing builders more and it does seem that priority invert is good enough (once you get into the habit), even in cases where the lix being targeted has climber/floater or similar.

Anyway, I have one or two things to suggest related to the editor, but I shall wait for the upcoming next update to be released first in case anything got addressed by then.  Keep up the fine work! :thumbsup:
Title: Re: 2014-04-04 released
Post by: Simon on June 26, 2014, 11:37:39 PM
Right, I'll try to get all physics in order, and your proposed digger fix made it into my local code (delay the removal of a single pixel by 1 frame).

Everything else can go in non-physics version changes that do not demand the user to update. Non-physics releases can occur in quick succession.

-- Simon
Title: Re: 2014-04-04 released
Post by: geoo on June 27, 2014, 04:15:05 PM
Love the new frog animation, it stays very faithful to the clam.
I changed your image so the width of the object is 64, so it aligns more nicely with the grid and will be symmetric when aligned. It still looks exactly the same.

I drew two alternative animations of the frog, see attached. I propose all three to be included in the next release. :D
Title: Re: 2014-04-04 released
Post by: NaOH on June 27, 2014, 08:59:29 PM
Wow, I love your frog animations so much! frog_catch.T.png is beautiful; that poor lix really looks like she's struggling. And the burpmunch makes me laugh so hard. I definitely approve of all of these going in!

By the way, 9 frames is what the clam had. (One still frame plus eight animated frames.) They should be mostly interchangeable now.

It would be neat if we could make all of these the same trap and the animation is different each time.
Title: Re: 2014-04-04 released
Post by: RubiX on June 27, 2014, 09:47:22 PM
Yea.  How about each froganimation has a different number at the start of its filename

have a pre-check IF statement on map-load to see if any of those filenames exist in the .txt file

If found, then a random number generator just selects 1 of all frog files to actually use.
So each time you load a frog map it'll be random kill animation during that current game.