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

Pages: 1 ... 195 196 [197] 198 199 ... 243
2941
Closed / Re: [BUG] [PLAYER] Stateload without savestate
« on: September 04, 2016, 11:20:47 AM »
I would be ok with both behaviors. As we talked about this yesterday both ways seemed logical: Either do nothing or jump back to the start.

Only the bug needs to go :P

2942
Some more replays and backroutes as Simon came over today and played the NL levels! :)

I only attached the replays which were different from already existing solutions.

Crane got obviously yet another backroute to fix ;P

Gronkling's level may also be backrouted as Simon saved everyone here.

And everyone saved as well on zanzindorf's level, but this is probably more an alternative solution than a backroute.

2943
Closed / [BUG] [PLAYER] Stateload without savestate
« on: September 03, 2016, 04:17:57 PM »
We expected to get to the start of the level with this, but instead we got to an internal savestate. Internal savestate = savestate that was made internally to improve the framestepping performance. We never made an own savestate!

Pressing the stateload once more got us to the beginning of the level, but the terrain was only updated with the first pressing of the stateload. A result of this is attached as a png. The level restarts, but with still altered terrain from the last try.

To reproduce this (we made this with Cranes contest entry to R1): Play a little bit and alter the terrain, then press the 10sec skip forwards or wait for a little bit ~ 10 secs. You must have played at least a little bit normally so that an internal savestate is created. Then press the stateload it will take you to the internal savestate + resets the terrain to this internal savestate. Pressing the stateload again brings you now as intended to the beginning of the level, but does not resets the terrain to the initial situation

Proposal: Pressing the stateload without a user-made savestate simply takes you to the beginning of the level in replay mode with the initial terrain layout.

For the picture: The basher hole should not be there anymore.

2944
Closed / Re: Should air-bashing at steel turn climbers? [DISCUSSION]
« on: September 03, 2016, 02:42:29 PM »
With special-casing for the first two strokes, we could probably use the following rules to continue bashing:
3a) There is removable terrain withing the next 14 pixels (and at the correct height)
3b) There is steel within the next (14-5*n) pixels (and at the correct height), where n is the number of previous basher stokes that haven't removed any terrain.
3c) There is steel within the next (19-5*n) pixels (and at the correct height), where n is the number of previous basher stokes that haven't removed any terrain, and where the basher has made at most 3 strokes.

There are still some problems with this:
- In situation i) above, one can manage about four basher strokes before removing terrain for the first time.
- I can still cook up situations where terrain behind a steel wall determines whether a basher turns or not. Most notably this occurs when putting a steel wall (with possibly some usual terrain behind it) after a steel slops (like in möbius' example).
Moreover I am very worried that such complex rules like the above might introduce new glitches, that only occur in very specific situations and on very specific basher strokes.

Unless someone has a brilliant new idea, I therefore tend to choosing some basher mechanics that fulfil only two of the following three conditions:
C1) Bashers turn at steel only when standing directly in front of it, cf. http://www.lemmingsforums.net/index.php?topic=2579.0
C2) Steel-bashing to turn climbers is possible and it does not depend on the exitance of normal terrain behind the steel wall, cf. first post in this thread.
C3) On steel slopes, bashers do not continue bashing, cf. the example level that möbius posted in this thread.

Presonally, I am in favor of keeping the current V1.47 behavior and accepting that C3) is not satisfied. Reason:
- Not-C1) does have too many weird consequences and whether a basher turns depends strongly on the pixel they started bashing.
- "Terrain behind steel"-influences are less discoverable by players than the C3)-behavior. In other words: Players can probably guess what conditions need to be satisfied for Not-C3) to happen, once they see it. Guessing in what setups the "terrain behind steel"-influence comes up (without already knowing the cause) is far harder. 
Therefore I deem ignoring C3) the most user-friendly option.
Note that the Lix-basher satisfied C2) and C3), but not C1).


Yes maybe simply discouraging the usage of such behaviors is enough.

This is a pretty tough situation and C1 is the most important one to keep. I would be fine keeping the current V1.47 behavior for the sake of not overcomplicating the rules.

There will be always some slightly weird mechanics and if you try to fix one with new rules you may end up creating new weird stuff or breaking old rules which other content depends on. You just can try to keep them at a minimum.

2945
Closed / Re: Should air-bashing at steel turn climbers? [DISCUSSION]
« on: September 01, 2016, 09:38:16 PM »
In my previous suggestion (two posts above), I made a mistake in analyzing setups b) and d). These are now corrected. Unfortunately this means that this suggestion is not as good as it sounded at first, because we reintroduce problems regarding the right-most setup in the image in the first post.

Here another suggestion (disadvantages are discussed below):
1') Assume the last n basher strokes have not removed any terrain. Then continue bashing if there is either usual terrain or steel withing the next (14-5*n) pixels (and at the correct height).
2) Always allow assignment of bashers. Currently one cannot assign bashers within 4 pixels of a steel wall.

The advantage is, that this basher behaves properly even in setups b) and d).
But there are two disadvantages:
x) Currently one can start bashers 14 pixels in front of the wall and he will continue bashing into the wall. With the new rule 1'), the basher can only start up to 9 pixels in front of the wall.
y) Having multiple bashers in the same basher tunnel is now much harder with rule 1'), because to continue all bashers have to remove terrain. So if the first basher to remove terrain is in the front of the others, he will be the only basher to actually ever remove terrain pixels. Hence the other bashers would stop soon. So one has to be careful how to place the bashers...
Note that the problem y) already happens for rule 1a) above.

I don't have any solution to all of this, so any suggestions are more than welcome.

b and d are definitly cases which should be avoided, but x and y are desired machanics. x eases creating a  timing of Lemmings in very common cases (+ is certainly used in a lot of replays). y is used sometimes in puzzles, but it is still possible as you described.

To prevent b and d and keep behavior x my suggestion would be a special case for the first 2 basher strokes (yes this sounds bad, but it could be a solution).
If x can be kept with the extra rule for the first basher strokes and y is still possible, but only needs some replay fixing in a few cases this could work.

2946
NeoLemmix Main / Re: Experimental Releases for Physics Bugs
« on: August 31, 2016, 03:57:37 PM »
Just uploaded a new version of GSTool. It supports some settings that don't work in the current version but will in future versions, most notably, a new object type: "Background Image". An object set to this (one per graphic set) will be used as a background image on any level that uses the graphic set in question as its primary graphic set.

Most other newly-supported features are for long-term purposes, not immediate future.

Note that colors work a bit differently with this new version. You no longer set particle colors; instead, you can set the mask color (used eg. for bridge pixels), minimap color, and background color; with the remaining colors being unused (but the first three have planned future use; GSTool, when opening an old DAT graphic set, will automatically set the colors correctly for the new uses, including these future ones. I'm not sure if it sets them correctly when opening an old graphic set from any other format.)

So theoretically I could start replacing the huge single colred backgrounds "soon". "Soon" only because I don't want to create ugly errors in existing stuff when I remove them ----> loading a level with them will create an error for a missing piece, but this should be solved as I remember with only giving a notice that a tile is missing and remove it in the level for now rather then giving an error.
EDIT: Also the ordering of the tiles should not have an impact anymore when removing adding stuff.
And of course when the bg image is fully supported I will use them as well instead of the big picture.

2947
NeoLemmix Main / Re: Experimental Releases for Physics Bugs
« on: August 31, 2016, 03:28:36 PM »
Thanks! I will look into the new version over the weekend and see if sth new broke (probably unlikely) and see if older bug stuff works fine now. :)

2948
NeoLemmix Main / Re: Experimental Releases for Physics Bugs
« on: August 31, 2016, 03:17:58 PM »
Updated the experimental again. Includes Nepster's recent physics fixes, a fix for the issue of new version's settings overriding old version's, a fix for the crash on levels with custom window orders, and custom sound effects now work. :)

Which link contains the new version?

Does the first post in this topic got the most recent one? As that version seems outdated to me.

I don't really know which link in which topic (as there is the "upcomming update" topic as well) contains the actual newest version anymore :8():

The first post in each of the 2 topics should contain the newest exp version to player and editor, then it should be clear to everyone (if they do not already, I don't 100%ly know :P)

2949
I played through the new versions again. See attached replays.

Bulletride (click to show/hide)

Colorful Arty (click to show/hide)

Crane (click to show/hide)

geoo (click to show/hide)

IchoTolot (click to show/hide)

Simon (click to show/hide)

zanzindorf (click to show/hide)

The left third of the level is purely for the visuals. In fact the whole level is created because I had the specific visual idea in mind. The solution was secondary in this case. I created the landscape and carved out a solution afterwards.
Maybe if you watch my Dune 2000 let's play in the future you can understand the things I tried to represent there a bit better.;)
The precision with the 2 climbers was intended here and I thought it was alright because of the relatively long teleporter animation + with a savestate at the climber assignment another try is made in seconds. I will see when putting Reunion 2 together if I make some adjustments here and ease this (+ maybe making the gliding in The Machine a bit more obvious). Currently the precision can be avoided as well ;). Josh found a way to completely bypass the timing.

As we speak about visuals: Gronkling: What is your polar level trying to represent? It looks somewhat like a logo, but I don't know from what. ??? Is it indeed a logo, maybe from a sports team I don't know?

2950
Phew, I just solved Harkonnen Force. That was really hard, but it made me feel smart after solving it :laugh:
I also beat Arty's levels which were both fun. I especially liked the Banjo-Kazooie themed one. I beat Wishing well, but my solution was very similar to Arty's latest back-route solution. Still a cool level. I really like the moss. Attached is the Harkonnen Force replay. I won't attach the rest of the replays because they're all very similar to ones already posted.

Spoiler (click to show/hide)

Completely acceptable solution, well done! :thumbsup:

2951
General Discussion / Re: General Comings and Goings
« on: August 28, 2016, 10:24:42 AM »
I will be in my hometown again until probably next thursday so no videos or bigger activities over that time period.

2952
Ok, then this should be it. :)

2953
I think Crane's level might be intended now! 5 secs more on the clock could be also a thing to add as this level nearly finishes on the 1 sec mark even if I do anything as fast as I can.


Bulletrides level:
Spoiler (click to show/hide)

2954
Still saved the digger 8-)

2955
Annnd this time I saved the digger :)

Pages: 1 ... 195 196 [197] 198 199 ... 243