Documentation for my plugins is changing. Hardware,...

« Back

628 days, 0 hours, 30 minutes ago

mcnimble

Documentation for my plugins is changing. Hardware,...

Documentation for my plugins is changing. Hardware, software, docs themselves.

With it comes a new URL: https://chmeee.org/#planets.nu
Note: The plugins themselves remain at the exact same URLs where they have always been, no need to change anything.

An improvement e.g. like this: https://chmeee.org/#planets.nu/RedrawAndFilter/EvasionFlare (with aligned pictures) is much easier now.

I also used the opportunity to improve the tampermonkey instructions: https://chmeee.org/#planets.nu/InstallingTamperMonkey

The new docs still show the old docs where they have not yet been changed. Old entry locations refer explicitly to the new location.

If things break horribly, the old version+content will be running here for a while: https://chmeee.org:8443/project/planets.nu/

Side note: I think the intermittent failures of my site have been solved since Nov 1st, and I expect them to remain solved.

627 days, 21 hours, 34 minutes ago

xpdx

RE: Documentation for my plugins is changing. Hardware,...

Cool plugins! Is there anyway to preserve the colors I've set for my planets while using the redraw and filter?

627 days, 21 hours, 32 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

Subscribing

Also, +1 to the previous question from Xpdx

627 days, 20 hours, 40 minutes ago

mcnimble

RE: Documentation for my plugins is changing. Hardware,...

Thx!

No. Since the request has come up before, here are 4 reasons why not:

The UI colors the note, not the planet.
The NU code assigns it to the note, at that.
The ShowNotes plugin will show the note in the color you gave it.

Furthermore, e.g. Planet 123 is orange, which means in your private color coding: has plenty of minerals. Except that info is superseded by the fact that the planet has been captured.

Then, if you set 11 colors for 11 players (the times I didn't realize two players were cooperating because that one ship was also red, and didn't jump out), do you have sensible/visible colors left for that kind of information?

Finally, the views that Redraw and Filter provide are better at visualizing quite a few of the things people use colors for. Such as 'plenty of minerals'. I find that written notes and ShowNotes take care of the rest, in much more detail than a color ever could.

627 days, 20 hours, 6 minutes ago

xpdx

RE: Documentation for my plugins is changing. Hardware,...

You are right of course that the plugin visualizes better and more precisely than my made-up color coding does, but habits die hard (even if they are dumb habits). Next game I start I'll try from the beginning with the RaF and forego my color coding.

Thanks for your efforts.

627 days, 20 hours, 4 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

If I want to see planet information on the starmap, instead of using colors, I add a note.
E.g. if a planet has a lot of Duranium on it, I make the planet note "D". Makes it easy to spot from the starmap.

627 days, 19 hours, 34 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

@Mcnimble, the reasons you stated for not manually coloring planets are good, and, yes, it did happen that a planet of mine was captured and it took some time for me to realize that, as it was manually color-coded and never displayed in red.

Problem is, I'm usually a micro-manager for the first 30-40 turns, and color coding gave me both economical and tactical view at a glance, if nothing else for (usually) 3 levels of development followed by 3 levels of military buildup, and some mix in between. Will have to try and replicate the same kind of eagle-eye view with the tools you built, which I already found much useful in other tasks.

627 days, 19 hours, 18 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

GAAAAAAHHHH

I realize just now that I also used "name-coding"... and R&F doesn't display ship names, only ship hulls, notes or nothing at all.

Can we hope for ship name display in a future release?

I know it's dumb to reveal to your enemy a ship class based on her name, but since I usually play Birds, if they actually see me it's either too late for them or myself.

627 days, 19 hours, 8 minutes ago

mcnimble

RE: Documentation for my plugins is changing. Hardware,...

*grin* yes, ship ID+name is somewhere on a list ;)

589 days, 18 hours, 37 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

UP!

After extensive personal testing, I'm giving due feedback - I switched to Redraw & Filter as my primary interface for playing on NU - whatever habits I had to loose in switching interfaces, are fully repaid in the better tools - "Evasion Flare" tool by itself is a good reason for change, and it's perfectly integrated in R&D!

(WISH LIST: any way to implement Evasion Flare calculations in the "q" function of the standard map? I sometimes have planets NOT pointed out as reachable in a single turn, as they really are if using the special Escape Points, and I have to discover it myself, then stitch a note to the planet!)

Keep up the good work!!!

575 days, 3 hours, 12 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

Update re: Horwasps

Question: is the protomolecule infection level from Horwasp minefields shown anywhere in R&F?

I played on a different computer, where I have no plugins, and realized there is this information displayed in the ship screen, in the standard NU interface. Can't say if this is visible on R&D until I reach home in another 8 hours

410 days, 6 hours, 6 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

I managed to find this thread again... miracles of Google Search... I have a couple questions RE: McNimble's Redraw & Filter:

- any way to toggle on/off the "turn: xxx" label stating on which turn the (outdated) info displayed on screen have been obtained? It's useful, but sometimes you have a map drawn with too many informations and need to temporarily clear it up;

- NEW FEATURE REQUEST:

The map usually displays planets in range for a warp-9 jump being joined by a line ("cluster" or "constellation") - it happens that this process doesn't display some "joins" for planets that you can actually reach - probably they are some corner cases of the algorithms involved.

This was true even for the original NU interface, so I suspect it's a system-wide issue (*). It would be really useful if Redraw & Filter could find this corner cases and join them with a specially crafted line, to let the user know that the standard interface doesn't show this "hidden path", but it actually exists.

(*) ADDED: I switched to another browser without any plugins, and I can confirm that with the standard NU map a given path for a 81.4 LY jump is NOT displayed either.

410 days, 4 hours, 40 minutes ago

drgirasol

RE: Documentation for my plugins is changing. Hardware,...

@ECATONCHEIRES: - any way to toggle on/off the "turn: xxx" label stating on which turn the (outdated) info displayed on screen have been obtained? It's useful, but sometimes you have a map drawn with too many informations and need to temporarily clear it up;

In the most recent version go to MapTools - Object Filters and press "Old". That will toggle the "turn: xxx" info.

404 days, 4 hours, 25 minutes ago

mcnimble

RE: Documentation for my plugins is changing. Hardware,...

There already is a plugin by @robodoc that shows complete planet connectivity. In addition it shows grav and/or hyp connections.

https://greasyfork.org/en/scripts/5020-planets-nu-gravitonic-connections

If you have Keyboard installed, 'q' will toggle its connections, and there are bindings for the grav/hyp connections, too. Press '?' on the starmap to see them.

404 days, 0 hours, 37 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

@Ecatoncheires: You can take the Gravitonic Connections script and mess with it to show only the connections the built-in Connections fails to show you if you want.

Since the script doesn't remove the built-in Connections map tool, it actually makes more sense for it to just show those ones, which are essentially Connections that exist because of Warp Well sliding.

Thanks for the idea! Ideally the built-in Connections map tool could just be improved though.
___

To change the script as I have, go to line 285 and change the 'true' to 'false'. This stops drawing obvious Warp9 connections (<83.5ly). I am concerned that this isn't identical to the Client... which would mean there would still be some missing connections altering the code the way I did.

I knew there were a lot of these missing connections in your average Sector.
But until I saw them all singled out, did I truly see how common they are.
___

Just a heads up, this script doesn't play well with the Ion Storm prediction script when set to view more than three Turns in advance (draw line thickness variable goes wonky due to conflicting script code alterations).

403 days, 18 hours, 24 minutes ago

hijk

RE: Documentation for my plugins is changing. Hardware,...

RAF is great. Planet color schemes are great too. Here's a simple edit to RAF to color planets: blue = high minerals, yellow = natives, green = both. Two advantages here: (1) the color scheme is automatic - you do not 'manually' set a planets color; and (2) the scheme is only active for planets you currently own, so when ownership changes, the default RAF color scheme is used. Edit criteria and colors to your own needs.

Around line #346 is the ColorForPlanet() function.
Edit the body of the function in TamperMonkey:

colorForPlanet: function(planet) {
// Original one-line return function for color as playerid or default grey . . . . . . . . . . . . . . . . . .
// return vgapRAFModel.showPlanet(planet) ? vgapRAFModel.colorForPlanetOwner(planet.ownerid) : "#666666";

var planetColor = vgapRAFModel.colorForPlanetOwner(planet.ownerid)

// If planet is owned by player, set color based on minerals and natives . . . . . . . .
if (planet.ownerid == vgap.player.id ){
var nativesYes = (planet.nativeclans > 10000) ? 1 : 0;
var mineralsYes = ((planet.groundduranium > 2000) || (planet.groundmolybdenum > 2000) || (planet.groundneutronium > 2000)) ? 1 : 0;
var ycolor = "#feff3d"
var bcolor = "#00679e"
var gcolor = "#549c00"
var sbcolor = "#8a00e6"
var amorph = "#ffa31a";
//vgap.starbases.forEach(vgapRAFModel.planetSBcheck);
//var planetSB = vgap.getStarbase(planet.id).planetid > 0 ? 1 : 0;
//console.log(">>> planet name = "+planet.name+"; Starbase = "+planet.isbase);
// 180529: add different coloring scheme if AMORPH natives are present.
if (planet.isbase) {
planetColor = sbcolor;
} else if (nativesYes == 1 && mineralsYes == 1) {
planetColor = gcolor;
if (planet.nativetype == 5){ planetColor = bcolor;}
} else if (nativesYes == 1){
planetColor = ycolor;
if (planet.nativetype == 5){ planetColor = amorph;}
} else if(mineralsYes == 1){
planetColor = bcolor;
}
} // end if planet is owned by player

return vgapRAFModel.showPlanet(planet) ? planetColor : "#666666";
},

#-- --- ----- - -- - - - - - - -- - - -- -

401 days, 16 hours, 19 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

@Ecatoncheires and @Glyn If you use both the default "Connections" tool and the "W9Connect" tool in Gravitonic Connections at the same time, the regular connections and "missing" connections are shown in two somewhat different colors, which seems to provide the information you are looking for (this is the way I intended for it to be used).

>Just a heads up, this script doesn't play well with the Ion Storm prediction script when set to view more than three Turns in advance (draw line thickness variable goes wonky due to conflicting script code alterations).

@McNimble sent me some suggestions on how to fix this a while back and even offered to send a fine-tuned patch. I'll update Gravitonic Connections once I get his patch, or I might just go ahead and implement his suggestions if he is busy.

398 days, 23 hours, 19 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

>Just a heads up, this script [Gravitonic Connections] doesn't play well with the Ion Storm prediction script when set to view more than three Turns in advance (draw line thickness variable goes wonky due to conflicting script code alterations).

I implemented @McNimble's suggestion for fixing this problem (I'm the author of Gravitonic Connections; I haven't released this fix yet). The difficulty that I'm having is that I can't reproduce the original problem to verify that it is fixed. McNimble's hint is as follows:

"...make it [Ion Storm Prediction] load just before GravConnect and set prediction turns >=2 to see what I mean"

I'm using Big Beefer's Ion Storm Prediction 0.3 and Gravitonic Conncections 1.3. I've tried it with violentmonkey on chrome and firefox, tampermonkey on chrome, and greasmonkey on firefox, and I don't see any wonky behavior. Can someone help?

398 days, 14 hours, 54 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

@Robodoc: Here is a screenshot of the conflict in action; https://imgur.com/a/ZL8UONr

I just tried to replicate it myself an at first didn't work... then though perhaps it is because the Sector didn't have an Ion Storm to display... that indeed seems to be the case as that produced the screenshot above.

Also note the text on the Map Tools menu is a bit messed up... I think your script is doing that but I'm not 100%.

I'm hoping the problem isn't in the Ion Storm Predictor script... as it might affect other scripts in the future as well.

398 days, 10 hours, 32 minutes ago

RE: Documentation for my plugins is changing. Hardware,...

Thanks, @Glyn. At least now I know what the wonky behavior looks like, although I still can't reproduce it. I've tried it in multiple sectors with both traditional and fuzzy ion storms, but everything looks normal to me.

Any other hints about how to replicate this buggy behavior?

Regarding the messed up menu, I've never seen that before. My computer must be very well behaved. :p

396 days, 18 hours, 39 minutes ago

mcnimble

RE: Documentation for my plugins is changing. Hardware,...

plugins are loaded in a specific order (you can change the order in TamperMonkey, 50% chance that you have to flip the order :) This technique https://chmeee.org/#planets.nu/McNimblesToolkitFirst should get you going).

the plugins thus register in that order with the NU code.

Which means hooks get executed in that order,

The problem is that the Ion Storm changes the Line Width from 1.0 to something big (10.0 or more), which means lines drawn by the subsequent plugins that do not explicitly set the line width, will use a previously set value.

Ion Storm should set the line width back to 1.0 (or save/restore on graphics context). Lacking that, all plugins should set things like line width once in their own draw method. Annoying, but the safest choice.

HtH.

396 days, 18 hours, 17 minutes ago

mcnimble

RE: Documentation for my plugins is changing. Hardware,...

Messed up menu is due to entries not fitting in the width provided by the menu. Subsequent words are positioned so low that they seem to be part of the menu entry below the problematic entry. Technically, a word could be below the menu, but I suppose it would be invisible in that case.

I thought I was the only one experiencing that, because I do not load fonts from servers, generally. Perhaps that is not the reason, and one or more of the entries from my plugins are 'too verbose', so to speak.

Part of the problem is NU CSS setting a fixed width, instead of fitting whatever text is provided. That is also problematic with scaling of pages/text, not just changing fonts.