User talk:Xymph/Map views

Even more spots!
General remark: this is fantastic and I can't argue with any of the reasoning. I agree it might be distilled to a help page, though that takes effort &mdash; we've learned that help pages must be incredibly succinct and focused, or people stop reading.

Regarding spots, since my name keeps getting dropped. :>  E4M1 was actually done by someone else, which I'd completely forgotten along with its prefatory chat. That means at least five different methods have been used, and their colors vary also: Given the level of detail you're going into... is this important? It seems quite difficult to enforce a uniform style: unlike text markup, we can't assume the same tools are available to all editors. (Unless someone writes a new utility, and I'd also like my own tropical island and a pet unicorn.)   Ryan W (talk) 00:03, 5 May 2016 (CDT)
 * GIMP on Linux
 * Unspecified (looks extremely similar)
 * Unspecified (but clearly different)
 * Not certain; likely Windows XP with chintzy shareware clone of Photoshop
 * Unspecified
 * GIMP on Mac OS


 * Thanks for your kind feedback. I know I keep saying this or that should be in the Help/Guidelines section, but yeah, it all takes time and thought. And it seems that the admins & editors most active here, are also spread the most thin (hi Quasar :>).
 * Regarding how spots are done, thanks for addressing my question before I even got around to raising it. ;) I toyed around with Gimp (and an ancient version of PSP) a bit already, and realized that applying marked spots to maps is a task more monumental than most on this wiki. Some degree of automation would help to make it more manageable, so Gimp scripting might be a viable approach, but one I have zero experience with. And I already have enough on my plate, so I'll focus on areas with more immediate results. --Xymph (talk) 03:41, 5 May 2016 (CDT)

drawmaps.py script for Python 3
Since Omgifol has supported Python 2.7 & Python 3 since 0.3.0, your scaling-supported drawmaps.py maybe can be updated for Python 3? I tried following the Omgifol example using https://www.gamers.org/~fpv/drawmaps.py but Python 3.7.8 gave a syntax error.

File "drawmaps.py", line 73 print "\t%0.2f: %d x %d" % (1.0 / scale, xsize, ysize)

I believe Python 3 deprecated its statement supporting C -like arguments. But it can be updated to use string formatting passed into the function:

print('\t{0:f2}: {1} x {2}'.format(1.0 / scale, xsize, ysize))

--Afterglow (talk) 22:13, 10 October 2020 (CDT)


 * Thanks for the heads-up, as a Python noob :-) I wasn't aware of this. I added it as a comment, and also to the other printf-like statement at the end, but not making it the default because one of my (aging) systems is still on Python 2.x. --Xymph (talk) 12:49, 11 October 2020 (CDT)
 * https://gist.github.com/derekmd/f00cbb7cca65129b933f91086e76e1f1 is the updated script that works in Python 3. String parameterization actually doesn't need to be changed - simply modify the statements to be  functions by adding parenthesis. The only other change is a  line requiring an update: a) explicitly name the 'key' parameter for the lambda b) only use the single parameter passed into the lambda. (Line 80 now matches the lambda in Omgifol 0.4.0's  file.)
 * I believe these changes will be backwards compatible with Python 2.--Afterglow (talk) 14:26, 11 October 2020 (CDT)


 * Yup it works. But why change part b of the sort call? --Xymph (talk) 15:24, 11 October 2020 (CDT)


 * Using the parameter, Python doesn't pass the 'b' argument to the  lambda for relative comparisons between items. https://docs.python.org/3/howto/sorting.html#key-functions


 * ...a key parameter to specify a function ... to be called on each list element prior to making comparisons.


 * Further down the page there's a parameter example that can be used for the old lambda definition, but it requires the script to have different code for Python 2 and 3. https://docs.python.org/3/howto/sorting.html#the-old-way-using-the-cmp-parameter


 * In the case of drawmaps.py, the sort order is a binary true/false and each item can compute its rank in isolation. i.e., a linedef knows if it's 2-sided or not. Return 0 (false) when it's 2-sided, 1 (true) for 1-sided. The linedefs array will be sorted ascending 0 to 1 making 2-sided drawn first, then 1-sided. So the updated lambda is faster than performing an explicit comparison of every linedef combination. The one-argument lambda also works in Python 2 and Python 3. --Afterglow (talk) 15:46, 11 October 2020 (CDT)


 * My link updated. Thanks for the explanation. --Xymph (talk) 16:13, 11 October 2020 (CDT)