Fwurg

[Mercury]

I created the following:

http://www.fwurg.net/tools/temp-planet-display/

This is not the final product so consider this a pre-alpha release, but it gives a nice overview of your worlds. To use, select your system, which will fill the other drop down, then select your world.

I plan to make a link in the planet and moon templates to the correct display.

[Chriz]

Is it possible to drop every world of the system under each other? (in orbit order)
That would give a nice overview of your system :)

Too bad it are circles and not hexagons.

[Mercury]

They were hexagons. I deliberately changed them to circles because I want to overlay them on top of the actual image of the planet and the circles easily allow you to see the planet in between in a way that is more natural then hexes with distance between them.

I see no reason why the whole system could not be displayed, though for now I don't have plans of setting up a page like that. I'm sure it would be quite easy to adjust though, just needs some code adjustments.

[Brend]

As to the corporations: my current todo list includes fixing their data on the wiki (things like zone types, and product types in the rules namespace; which will also include a 'Base Good' and 'Base Zone' data field for tools that need such information)

[Brend]

I'd like hexagons as well. Maybe that's easier with a simple canvas (that would work in all browsers too ^_^)

The Zone text requires some styling It is rather bad when viewing ic:amird in the ic:smi-halek_system (high contrast zones with dark gray on black text in them..)

And finally: the Genealogical Archive is shown as 'empty' O_o

[Mercury]

I'll look into hexagons. No need for canvasses, this works conceptually in all browsers, I just didn't look into the gradients yet. Geaneology archives are a special option I missed.

[Brend]

What gradients? I was talking about the background thingy, where you display the zone color.

That would be extremely easy in a canvas; and you would require less boilerplate HTML, so that would be better, right? Oh well -- never mind for now. But if you want to integrate this into something, the current HTML+javascript will require some revamping anyway regardless of what method is used.

[Brend]

Ah. I get the remark about the gradient now ^_^

With #ff0000 being top color, and #0000ff being bottom color. Slightly different code required for products with top and bottom color the same (but you can easily see the pattern):

Code: Select all

background: #ff0000;
background: linear-gradient(135deg,  #ff0000 0%,#ff0000 50%,#0000ff 50%,#0000ff 100%);
background: -moz-linear-gradient(-45deg,  #ff0000 0%, #ff0000 50%, #0000ff 50%, #0000ff 100%);
background: -webkit-gradient(linear, left top, right bottom, color-stop(0%,#ff0000), color-stop(50%,#ff0000), color-stop(50%,#0000ff), color-stop(100%,#0000ff));
background: -webkit-linear-gradient(-45deg,  #ff0000 0%,#ff0000 50%,#0000ff 50%,#0000ff 100%);
background: -o-linear-gradient(-45deg,  #ff0000 0%,#ff0000 50%,#0000ff 50%,#0000ff 100%);
background: -ms-linear-gradient(-45deg,  #ff0000 0%,#ff0000 50%,#0000ff 50%,#0000ff 100%);


Hope that helps. (Also: note the convergent notation in different browsers, only the old webkit is different.)

...this works conceptually in all browsers...

Yes... Well... That might be true... But this sounds suspiciously like 'in theory, this should work' :P

And another esthetical remark: the layouts of different planet sizes should really be aligned on the same center; if you swtich from large to medium, your planet moves 'up' instead of 'shrinks'. (EDIT: Do'h you already had that one.)

[Caldoss]

Non-technical observation: this looks perky! The extra zones from the Underworld feature aren't added in a 'round' manner yet, though. Just a tiny nitpick. Otherwise this is super-uber-promising.

[Mercury]

I was pleasantly surprised myself at how clear the overview of zones becomes.

The underworld is deliberately off to the side - its impossible to make a round figure with 22 or 40 zones and they represent the underworld, so they're put off to the side. Its a consequence of a non-standard number of zones (the number 1,3,7,19 and 37 were not picked at random, but specifically because they allow this type of display).

[Elmer]

It looks really cool, and I think this layout can be the start of a great planet interface to make the economy overview a lot easier and better to adjust. Brend probably already told you about it and if not: The game 'Endless Space' has some really nice interfaces for planets. It can serve as a good inspiration for our planet interface.

I can always help with thinking of a good way to display the system (as I know a thing or two about interfaces.)

[Mercury]

I am releasing the first beta version of the Planet Display. Click your zone for details. The example below is Mirda, but if you change the url to your world of choice, it should display properly:

http://www.fwurg.net/tools/temp-planet- ... d=ic:mirda

I'm looking for a way to integrate a link into the Planet and Moon templates, but I believe I need some help there. If anyone has experience with the templates, I'd much appreciate it if you could give me a hint on how to do it...

Beyond that: feedback welcome!

[Elmer]

It looks pretty awesome already, and I really like the 'edit' option on empty zones

First I was wondering why you would randomize the zones over the planet, but then I discovered that when you zoom in to much, the zone lay-out gets fucked up. maybe a possible thing to look into (although not that important.)

Maybe a little more space between the zones is nice, so the zones are not a clod in the middle of the planet. And I think the zones may have a little bigger border, or maybe a shadow. Now does it appear a little chaotic because of the enormous heap of carnival colours.

The different data blocks may have the same styling as all the blocks on the wiki, with a gradient on top of it (everything will look better with gradients).

I think it would be nice to have the complete overview of how much you produce somewhere in this screen, together with how much power you use and the population over the planets. I think it will be nice to have the complete overview of your system on one page. :)

So far the overview looks really cool, I like it. ^^

[Brend]

It looks awesome! I like the zone statistics block to the right.

Me and Elmer tried our hand at some esthetical fixes; and I have some technical remarks.

Esthetical fixes

The first esthetic fix: the circles have a normal cursor. They would be better with a .circle { cursor: pointer; } to indicate that they are clickable interface elements.

The second fix: We really like gradients, so we would propose to add the the box class to #leftmenu, #rightinfobox, #primary. The following CSS goes with this (this puts the gradient on all the box backgrounds ^_^):

Code: Select all

.box {
   background-color: #222222;
   background-image: linear-gradient(to bottom, #444444 0%, rgba(34, 34, 34, 0) 100%);
   background-position: center top;
   background-repeat: no-repeat;
   background-size: 100% 30px;
}

The third fix: The current innertext has a low contrast. We propose to just remove the color: gray; on the .innertext div rule.


Technical Remarks

Every developed zone has an onclick of: $(".circle").removeClass("selected");$("#"+this.id).addClass("selected");displayZoneData(17);

First off: where did this 17 come from? There is absolutely nothing you should do with the numbers in the <data !developed zone #Zone XX>, because people could just as well put <data !developed zone #Designated Power Zone> there (which IMHO is very good use of the data plugin). These identifiers are meant as opaque strings, and code should not rely on any meaningful content in them. This is my most important point, as this is a conceptual thing. All other implementations issues are irrelevant compared to this!

Secondly: $("#" + this.id) is better written as: $(this)

Thirdly: $(".circle").removeClass("selected");$("#" + this.id).addClass("selected"); should really just be placed in the handle method (which should not be put in the onclick, but that's a while other story).

Ideas for Improvement

Brend: Use the system as base for the tool, instead of the planet. By not reloading the page when switching to another planet, users will think the tool is faster ^_^ (This would require changing up some code though.)

Elmer: Population information would be awesome. Especially if done like in Endless Space:


But we understand that this might require some rather fancy hackings (Brend's remark: Canvas or very fancy CSS3 :P)

[Mercury]

First I was wondering why you would randomize the zones over the planet, but then I discovered that when you zoom in to much, the zone lay-out gets fucked up. maybe a possible thing to look into (although not that important.)

If you zoom in, the zones will get messed up. No way to fix that.

Maybe a little more space between the zones is nice, so the zones are not a clod in the middle of the planet. And I think the zones may have a little bigger border, or maybe a shadow. Now does it appear a little chaotic because of the enormous heap of carnival colours.

I agree but for Large Planets I need the space and its difficult to make it dynamic for various world sizes. Changing the image size is NOT a solution either. I'm open to suggestions, but there's some technical difficulties there, hence the current configuration.

The different data blocks may have the same styling as all the blocks on the wiki, with a gradient on top of it (everything will look better with gradients).

Agreed. This is something I want to improve upon in future versions but it seemed non-relevant for the beta. Also note that it looks better in IE10+ and Firefox than it does in IE9 which doesn't render ANY gradients, making product zones a lot uglier.

I think it would be nice to have the complete overview of how much you produce somewhere in this screen, together with how much power you use and the population over the planets. I think it will be nice to have the complete overview of your system on one page. :)

So far the overview looks really cool, I like it. ^^

Your request has been noted!

[Brend]

PS. I have updated code for the gradients. Replace the single background-image line with:

Code: Select all

  background-image: linear-gradient(to bottom, #444444 0%, rgba(34, 34, 34, 0) 100%);
  background-image: -moz-linear-gradient(top, rgba(68,68,68,1) 0%, rgba(34,34,34,0) 100%);
  background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(68,68,68,1)), color-stop(100%,rgba(34,34,34,0)));
  background-image: -webkit-linear-gradient(top, rgba(68,68,68,1) 0%,rgba(34,34,34,0) 100%);
  background-image: -o-linear-gradient(top, rgba(68,68,68,1) 0%,rgba(34,34,34,0) 100%);
  background-image: -ms-linear-gradient(top, rgba(68,68,68,1) 0%,rgba(34,34,34,0) 100%);


That should get you going in all modern browsers. (I use this code on the wiki too)

Your request has been noted!

We might be able to use the tax tool code for this? We should look at integrating stuff like that, instead of reinventing the wheel.

[Mercury]

Thank you for all the help and suggestions. I won't be working on the tool this evening but I will look into the issues you raised to see what I can do later!

[Mercury]

I've processed most of the above fixes but I'm running into a problem:

I'm no longer using the opaque entry title as zone identifier which means I no longer risk the whole "it might not be a numbered zone" risk, however this poses the problem of sorting the zones.

Now what I did was sort them alphabetically but of course this causes the "10 sorts before 9" problem because the first digit of 10 is smaller than 9.

My current tendency is to go back to processing the zone entry title as if it was not opaque, but I'm open to alternative suggestions...

Edit: idea -> put zone numbering in the data model

[Elmer]

do they need to be sorted? why not use the sorting as the player has it noted on his page?

[Mercury]

Is that information available? Because I have no clue how to get the index of the datablock on a page. Obviously this would work for me ^_^

The problem is current sorting is odd - example, mirda, which goes:

Zone 1, Zone 10, Zone 11, Zone 12 ... Zone 19, Zone 2, Zone 3 ...

That's clearly undesirable.

[Brend]

((Stop replying to each other while I'm writing -- you annoying forum users :P))

@Elmer: From a wiki perspective, they have no sorting. The fact that your see them in a certain order in the planet's page is because they can not be defined without putting them one after the other. From a data perspective, there is no ordering: the '#Zone 12' part in '<data !zone #Zone 12>' is just a name. Having a zone with '<data !zone #Planetary Defence Grid>' is perfectly valid, and does not give any information as to the ordering of the zone.

@Mercury: No. That information is not available (yet: it might become available in the future as a side effect of the 'warning: multiple blocks with the same id' feature).

I have given the stated problem some thought. I have a few notes, which I will post in thinking order (read as: if anything is unclear, I take the blame, and you should ask for a clarification.)

"10 sorts before 9"

This is indeed a problem. Of course, this is a well known problem (ASCII just doesn't sort in a way that's even remotely human-logical). To solve it, we have the 'natural order' sorting algorithm. Below I present the case-insensitive variant of this (courtesy of Dave Koelle, under the LGPL license):

Code: Select all

/* ********************************************************************
 * Alphanum sort() function version - case insensitive
 *  - Slower, but easier to modify for arrays of objects which contain
 *    string properties
 *
 */
function alphanumCase(a, b) {
  function chunkify(t) {
    var tz = new Array();
    var x = 0, y = -1, n = 0, i, j;

    while (i = (j = t.charAt(x++)).charCodeAt(0)) {
      var m = (i == 46 || (i >=48 && i <= 57));
      if (m !== n) {
        tz[++y] = "";
        n = m;
      }
      tz[y] += j;
    }
    return tz;
  }

  var aa = chunkify(a.toLowerCase());
  var bb = chunkify(b.toLowerCase());

  for (x = 0; aa[x] && bb[x]; x++) {
    if (aa[x] !== bb[x]) {
      var c = Number(aa[x]), d = Number(bb[x]);
      if (c == aa[x] && d == bb[x]) {
        return c - d;
      } else return (aa[x] > bb[x]) ? 1 : -1;
    }
  }
  return aa.length - bb.length;
}


This method is intended for consumption as a comparator with javascript's Array.sort method.

Zone numbering in the data model
While I would usually be opposed to adding such 'aesthetic' information, I think that in this case this might be warranted. While the zones on a planet have no identifiable ordering per se, it could help the user if the zones have a stable ordering. (Especially if the user views the zone identifier is 'their' name for it.)

This would require a numbering of all zones on all planets... Of course, if we ever have magic editing power, we should allow the user to reorder the zones in the planet view just by dragging them around...

Conclusions
Maybe a best-effort approach is the holy grail? I know I was rather adamant that the identifier not be used -- but you could try and see if the identifier matched /Zone [0-9]+/ (a javascript regular expression), and sort those to the front in numeric order to fill out the planet. Then smack the rest into the 'special zone' slots.

You could even do trickery like seeing of there is a 'Planetary Defence Grid' id, and put that in a special zone in the top right of the display; or other funny stuff. (Which would be much easier if the Planetary Defence Grid completed_project data would reference the created zone.)

[Mercury]

Does the wiki plugin offer alphanumerical sorting of this kind? I can't seem to get the sorting to work even with your algorithm (the problem isn't your algorithm)

[Brend]

Errr... no. SHould I have a look at the code?

(It doesn't sound like it should be very difficult in all honesty: worst case: grab al identifiers and drop them in an array, sort the array with yourArray.sort(alphanumCase), and out comes a sorted list. Though you should really sort on the 'entry title' field, which would require wrapping this in another comparator that grabs the correct fields from the objects in the array.

Give me a holler if you want a second pair of eyes!

[Mercury]

Actually, I just figured out it was because of a typo. Nm, I have it fixed!

[Brend]

(I am fully aware of the cross-setting post.)