welp, hooked up a basic right click command, and rushed the bot with 4 drones, achievement unlocked i guess .-.
ok openbw, i get it you wanted to replicate the mechanics exactly, but did you also have to replicate the code quality of a 1998 video game?
https://github.com/OpenBW/openbw/blob/master/bwgame.h
arrive at this page every time i need to upload/send a video
https://stackoverflow.com/questions/20847674/ffmpeg-libx264-height-not-divisible-by-2
I get it there is a choice between pad or crop, but why do I have to do the math as well? T_T
got openbw to replay, getting rid of some dlmalloc nonsense, next to get a bot to compile (the one I tried was not c++, but some kind of MSVC specific, no includes, no respect for standard abomination) and cobble together enough UI to beat it.
So you terraformed your marses and made yourself these perfectly square flat islands, on which you made bunch of single rover housing stations in a perfectly square NxM grids, and then randomly air dropped bunch of rovers there. Now you need a program to plan a course to get each of them to a place they can call home. Some of you went for the Electric Wheelchair 4.2 model, and others preferred the Atomic Tank 6.6.6.
1. EM 4.2: these are super efficient but have limited fuel, so need to make sure you do not ran out of it on any rover.
2. AT 6.6.6: these have unlimited fuel but wreck the environment, so gotta have them moving as little as possible altogether.
Rovers can't collide thanks to state of the art interdenominational wormhole technology, but it's proprietary and patented so you can't use it for anything other than avoiding collision.
For those who have no or too much imagination:
given an NxM grid and K (<= N*M) random points, both in the same range (say 0 to 1 on each axis), pair the random points to grid vertices minimizing the
1. maximum distance
2. sum of distances
between each pair.
what's a column vector plus a row vector? huh? :v
huh?! :V
(>-.-)>
vector
(
vector(1),
vector(2),
vector(3)
)
+
vector(.1, .2, .3)
||
vector
(
vector(1.1, 1.2, 1.3),
vector(2.1, 2.2, 2.3),
vector(3.1, 3.2, 3.3)
)
now if you have been programming for a while you might have noticed that comparison is just a special case of subtraction. We have a subtraction here and clamp has got to have a comparison with sameish parameters in it, so lets expand it and see if we can notice any patterns:
upper =
B.upper < A.lower ? A.lower :
A.upper < B.upper ? A.upper :
B.upper;
offset = upper - B.upper;
lower = clamp(B.lower + offset, A);
return {lower, upper};
We have 3 cases, let's consider what upper and hence offset would be in each
B.upper < A.lower ? A.lower
offset = A.lower - B.upper
A.upper < B.upper ? A.upper
offset = A.upper - B.upper
otherwise B.upper
offset = B.upper - B.upper
the parameters of comparison and subtraction are the same, and in the last case subtraction is unnecessary, it's just 0, so we can do the subtractions upfront and then compare the results
offset_lower = A.lower - B.upper;
offset_upper = A.upper - B.upper;
offset =
offset_lower > 0 ? offset_lower :
offset_upper < 0 ? offset_upper :
0;
upper = B.upper + offset;
lower = B.lower + offset;
lower = clamp(lower, A);
return {lower, upper};
ok, does it look like something now?
no, what a waste of time and effort
pull_upper is classy, nothing to be ashamed of, while clampull properly telegraphs "steer clear of this madness"
it starts as your usual range clamping:
upper = clamp(B.upper, A);
lower = clamp(B.lower, A);
return {lower,upper};
or you might call it an intersection, but then you have the offset calculated from upper clamping and applied to lower before clamping it, so we're pulling the range B into the A when it's to the right of it. Could do the same with lower and pull it in if it's to the left.
so what is this:
got ranges A and B
upper = clamp(B.upper, A);
offset = upper - B.upper;
lower = clamp(B.lower + offset, A);
return {lower, upper};
libstdc++ manual: These debugging containers are functionally equivalent to the standard drop-in containers used in debug mode [1]
me: but why isn't std::string detecting iterator invalidation, like __gnu_debug::string, what am I doing wrong :/
libstdc++ manual: *goes on a huge rant about how awesome libstdc++ is* ... The end result is that we have achieved per-use recompilation but have had to give up some checking of the std::basic_string class template (namely, safe iterators). [2]
me: why thanks for being so honest and upfront about that, I totally didn't waste all day looking into this thanks to you -_-
1. https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_using.html#debug_mode.using.specific
2. https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_design.html#debug_mode.design.methods.coexistence