Enhance: allow modification of the player room indication on 2D map by SlySven · Pull Request #2621 · Mudlet/Mudlet

SlySven · 2019-06-15T18:08:43Z

This commit reorganises the 2D Painter code to draw the player room indicator AFTER all the rooms have been drawn so that it does not get overdrawn by rooms painted after the player's room - which it could be if the rooms are at maximum size or the area is in "gridMode".

It also offers some alternative marker options in the form of an oversized ring around the room which reduces the obstruction of the details of the room when the marker is drawn on it. The alternatives are:

a fixed red colour ring
a fixed blue/yellow colour ring - two contrasting colours mean that it can not be lost if drawn over a room that already has one of them as its colour (environment) setting.
a customizable two colour ring where the user can set the outer and inner colours as they like - even to the same colour.

~~This commit does not contain code to save the setting between sessions. It is intended to get peer/public evaluation of the proposal.~~ A follow up commit ~~will be~~ has been appended if as this proposal is acceptable and does work.

The ancient (bool) Host::mMapStrongHighlight option is still respected, I note that it was introduced in 3cb1719 from 2011/01/20 (after Mudlet 1.0.5) and the code to control it was lost in 8b0e8bb from 2012/12/31 "NEW Vadim Peretokin: mapper remembers settings" just before the release of Mudlet 2.0...!

This may fix #2057 raised by @Eraene .

Signed-off-by: Stephen Lyons slysven@virginmedia.com

This commit reorganises the 2D Painter code to draw the player room indicator AFTER all the rooms have been drawn so that it does not get overdrawn by rooms painted after the player's room - which it could be if the rooms are at maximum size or the area is in "gridMode". It also offers some alternative marker options in the form of an oversized ring around the room which reduces the obstruction of the details of the room when the marker is drawn on it. The alternatives are: * a fixed red colour ring * a fixed blue/yellow colour ring - two contrasting colours mean that it can not be lost if drawn over a room that already has one of them as its colour (environment) setting. * a customizable two colour ring where the user can set the outer and inner colours as they like - even to the same colour. This commit does not contain code to save the setting between sessions. It is intended to get peer/public evaluation of the proposal. A follow up commit will be appended if this proposal is acceptable and does work. The ancient `(bool) Host::mMapStrongHighlight` option is still respected, I note that it was introduced in 3cb1719 from 2011/01/20 (after Mudlet 1.0.5) and the code to control it was lost in 8b0e8bb from 2012/12/31 "NEW Vadim Peretokin: mapper remembers settings" just before the release of Mudlet 2.0...! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

add-deployment-links · 2019-06-15T18:08:48Z

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

SlySven · 2019-06-15T18:18:45Z

Original, current code:

Emulation of original - however drawing the indication later in the code means the exit markings within the room have been covered - to get it back we would have to have a copy of the code for them as part of the processing of the player room (making a function to do that and calling that for every room normally will slow things unless it is made an inline one):

Red ring:

Blue/Yellow Ring:

Custom ring with green and magenta colours:

vadi2 · 2019-06-15T20:08:20Z

I have a different take on doing this - what if we allow people to set a custom image in place of the marker? That would be way more flexible than the current and proposed ring system, yet still relatively easy to code and for people to use.

Eraene · 2019-06-15T20:38:42Z

This seems like a good change. I'm a little concerned the ring is too large, as it covers up adjacent rooms just slightly (and their exits), but it's a large step in the right direction.

As for a custom image @vadi2 - I'm not so sure. The idea of sailing the internet just to find an image to replace the marker that I don't like doesn't seem enticing to me.

SlySven · 2019-06-16T11:02:00Z

Also you would also need an image with a degree of transparency - and I do not imaging that there is a large proportion of stock images with that characteristic - remember .jpg just doesn't handle transparently and .gif can only set pixels of particular pixel colour to wholly transparent so you are pretty much talking only of .png ...

SlySven · 2019-06-16T11:07:41Z

... I'm a little concerned the ring is too large,..

A (couple of) spin-box(es) to set the outer (and inner) diameters might help there but you, Vadim, have previously reminded us to be really careful about adding more knobs and switches... 😟

vadi2 · 2019-06-16T15:34:23Z

Yeah, perhaps not on the general settings screen but hide the very rarely-used options behind pop-up menu. I don't foresee too many customising this given how few have asked to change it over the years.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

SlySven · 2019-06-16T22:04:04Z

Well I've added controls to set the size and also added alpha (transparency) controls to the custom colours which means that it can be adjusted to NOT obscure details - though what those might be can vary I guess between users' preferences for maps.

For instance grid mode maps perhaps will have different requirements than those with exits and where there is at least one (or two) room spaces between adjacent rooms - that is why I doubt there is one setting that everyone will think is the best...

vadi2 · 2019-06-16T23:27:31Z

👍

vadi2

I like 👍 thanks for adding this!

SlySven · 2019-06-24T22:19:33Z

It is still a Work-honestly-In-my-Plans-even-yesterday (WhImPey)... 😁 - it needs the settings to be save/loaded between session...

... also I would like to try and find a way to draw the player room last so then I can put it back to where it was before but avoid other rooms being painted from overwriting the new stuff. The quick and dirty fix would be to convert the (QSet<int>) TArea::rooms into a QList<int> for each T2DMap::paintEvent(...) call and then, if the player room is found in that during the iteration through it to skip painting it then and to append it to the end of the list - this would probably be simpler but be less efficient code compared to refactoring out the whole of the per room paint code to an inline method and then calling it with the player room after the iteration through all the other rooms ...

vadi2 · 2019-06-25T05:25:03Z

Hm... yes, let's just paint the room on top after instead of keeping changing the datastructures we use a lot.

SlySven · 2019-06-25T22:41:13Z

Actually the refactoring isn't too bad and it does allow the paintEvent code to appear to be smaller (by shunting it off to an inlined {I hope} method - and the benefit of not overwriting the player room markings does seem worth it...

SlySven · 2019-06-25T22:44:39Z

Oh, b****r - I had two parallel repositories (so I can run side by side comparisons of my work in progress code against the main line one) both open in Qt Creator - and I did the refactoring on the wrong repository's code! 🤦‍♂️

This is done by extracting the relevant room drawing code to a separate inline function that is used whilst iterating through the area rooms to paint them, skipping but noting if the player room is found and then that function is used to paint the player's room afterwards. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

SlySven · 2019-06-26T08:45:02Z

It turns out that using auto in a function prototype is a GCC extension to C++14 and the Clang compiler objects to it. (It was being used where a QPen reference/value was being passed to the new inline T2DMap::drawRoom(...)) It was inserted automagically by the latest Qt Creator extract function refactor operation so might need to be watched out for in the future...

vadi2 · 2019-06-26T08:47:26Z

Good to know!

SlySven · 2019-06-26T08:53:35Z

I'll see if I can fix it this morning - whilst on a 2 hour train to pick up a replacement 🚗 from a parent - I've reserved a Window seat with a table so should have power and WiFi on the way... 😀

The clang compiler does not like `auto` being used as a type in function prototypes as it is not formally part of the C++14 standard but a GCC extension - it got put in by the Qt Creator function extraction code option on the refactor menu. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

vadi2

Looks good 👍

@Eraene mind testing the final version?

vadi2 · 2019-06-26T21:04:32Z

src/T2DMap.cpp

+// player's room and then, AFTER all those have been drawn, once for the
+// player's room if it is visible. This is so it is drawn LAST (and any effects,
+// or extra markings for it do not get overwritten by the drawing of the other
+// rooms)...


I don't think this comment is needed. We don't need the history of the code as a comment (we can look at git history for that) and we can tell the function is used in two places by looking at usages. Long comments don't really help in readability, plus it's only you who'd be interested in keeping it up to date...

Well, not every usage of the source code is going to be from a git repository, but I take your point - how about if I reduced it to a one-liner along the lines of:

// We need to ensure the player's room is drawn last so that any oversized parts of it don't get overwritten by other rooms....

Perfect, and that should be at the point where this function is called for that reason - not at the function definition (doesn't make sense there)

src/T2DMap.cpp

vadi2 · 2019-06-26T21:06:55Z

src/T2DMap.cpp

-    bool __Pick = mPick;
+    // As it happens this local is never changed in this method so it can be
+    // made const:
+    const bool __Pick = mPick;


Suggested change

const bool __Pick = mPick;

const bool pick = mPick;

Agreed! Whoever thought to using a double leading underscore is heading for trouble as far as I can see, e.g. https://stackoverflow.com/questions/224397/why-do-people-use-double-underscore-so-much-in-c - mind you, I think I have used them in the qmake project file but then that is not text that is parsed by the compiler/linker...

SlySven · 2019-06-28T01:21:49Z

@Eraene mind testing the final version?

Not the final version yet I am afraid - got to get "saving-to" and "loading-from" the game saves working and it is a bit awkward as the TMap (and the mapper classes) do not necessarily get instantiated when the the profile is being read.

<ASIDE>This means the settings have to be stored in the Host class whereas currently they are in the TMap one - furthermore, since we seem to be trying to protect the Host class from conflicting access from more than one thread with a (QMutex) Host::mLock it is desirable to not access that class's member variables more than is necessary {which is why I've just raised #2673 which suggests a way to reduce the risk of deadlock there} so ideally I should continue to use the copy of the settings in the TMap class for map painting but keep them synced with the master ones held in the Host class...</ASIDE>

They are saved with the profile's data rather than the map. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

SlySven · 2019-06-28T18:41:37Z

Okay - finally got the save and load working.

Can you okay this now @vadi2 ?

Helpful hint no. 42: using pugixml::append_attribute(<attribute name>) more than once on the same node with the same attribute name produces invalid XML - but as pugixml is a lightweight ("speedy"?) library it does not check for such unnatural acts {see https://github.com/zeux/pugixml/issues/269} and the Qt QXmlStreamReader class will only report that such an element with a duplicate attribute is an element of a tokenType() that is QXmlStreamReader::Invalid instead of QXmlStreamReader::StartElement.

The moral of this is - if adding a new attribute to one of the elements that are exported in an Mudlet XMLexport method ensure you do not forget to edit the attribute name if you copy and paste an existing append_attribute(...) line of code. 😱

vadi2

Works well but I think there are improvements we can make to the code it make it less confusing, see below.

vadi2 · 2019-06-29T08:54:45Z

src/Host.h

    // An invalid/null value is treated as the "show all"/inactive case:
    QTime mTimerDebugOutputSuppressionInterval;

+    // This hold copies of variables from the TMap class which are saved with


This is a confusing comment and we shouldn't have it - it's the Host class that stores the application settings in Mudlet. Other classes should reference Host for the settings they need, not the other way around.

It didn't evolve like that! When I started this PR I hadn't contemplated the load/save of the settings - though in hindsight that comment does need revision..

vadi2 · 2019-06-29T08:56:34Z

src/Host.h

+    QColor mPlayerRoomColorPrimary;
+    QColor mPlayerRoomColorSecondary;
+    // Mode selected - 0 is closest to original style:
+    quint8 mPlayerRoomStyle;


Why such an esoteric datatype choice?

See C++ Core Guidelines:
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es106-dont-try-to-avoid-negative-values-by-using-unsigned

Deliberate limit on something with less than a handful of choices (four), and it is much safer to convert between integer representations of numbers of different bitnesses for unsigned integers.

This seems to go exactly against the best practice mentioned above?

vadi2 · 2019-06-29T09:02:11Z

src/T2DMap.cpp

+// player's room and then, AFTER all those have been drawn, once for the
+// player's room if it is visible. This is so it is drawn LAST (and any effects,
+// or extra markings for it do not get overwritten by the drawing of the other
+// rooms)...


Perfect, and that should be at the point where this function is called for that reason - not at the function definition (doesn't make sense there)

vadi2 · 2019-06-29T09:03:34Z

src/T2DMap.cpp

+// player's room if it is visible. This is so it is drawn LAST (and any effects,
+// or extra markings for it do not get overwritten by the drawing of the other
+// rooms)...
+inline void T2DMap::drawRoom(QPainter& painter, QFont& roomVNumFont, QPen& pen, TRoom* pRoom, TArea* pArea, const int currentRoomId, const bool isFontBigEnoughToShowRoomVnum, const int playerRoomId, const float rx, const float ry, const bool picked)


This function signature is a monster with many tentacles: I think if we gave anyone drawRoom(painter, roomVNumFont, pen, room, pArea, currentAreaRoom, isFontBigEnoughToShowRoomVnum, playerRoomId, rx, ry, __Pick); to look at, they'd have no clue what they were looking at. Let's improve it!

Can't currentRoomId be derived from pRoom inside the function? Or something like that - we have 3 arguments that all talk about the room, at least one should go.

pArea is only checked for gridMode - that should be passed in as a boolean to make the function interface more intuitive.

isFontBigEnoughToShowRoomVnum - no to yoda speak and 30 character variables! roomTextfits would work fine, observe:

if (mShowRoomID && roomTextfits) {

And it wouldn't even need the comment it has right now, because it would be self-explanatory.

The many tentacles come from me using the refactor code to extract a large chunk of code from the paintEvent code but not spending enough time to refine out all the extraneous bits - the use of pArea to get the gridmode setting does sound sensible, getting currentAreaRoom from pRoom also; roomTextFits though - what text - there is a symbol is that the text it means - fair enough I will have a think on that and find something we both can agree on...

😟 Oh, I haven't done much with this. Lemme have another look at it...

... okay take a look at the latest commit: 010f8b4 !

vadi2 · 2019-06-29T09:24:16Z

src/T2DMap.cpp

+            if (mpMap->mpRoomDB->getRoom(mTarget)) {
+                mpMap->mTargetID = mTarget;
+                if (mpMap->findPath(playerRoomId, mpMap->mTargetID)) {
+                    mpHost->startSpeedWalk();


Why is the function to draw a single room on a map calling startSpeedWalk()? That doesn't seem to make sense. Need to fix this in a follow-up PR.

ℹ️ Nope, that is actually starting the speed walk route calculation - because the current room being painted has been determined to be close enough to where the mouse was double-clicked on the map to be the destination for the speed walk. Incidentally the use of the playerRoomId is because that is the starting point for the speed walk route. Also, the destination room for the speedwalk gets drawn with a red-circle on it for just that one paint event.

As part of the previous point #2621 I happened to refactor this code out to a separate initiateSpeedWalk(...) helper! 👼

vadi2 · 2019-06-29T09:31:17Z

src/TMap.cpp


+void TMap::initialiseMembersFromHost()
+{
+    mPlayerRoomColorPrimary = mpHost->mPlayerRoomColorPrimary;


Why are we copying that into this class?

I originally wrote the code on the basis of having the settings in the TMap class - because they are associated with the map strangely enough 😉 - but then I worked out that they would need to be stored as part of the profile and thus as part of the Host class. I am aware that some of the members of that class are protected by a QMutex but it is not entirely clear why those particular ones are so protected; and rather than having to read the settings from that class for every T2DMap::paintEvent() I felt it was safer to work from copies held in the TMap class and only access the master ones in Host when they needed to be changed or used to initialise the copies.

You're the one who put a QMutex on them... if we don't need it anymore, lets take it off?

Seems to make sense not to complicate things with forgotten mutexes and then copying things around...

vadi2 · 2019-06-29T09:34:56Z

src/dlgProfilePreferences.cpp

+void dlgProfilePreferences::slot_setPlayerRoomSecondaryColor()
+{
+    Host* pHost = mpHost;
+    if (!pHost || !mpHost->mpMap || !mpHost->mpMap->mpMapper || !mpHost->mpMap->mpMapper->mp2dMap) {


This setting should be adjustable even when the map isn't open, right?

Debatable, I think. After all why show the controls if you are Mudding without a map - I know I wouldn't but not everyone thinks like that...

Well - because you haven't yet opened the map?

Ah, looking at how the code is structured that slot directly alters the 2D mapper by calling a method in the T2DMap class - which can't happen if there is no map loaded. Going to have to rethink this...

src/dlgProfilePreferences.cpp

src/mudlet.cpp

…odificationOfPlayerRoomIndicatorOn2DMap

vadi2 · 2019-09-05T18:02:25Z

@SlySven ping

vadi2 · 2019-10-13T12:24:48Z

👋 :)

As the `TMap` members being initialised are (now) public they can assigned values from the Host members they are caching directly in the `mudlet::createMapper(...)` method. In that method - since there are many uses of `(TMap*) pHost->mpMap` it is sensible to create a shorter named variable `pMap` to hold that pointer value. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

…IndicatorOn2DMap Conflicts resolved in: * src/Host.cpp * src/Host.h * src/T2DMap.cpp * src/T2DMap.h * src/dlgProfilePreferences.cpp * src/dlgProfilePreferences.h * src/mudlet.cpp Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

They were only being written to the cached values in the TMap instance so were not being stored when the profile was saved. Also the default output from `QColor::name()` does NOT contain any alpha component so that was not being stored either when the profile was being saved. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

It is not possible to just colour the background of the `QPushButton`s that set the custom colours to use for the *custom* player room marker as the transparency effects do not show. Instead this commit arranges for an icon with a black-and-white checker board pattern is over-painted with a brush in the relevant colour so that when the opacity is less than 100% the pattern is shown to an extent which is proportional to the degree of transparency of the colour chosen. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

…IndicatorOn2DMap

vadi2

Works well! I love the realtime feedback so you can do the settings adjustment quicker.

… code Suggested in peer review comment: Mudlet#2621 Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

…alised Forgot this when I was producting Mudlet#2621 as I tend to use the other form of the map in a floating/dockable window. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

…alised Forgot this when I was producting #2621 as I tend to use the other form of the map in a floating/dockable window. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

…udlet#2621) This is a squash-and-merge of a number of commits with the following edited summary: This PR reorganises the 2D Painter code to draw the player room indicator AFTER all the rooms have been drawn so that it does not get overdrawn by rooms painted after the player's room - which it could be if the rooms are at maximum size or the area is in "gridMode". It also offers some alternative marker options in the form of an oversized ring around the room which reduces the obstruction of the details of the room when the marker is drawn on it. The alternatives are: * a fixed red colour ring * a fixed blue/yellow colour ring - two contrasting colours mean that it can not be lost if drawn over a room that already has one of them as its colour (environment) setting. * a customizable two colour ring where the user can set the outer and inner colours as they like - even to the same colour. The ancient `(bool) Host::mMapStrongHighlight` option is still respected, I note that it was introduced in 3cb1719 from 2011/01/20 (after Mudlet 1.0.5) and the code to control it was lost in 8b0e8bb from 2012/12/31 "NEW Vadim Peretokin: mapper remembers settings" just before the release of Mudlet 2.0...! Refactor: ensure player room is drawn last This is done by extracting the relevant room drawing code to a separate inline function that is used whilst iterating through the area rooms to paint them, skipping but noting if the player room is found and then that function is used to paint the player's room afterwards. Revise: made code acceptable to all compilers The clang compiler does not like `auto` being used as a type in function prototypes as it is not formally part of the C++14 standard but a GCC extension - it got put in by the Qt Creator function extraction code option on the refactor menu. Revise: allow player room marking customisation to be saved and restored They are saved with the profile's data rather than the map. Revise: show transparency effects in custom player room marker colours It is not possible to just colour the background of the `QPushButton`s that set the custom colours to use for the *custom* player room marker as the transparency effects do not show. Instead this commit arranges for an icon with a black-and-white checker board pattern is over-painted with a brush in the relevant colour so that when the opacity is less than 100% the pattern is shown to an extent which is proportional to the degree of transparency of the colour chosen. Refactor: extract code to start 2D map speed-walk & simplify drawRoom code Suggested in peer review comment: Mudlet#2621 Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

…alised Forgot this when I was producting Mudlet#2621 as I tend to use the other form of the map in a floating/dockable window. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

SlySven added the 0 - Work in progress label Jun 15, 2019

SlySven requested review from a team June 15, 2019 18:08

SlySven assigned vadi2 Jun 15, 2019

Revise: allow size and transparency of player room marker to be changed

a1a208e

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

vadi2 approved these changes Jun 24, 2019

View reviewed changes

vadi2 assigned SlySven and unassigned vadi2 Jun 24, 2019

vadi2 approved these changes Jun 26, 2019

View reviewed changes

Revise: allow player room marking customisation to be saved and restored

e9ae730

They are saved with the profile's data rather than the map. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

SlySven assigned vadi2 and unassigned SlySven Jun 28, 2019

vadi2 requested changes Jun 29, 2019

View reviewed changes

vadi2 assigned SlySven and unassigned vadi2 Jun 29, 2019

Merge remote-tracking branch 'origin/development' into Enhance_allowM…

ab301a3

…odificationOfPlayerRoomIndicatorOn2DMap

W.I.P. incomplete

148ad60

SlySven added 8 commits November 26, 2019 20:53

Combine with merge commit

28489f9

Revise: insert spaces after commas to reduce moans from CodeFactor

557c8b9

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

Deconflict: attempt to resolve conflict in changes to Host.h file

9cd6122

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

Merge branch 'development' into Enhance_allowModificationOfPlayerRoom…

7028c34

…IndicatorOn2DMap

vadi2 approved these changes Dec 1, 2019

View reviewed changes

Refactor: extract code to start 2D map speed-walk & simplify drawRoom…

010f8b4

… code Suggested in peer review comment: Mudlet#2621 Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

SlySven merged commit 56c363d into Mudlet:development Dec 1, 2019

SlySven deleted the Enhance_allowModificationOfPlayerRoomIndicatorOn2DMap branch December 1, 2019 14:36

SlySven mentioned this pull request Dec 2, 2019

BugFix: ensure TMap members controlling 2D player room mark are initialised #3257

Merged

SlySven restored the Enhance_allowModificationOfPlayerRoomIndicatorOn2DMap branch June 22, 2020 18:06

SlySven deleted the Enhance_allowModificationOfPlayerRoomIndicatorOn2DMap branch June 22, 2020 18:13

SlySven mentioned this pull request Oct 26, 2024

Grid mode current position circle can get chopped off at times #675

Closed

Uh oh!

Conversation

SlySven commented Jun 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

add-deployment-links bot commented Jun 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test versions

Uh oh!

SlySven commented Jun 15, 2019

Uh oh!

vadi2 commented Jun 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Eraene commented Jun 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SlySven commented Jun 16, 2019

Uh oh!

SlySven commented Jun 16, 2019

Uh oh!

vadi2 commented Jun 16, 2019

Uh oh!

SlySven commented Jun 16, 2019

Uh oh!

vadi2 commented Jun 16, 2019

Uh oh!

vadi2 left a comment

Choose a reason for hiding this comment

Uh oh!

SlySven commented Jun 24, 2019

Uh oh!

vadi2 commented Jun 25, 2019

Uh oh!

SlySven commented Jun 25, 2019

Uh oh!

SlySven commented Jun 25, 2019

Uh oh!

SlySven commented Jun 26, 2019

Uh oh!

vadi2 commented Jun 26, 2019

Uh oh!

SlySven commented Jun 26, 2019

Uh oh!

vadi2 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SlySven commented Jun 28, 2019

Uh oh!

SlySven commented Jun 28, 2019

Uh oh!

vadi2 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

SlySven commented Jun 15, 2019 •

edited

Loading

add-deployment-links bot commented Jun 15, 2019 •

edited

Loading

vadi2 commented Jun 15, 2019 •

edited

Loading

Eraene commented Jun 15, 2019 •

edited

Loading