thomasahle / TrinityProject

A mindblowing trainbased game for entire family
http://thomasahle.github.com/TrinityProject/
GNU General Public License v3.0
8 stars 3 forks source link

BUG: DEADLOCK SplitMerge can deadlock if it's too short. #62

Open MattPellegrini opened 12 years ago

MattPellegrini commented 12 years ago

Try level 21 then just insert a SplitMerge, the trains deadlock.

Bug is also in the web version so has been there a while

http://thomasahle.github.com/TrinityProject/game/TrainBox.html

MattPellegrini commented 12 years ago

Perhaps we could have a solution where each component knows the longest train it can possibly take from it's previous component which is updated whenever a new component is inserted... sounds complicated though.

public void updateMaxLengthTrainExpected(int compNum, int len){ this.maxExpectedLength=len; log().debug("Max length of train expected for component " + compNum + ": " + len); mTrainTaker.updateMaxLengthTrainExpected((compNum+1), len); }

MattPellegrini commented 12 years ago

the above suggestion is now implemented, but the onSizeChanged() method of the SplitMerge component needs looking at. I've created a way to allow us to know exactly how much buffering the top and bottom components need to avoid deadlock, but I can't seem to use this to actually create the amount of buffering in onSizeChanged.

See commit MaxTrainLengthExpected implemented.

thomasahle commented 12 years ago

I thougt our idea was that people had simply failed the level if they deadlocked? I havent had a chance to look at your changes yet though.

MattPellegrini commented 12 years ago

Generally yes. So if they have a flip component and one put one train into it, this is a form of deadlock inherent to solving the game. (though we should indicate on components when they are full - separate issue)

However this is a form of deadlock that might be part of a solution to the puzzle, so it would be better to have it so that this can't happen.

My code gives the width that the first ID component of the top/bottom HorizontalComponent of a SplitMerge should be, I just can't get the code right to actually do this, the figure needed is there though.

It's called deadlockBufferWidth and needs to be used in onSizeChanged() of SplitMerge. The implementation of this method was confusing and I kept getting infinite recursion.

I thougt our idea was that people had simply failed the level if they deadlocked? I havent had a chance to look at your changes yet though.


Reply to this email directly or view it on GitHub: https://github.com/thomasahle/TrinityProject/issues/62#issuecomment-6544565

thomasahle commented 12 years ago

Again, I havent got access to the game now, but I remember discussing live resizing trains and tracks, and stretching splits when new components are inserted, and I remember the best solution we found was to simply not include levels that required sending too long trains into a split. Maybe your solution solves all the intuitivity issues, cant tell. Oh, and I appologize for the infinite reqursion.