The basher/digger example is something I would put in the same classification as the timezone case I mentioned where I wouldn't really care about the classification, especially if it was an end user entering it. Sure, I might lean one way or the other if I'm entering it but if I'm having an end user enter it shouldn't really matter for something along those lines.

Honestly though if I have some sort of form for the end user to enter stuff I probably wouldn't even worry about classification at that point; I'd probably just have it be something like 'Enter a ticket' and not ask them/call it either one. No reason to give them the illusion of choice if there's a 50% chance they'd be wrong either way. In theory I'd be reviewing them afterwards anyway and can classify them at that point by adding a tag or whatnot if it helps the organization.

All this said, usually in my day-to-day work it doesn't particularly matter to me what it's considered, I just work on the tickets on the board. The classifications are probably used by the product owners for prioritization/etc but doesn't matter much for the actual dev work. And I haven't had any personal projects complicated enough to worry about ticketing systems.

I'm not sure if I totally agree with your classification, at least for all cases. When talking about a feature request, in most cases to me that means something the program doesn't attempt to do at all, so it doesn't make sense to think of it in terms of 'programmer implemented X, user wants Y.' For example, if I'm making a text editor, it doesn't really make sense to be like 'The editor allows copy/pasting, but the user wants it to do spellcheck,' these are mutually exclusive things. I guess you could like, think of it as 'The program does (not spellcheck),' 'The programmer implemented (not spellcheck),' 'The user wants (spellcheck), not (not spellcheck)' but that seems...a bit clunky?

To me, I'd say the main breakdown is like this:
It's a bug if:

• The program attempts to do X
• The program actually does Y

It's a feature request if:

• The program does not attempt to do X
• I'd be good if it did X

Now, I say the main breakdown because I think there is a middle ground that does act more like your example; existing things in the program that could act multiple ways without necessarily being wrong depending on your point of view. Just as a simple example, whether a time field defaults to the user's timezone or GMT. Depending on the context, there could be valid cases for both. Things like these I don't think I'd particularly care whether it's classified as a bug or a feature, especially if an end user is the one entering the report. Maybe these are the types of cases you are referring to, based on your flow.

I think agree with the general assessment of UX bugs, they will typically be things that act more like the later case of 'not technically wrong but could be better.' There's only so much you can add to protect the extreme edge-case user without becoming overly cumbersome for the general use (sure, multiple more confirmations on delete make it safer, but is it worth making 99.9% of cases that much worse to account for the .1% that may or may not happen).

Quote from: Simon on August 12, 2023, 02:27:46 PM
Four indices. American cards put indices in two corners only. Does no American ever fan cards in hand in the wrong direction?

To me this just seems like a self-fulfilling prophecy: why would anyone here learn to fan their cards the other way if you couldn't actually see what the cards were?

It actually took me a minute to figure out what fanning them the other way meant, at first I was wondering if you were all psychos that held the cards from the top or something. Didn't realize it meant having the left card on top rather than the right. Don't think I've ever even considered holding them that way. Just thinking about it that was feels like it'd be clunkier just to hold/fan, but that's likely just a muscle memory thing.

I've mostly played what I think is typically called Rummy 500, which rather than solely holding cards in your hand you instead play your sets visibly, and can play cards on the other player's sets as well. It also involves being able to pick up one or many cards from the discard pile. I enjoy the additional strategical elements that it involves. In general I prefer this version to Gin, but still enjoy both.

Rummikub is pretty fun. It kind of plays like Rummy (you're trying to make sets of at least three matching/three in a row), but one of the things I like most about it is that you can mix and match tiles that are on the board as long as everything ends up a valid set. So for example if I have a a red five, blue five, and green two, and the board has a green 3-4-5 set, I can play my 2 at the front to make it 2-3-4, then yoink the 5 to make a 5-5-5 set as well. Sometimes I'd end up rearranging half the board just to get one or two tiles out of my hand.

Quote from: Simon on November 02, 2022, 03:55:18 AM
In English, I haven't seen anybody put a space ("100%"). Is it correct to omit the space? That would treat % different than physical units; you'd write "220 V", "60 Hz" even in English.

As an only English speaker, I don't think I've ever seen someone put a space before a percent sign. Or at least, not that I can recall. It definitely looks weird to me.

And I wouldn't say that physical units always have a space in English, writing 220V or 60Hz is definitely normal, though adding the space there is probably more common than doing it for %. This might also depend on the unit though? I'm trying to think if there's any I would expect a space.

In fact, it looks like Google insists you don't put the space

So I was thinking of a different approach to the graph problem, but I kept hitting snags in my logic so I might think that over longer.

For Geoo's issue, I'm not sure if I 100% understand the priority orders you laid out. I think I figured out your initial example and was just conceptualizing it differently. I'm still unclear on the second example. You first say that the hatches would go A1, B1, A2, C2 as 1,2,3,4 respectively, but in the side by side examples it looks like A1 is 1 and B2 is 2? I also don't really follow how the rearrangement happens there. Not sure if I'm just missing something.

Here's some thoughts, based on my assumption of how the ordering works:

Spoiler

Okay, so my initial read on this is it's simply doing a bubble sort, you can move one item at a time and bubble it up or down to change the priorities. If that's the case, our worst case complexity is the same as bubble sort, which would be n-1 moves, or (p*h)-1 where p = num players and h = num hatches.

However, there are a couple different interpretations here that still fulfill the criteria of the problem, and it has to do with how strict we want the ordering. There's two variables we can tweak that give us slightly different scenarios:

Strict player orders: Do we care that player A always comes before player B?
Strict hatch order: Do we care what order the hatches release as long as they are synced for all players?

For example, this arrangement fulfills the original reqs if we don't need strict ordering for either:
B2 A2
B3 A3
B1 A1

I'm assuming here that we probably want non-strict player order (player order doesn't really have meaning since player order is random on level start) but strict hatch ordering (we want the level to spawn from top-down). Given that, we have a bit more control over the bubble sort. The worst case is still an inverted list, like so:
B2, A2, B1, A1
However, since we don't care about player order, we don't actually need to reorder B2 and A2, so instead of a worst case of 3 our worst case is only 2, to move B1 and A1 to the front (or B2 and A2 to the back, if you'd prefer )

Best as I can tell, the worst case complexity for this scenario is equal to p(h-1). No matter the original sort order, we can always ignore one group of hatches and use their player order for the other hatches as we move them around.

Now, in the very non-strict case where we don't care about player order OR hatch order, our worst case changes yet again. Now an inverted case isn't strictly worst because we don't care about the hatch order, we just need to group the same hatches with the same player order, so I think worst case becomes hatches grouped by player (A1, A2, A3, B1, B2, B3). To me, this seems like the most complex to try and find the formula for. because it's weird to think of scenarios, but I think that it ends up being (p-1)(h-1).

That also makes me assume if you wanted to keep player strict but hatch non-strict, it would be (p-1)h, but I honestly haven't checked that at all and am just assuming based on the other formulas I came up with.

Hopefully my interpretation is correct here? I think that no matter how you slice it it should be reducible to a list so I assume it should be a valid line of reasoning.

You could make this even more complicated if you consider that it's easier to change the priority in the text file directly, which allows you to move adjacent hatches up/down at the same time with copy/paste. My gut says worst case would still be arranged in a way where you're moving single items at once, but I haven't thought much about it.

To me this looks like a case of double escaping, though I'm not sure where the second semi-colon would've gone.

I might join, not sure. I'm currently trying to grind through some stuff in another game before some time limited content, so I'll see how much of it I get through during the week. If you end up light on people I can probably be persuaded to join, though.

I might be able to show up late, depending how long you guys go. 22 UTC is 5PM here and we usually go to dinner around 4 on Saturdays so I'll have to see when I get back.

Debian wants you to only make major updates every 2 years? Dang, that's a heck of a lot to ask for software dev, especially in this day and age...Though, admittedly I'm unfamiliar with most things Linux, so maybe this isn't that weird.

Anyway, on the dev side of things, I think that there might be some middle ground to the two plans.

I think that reworking the server to allow multiple versions to connect to it but only allow connections to the same minor version makes sense to add in general, even regardless of Debian stuff. It might be the case that not everyone updates instantly even on other platforms (since far as I'm aware there's no auto update), and it might also be the case that you want to have someone help you test a beta feature or something without worrying about what happens if someone else mistakenly joins the server. Making this change I think can be what allows you to make riskier changes without worrying about the Debian problem.

On the topic of the level format, from my experience I would say that changing a format like that is generally the last thing I want to do, as it just causes so many headaches (what to do with old data, etc), so I would say it's at least worth exploring how something can fit in the existing format before just changing it. That said, sometimes there's just nothing you can do no matter how malleable you tried to make the initial format because of things you just didn't think about. It can be kind of a balance here; sure, you might spend X amount of time exploring how the new feature could fit in the old format, but if it takes 3X time to design the new format/change the parsing code/figure out how to handle old formats, then it might not be worth it. One thing maybe worth considering also is if you can support multiple level parsers in one version (I know nothing about how the levels are parsed now). Could it be possible to add some 'format version' to the level layout that tells the parser how to handle any given level (and assume anything without this field is the old format). Maybe not the most elegant, but sometimes better than worrying about how to update all the existing data somehow.

Another thing with experimental features, in relation to whether or not to worry about spending time making it agree with the rest of the software; you could always do a quick and dirty version of a feature first as a test (does the feature work well, is it actually as fun as we thought, etc) before doing a second pass to make it 'fit' better if needed. It obviously would require a bit of rework, but sometimes after making something once when you take a step back and think about how you would design it again I find that I have a better understanding and better ideas on how to go about it, so it might be easier to fit it in more agreeably when you already have a general understanding of what needs to be done. Also, in relation to not wanting to cut something in an experimental version, don't be afraid to cut a feature if it doesn't turn out well in testing. If a feature just isn't fun, or doesn't work well, or whatever, don't let it hang around just because of the sunk cost fallacy.

Anyway, this ended up a bit more long winded then expected Some of these are probably already things you've thought of, but figured it was at least worth stating in case you hadn't. I'm likely not the best coder here, but I'm always happy to bounce ideas around if you need more eyes. I even wouldn't be against getting my hands in there, but not being familiar with the source language might make that a bit trickier.

Okay, had some more thoughts on this yesterday while trying to sleep, here's my thoughts/findings:

Spoiler

So, I mused in my previous post about whether or not it would be more efficient to change directions every time you returned to the starting car, and after more thinking/exploration I determined that it is, it's actually MUCH more efficient to change directions every time you return to the starting room. Here's the basic idea (also, I'm generally going to use right and left to refer to the directions because it just made the most sense to me to think about it that way):

So if every time you re-traverse the train you always start going right, all those steps you take to get back to the last car you checked are all wasted. You already know the entire path to that train car, so you aren't gathering any new information. However, if you change from right to left every time you return to the first car you can actually gather some information on the trip back out. If I start going right, don't find the end, but then go left instead, I now get to see the two cars to the left of start, which is new information. Then, when I don't find it on the left and head back right, even while traversing back to the furthest car I'm still gathering information, as I might've actually changed a light on that side now.

I'm not sure if I explained that well enough but here's some data I gathered on the total amount of steps that it takes to confirm the car numbers to prove that it's actually a lot more efficient:

Spoiler

Only moving one way:
Only Right, Case 1 : 2 steps
Only Right, Case 2 : 6 steps
Only Right, Case 3 : 12 steps
Only Right, Case 4 : 20 steps
Only Right, Case 5 : 30 steps
Only Right, Case 6 : 42 steps
Only Right, Case 7 : 56 steps
Only Right, Case 8 : 72 steps
Only Right, Case 9 : 90 steps
Only Right, Case 10 : 110 steps
Only Right, Case 11 : 132 steps
Only Right, Case 12 : 156 steps
Only Right, Case 13 : 182 steps
Only Right, Case 14 : 210 steps
Only Right, Case 15 : 240 steps
Only Right, Case 16 : 272 steps
Only Right, Case 17 : 306 steps
Only Right, Case 18 : 342 steps
Only Right, Case 19 : 380 steps
Only Right, Case 20 : 420 steps

Switching directions:
Left/Right, Case 1 : 2 steps
Left/Right, Case 2 : 6 steps
Left/Right, Case 3 : 7 steps
Left/Right, Case 4 : 13 steps
Left/Right, Case 5 : 14 steps
Left/Right, Case 6 : 22 steps
Left/Right, Case 7 : 23 steps
Left/Right, Case 8 : 33 steps
Left/Right, Case 9 : 34 steps
Left/Right, Case 10 : 46 steps
Left/Right, Case 11 : 47 steps
Left/Right, Case 12 : 61 steps
Left/Right, Case 13 : 62 steps
Left/Right, Case 14 : 78 steps
Left/Right, Case 15 : 79 steps
Left/Right, Case 16 : 97 steps
Left/Right, Case 17 : 98 steps
Left/Right, Case 18 : 118 steps
Left/Right, Case 19 : 119 steps
Left/Right, Case 20 : 141 steps

Only moving one direction will always take Σ2n (0 to n) steps to 'solve', whereas changing directions takes...Okay, so, I'm not really sure to be honest. Maybe someone better at math can determine that. The nice thing, though, is that for odd number n the number of steps to 'solve' will always just be the number of steps to solve n-1, plus 1 (because as soon as you enter the next car you will have noticed it changed)

EDIT: Looked into the numbers a little bit, best approximation I can find for the number of steps for each is this (I think):
Σi (for i=1 to n/2) + (3n/2) + 1 (or +2 for odd numbers)
(n/2 is floored for odd numbers as well)
I don't really understand the pattern but...I think this should be accurate?

I also made a quick python script for testing this, for anyone curious. Feel free to check my work/modify the search functions/judge my coding:

Spoiler

Code Select Expand

#!/usr/bin/python
import random

######################
#  Search Functions  #
######################

# Traverse the train always starting to the right
def forwardSearch(train):
totalSteps = 0
stepsToTake = 0
startingLight = train[0]
# Break at 100 in case I'm bad at coding
while stepsToTake < 100:
stepsToTake += 1
# Move to the last car
totalSteps += stepsToTake
# Change the light
train[stepsToTake%len(train)] = not train[stepsToTake%len(train)]
# Walk back to starting car
totalSteps += stepsToTake
# Check the light
if train[0] != startingLight:
# We changed the first car, we know how many cars
return (stepsToTake, totalSteps)

# Traverse the train both left and right
def swingSearch(train):
totalSteps = 0
stepsToTake = 0
startingLight = train[0]
observedRight = []
observedLeft = []
polarity = -1
# Break at 100 in case I'm bad at coding
while stepsToTake < 100:
stepsToTake += 1
polarity *= -1
lights = observedRight if polarity > 0 else observedLeft
# Walk the car
for i in range(1, stepsToTake+1):
totalSteps += 1
curLight = train[polarity * i%len(train)] # Don't access imaginary cars
if i > len(lights):
lights.append(curLight)
elif curLight != lights[i-1]:
# Light changed, log
return (i + stepsToTake-1, totalSteps)
# Change the last light, as well as our observed version
lastCar = polarity * stepsToTake%len(train)
train[lastCar] = not train[lastCar]
lights[stepsToTake-1] = not lights[stepsToTake-1]
# Walk back to starting car
totalSteps += stepsToTake
# Check the light
if train[0] != startingLight:
# We changed the starting car, we know how many cars
return (stepsToTake, totalSteps)

################
#  Run Trials  #
################
def makeTrain(size):
train = []
for i in range(0, size):
train.append(random.randint(0,1) == 1)
return train

NUM_TIRALS = 20
for i in range(1, NUM_TIRALS+1):
# Make a train
train = makeTrain(i)
# One direction search
guess = forwardSearch(train)
if guess[0] == i:
print 'Only Right, Case', guess[0], ':', guess[1], 'steps'
else:
print '!!! BAD ANSWER !!!'
# Switch direction search
guess = swingSearch(train)
if guess[0] == i:
print 'Left/Right, Case', guess[0], ':', guess[1], 'steps'
else:
print '!!! BAD ANSWER !!!'

(EDIT: apologies, it doesn't seem to like my code in a spoiler tag)

I assume this same theory should work for the more complex ways of traversing the train as well, I just did the simple case because it was the easiest.

(unrelated, but I tried the 4 box puzzle that was the previous one for fun, here's my working out if anyone is interested)

Spoiler

(labels in caps, contents in lowercase)
Who can have what label:
A: bb
   BBB - Know third is w
   BBW - Know third is b
   BWW - can't know third because it's already wrong
   WWW - can't know third because it's already wrong

B: bw
   BBB - can't know third because it's already wrong
   BBW - Know third is w
   BWW - Know third is b
   WWW - can't know third because it's already wrong

C: ww
   BBB - Could be
   BBW - Could be
   BWW - Can't be because he would know the third
   WWW - Can't be because he would know the third

D: Label must be WWW because no one else's can be

B must be labeled BWW because he's the only one who can have that, so his third is b.

Because B has bbw contents, A must have bbb contents, so his label is BBW. This leaves label BBB for C

Labels:
A: BBW
B: BWW
C: BBB
D: WWW

Either C or D must have www as the contents, but D can't have that because that's his label. So C has www. This leaves bww for D's contents

Contents:
A: bbb
B: bbw
C: www
D: bww

For the current puzzle, going off Simon's post:

Spoiler

To avoid the 'walking a million cars to find out there's 19' problem, you could always say that if you hit a series of x cars with lights off that matches the number of cars you already walked through (or maybe bump it to 2x or something for safety, since if car 19 was already off you'd turn around after 18x2 instead of 19x2), you could just turn around at that point, though that doesn't exactly fall neatly into a time complexity.

I'm trying to decide if you did turn a light on and walk back to start, if you con't find a light on on the way back (meaning you didn't loop yet), if it would be helpful to proceed in the other direction or not. Probably not since you still wouldn't really know when you hit the light you turned on, so might as well continue the same direction you already were, knowing you can probably proceed to at the very least 2y cars (where y is the car you decided to turn around in the first time) before you would reach the point where you might've looped.

All in all, not sure if these are even helpful, just trying to throw some ideas out.

Spoiler

Leave your shoes in the first car, proceed through the cars sans-shoe, and when you get your shoe back that's how many cars

Okay, here's some real thoughts on the puzzle (not a solution really, but I'll spoiler just in case. It's mostly just kind of brainstorming an issue):

Spoiler

So, one thing I'm not sure of here is how to actually CONFIRM you've gone around. Even if you did something like always turn all the lights to off, can you really be sure you've done a full loop? Maybe there just happens to be a run of x trains all with their lights off that happen to appear after the point you think you've looped, so even by doing what you think is a second loop maybe you didn't actually do a second loop.

The only thought I have to deal with this so far is you need to do another loop in the opposite direction where you change something and confirm that you are able to observe said change. This seems inefficient, though, although would still be linear time since it's just another cycle of n, but the question is then if you do an extra cycle to confirm the size, but find out that you're wrong, what does that do to the time complexity? Is there a way to keep going still in linear time?

Apologies for the delay on these, been all over the place the past week. Here's the double team map pack. I did actually make a fix so that the chute is a 2px gap rather than 4px, to prevent the bridges that work for only one player. I also added even player versions just for completeness (except 2 players, because that seemed pointless, but maybe it could be interesting? I dunno).

Small disclaimer: I ordered the hatches/exits directly in the text file because it was easier than moving all of them around in the editor, but I did give them a once-over and I think all of them are in the right place. We can keep an eye out if anything is misplaced when playing, but i think it should be fine (honestly it's probably more likely everything is correct than if I moved them manually).

I can also include the original versions if you want, just in case, but I think the new versions should probably be fine.

Also, is there a file structure I should use for future reference? Right now it's just a zip with all the files in one folder, is it easier for you if I split them out the same way they're structured in the level navigator (with the network/user/#p structure?) or something along those lines?

Quote from: Simon on May 08, 2021, 07:34:43 PM
Dominator_101: Please send/post the team Rescue Rangers! I've got your Constructive/Destructive Interference and will include it in the next release.

Sure, I can definitely send my double team map. I did want to try and fix the one quirk where you can build a bridge that's safe for one player to drop but not the other (in the chute between the two players), but I think alignment is screwing that up, if I drop the gap to 2px (currently 4px) the lix just hang in the chute and don't fall. That kinda makes sense since it's in the exact middle of the two hatches, so it's likely at an 'odd' alignment rather than 'even.' If anyone has any ideas to fix this, let me know and I can try, but if people also don't think it's an issue I could just leave it as-is. I'm curious how wide the chute is in geoo's original team one, I based this one off of the single iteration since his team one wasn't up. One idea I had that might work is if I make the worker drops all 3px that should shift the alignment of the chute, but that might also be pretty annoying to change.

Whether I make a fix for that or not, I'll probably also spin up some even player versions, just for the sake of completeness (the point was to have an alternative to the even player team map, but no reason to not just include even player versions of this as well).

As for the interference maps, it might be best to just include the 2-player versions for now, I think I might need to think about how to better handle more players. My general idea of the maps was to be 2p, and I just kinda slapped on 4p versions since there were 4 hatches.