Fwurg

[Mercury]

In the :dot: format, zero is represented by ○ while one is represented by ●. Mirda has an offensive capability of 0 in all three rings, but the wiki lists this as dot1 or ●. This should be ○. It appears to be either a template or a data-type bug

[Chriz]

Mirda currently houses the Veolian Army. The template does not mention this but it does calculate it in its dots.

[Mercury]

That's not good! That means my code for displaying a planets military stats in the system viewer is not correct :(

[Brend]

@Mercury: exactly.

This isn't a bug. Mirda's base defences don't have any offensive capabilities. The offensive dots on mirda come from the Veolian Imperial Guard (which has 1/1/2). These dots are automatically summed with the planet, as the army is currently not attached to a fleet (in which case they would be summed with the fleet). This works in the same way for Planetary Defence Zones, in which the distrubtion of combat dots is stored with the zone and summed with the planet.

This is rather clear in the template, where the query for all combat stats starts with:

Code: Select all

<view>
template {
  military_combat_statistics
}

I'm not sure whether you actually looked at the template to see what's going on. And I agree with Chriz, that the Mirda page does not clearly list what armies are stationed on Mirda (which it should!). And now that I had a look at the template again, it seems that the template is actually incorrect: it doesn't add the defence forces' points.

I see how this is confusing given the lack of links to the army, and I like to get this opportunity to detect an error (both the 'no mention', and the 'no defence force' problems). But I would much appreciate it if people (again, I'm not sure whether you did) would first try to see what's actually going on before throwing around bug reports.

I will update the query to include defence forces today (but I have some other things to take care of first).

[Mercury]

Actually, I did investigate the issue when I noticed my system display listed an empty dot while the wiki page listed a closed dot. This seemed odd to me, so I checked if perhaps my handling of the dot string was off. It seemed okay, so upon investigating further, I found very clearly that Mirda listed "Offensive Attack: 0" and that it displayed a full dot instead of an empty one, while my system viewer correctly displayed the value of 0 as it is listed in the data.

Almost all data on the wiki is copied directly from the fields listed and displayed as such. For example, even if a zone is specialized you need to manually add the +corp to the icon data to actually get specialized data, despite the fact that a template could probably do this automatically. Thus, upon seeing the value of 0 listed on the Mirda page, with a different associated display, I naturally concluded this was a bug. I'm glad it wasn't.

At this time however that means I don't have a way of determining the combat scores for a world without additional queries, despite the fact that worlds list these scores. Perhaps this is something we need to look at at a fundamental level.

[Brend]

We have derived values at some places: the stories are another good one. And that corporation thing will be derived once I am done with the corporation data overhaul.

At this time however that means I don't have a way of determining the combat scores for a world without additional queries, despite the fact that worlds list these scores. Perhaps this is something we need to look at at a fundamental level.

I am not sure what you intend to say there, but my first reaction was very negative -- so I will refrain from replying until I have reread this a few times, or some elaboration comes along.

[Mercury]

To clarify, I think at the level of the data model it is incorrect to have an object actually list a value such as its "Offensive Attack", but to then not have that value be its actual Offensive Attack. The listed score for Offensive Attack in the Mirda datablock is in reality only the base for the offensive attack and additional calculations are necessary.

Imho, this is counter-intuitive. I would propose that either Mirda lists its exact score after all modifiers (preferred for me since it allows simple planet templates and tools) or alternatively, the world should not list an Offensive Attack score at all, and the entire value should always be calculated.

[Brend]

You misinterpret the data model: the value listed for Mirda's offensive attack is Mirda's offensive attack. This is however modified by things such as armies (just like a Jedi's base combat stat Force Level is modified by equipment and combat styles) -- and we're not stashing the full combat stats on the Jedi either... The problem is that a world does not have a nice single base stat: it has six of them; and that's why they're all represented. Just like you said: it is "only the base for the offensive attack and additional calculations are necessary".

(Note for the record: RemcoSwenker and I had them as Base Outer Attack, but we changed it for consistency.)

If you want Mirda to list its exact scores, that would entail the user painstakingly adding all values by hand; which is something that is counter-intuitive to me (and experience has shown that this is prone to error). Furthermore, if we go down that road, we should really ask users to do some other calculations by hand as well, after all -- you can then fetch the data in a single query.

I am in favour of deriving as much as possible, and interlinking the data where-ever possible. This might require you to write some creative queries, and in some cases run one or two extra queries, but that should not be the users burden to carry. (For example: the 'Specialised By' field on zones has proven to be derivable, as the real link to the corporation is the Zone Type of the zone.)

<rant>
To me it seems that tools should work for the user, instead of your preferred other way around: what you propose is basically pushing work to the user because it would greatly convenience your tool-writing.

Of course, I get why you don't want multiple queries: they will increase the pre-load time of your tools even more. But that's exactly why I suggested not loading all data up front. But it seems you are adamantly set against not pre-loading everything, so I won't try to argue the point.

This seems to be just the same issue as with your proposed (and pushed-through) fix of the jackpot special, which also seems to have been for the reason of 'my tool writing is hindered by the data model'. And I still fail to see why that was necessary, to be honest.

While writing this, I have realized that for me discussions such as these really take the fun out of doing things for FWURG. As it seems impossible to reconcile your view on the matter with mine, I'm afraid that I'll just have to stop caring about the underlying principles of FWURG (which could be rather difficult, as I care a great deal about the game). After all, in the end, the Jackpot 'fix' was also pushed through, so I don't want to waste my time on arguing that you should really just derive the values and fix your pre-load issue in some other way -- you'll probably pre-load the data anyway and make users wait for five seconds just so they can view a single planet, update the wiki, and wait another five seconds to review the planet.
</rant>

You could remove the Offensive ratings from worlds. But you would need to put them back as soon as a single technology, special project, racial characteristic, special or other gimmick put a base value on the world. So I say we keep them, and you derive the values through a query.

[Mercury]

Every query costs up to 2 seconds. The more complex the data model with regards to links, the more queries must be done consecutively rather than in parallel, adding up the time cost. You want a snappy response time, you pre-load the data.

[Brend]

Yeah, but that's the point: people don't want to wait for seconds when they just want to check their population growth or look at a single planet. And you have to preload all data every time you (re)load the tool. But, 'it works' is a good quality too :)

[Mercury]

Yeah, but that is also my point. If I load data on the users click, they STILL have to wait two seconds, only now they have to wait every single time they click instead of only once at load time. And those two seconds are local here with a 2 meter 1gb line between the machines. If using the internet, round-trip time is added to this in addition for each query.

[Elmer]

With my lack of knowledge: you do not load all data at once, only the needed data. If you startup your computer you do not start all programs at once. In fact, you start up as little as possible to increase response times.

Most people prefer to wait 10 times 2 seconds, than 1 time 20 seconds [citation needed]. Why would I load the data of the economical production of the Daryas when I am interested in the population growth of the Teprogrena?

But then of course, once the data is loaded, it would be a waste to load them again if you click the relevant button again.

[Mercury]

The load time is not created by the amount of data transferred. Its created by general overhead for each query. If I do one query which gets the economic production of all factions, the increase in load time over getting the economic production for Darya only is negligible compared to the cost of doing another query. So I'd rather spend 1800 ms loading the data for all players than 1500 ms for loading the data for one player and then another 1500 ms if a user clicks a button to load for the second player.

I agree 1 time 20 seconds is worse than 10 times 2 seconds, but 1 time 3 seconds is not worse than 10 times 2 seconds.

Edit: correction, there is SOME relationship between data volume and load times. That said, query overhead is still the dominant cost factor, from what I can see.

Data sample: loading zone data for 1 planet takes up 1250 ms, loading zone data for an entire system takes up about 2000 ms.

[Brend]

The overhead is indeed large. But that is one of the reasons I proposed not preloading everything...

Maybe we have different ideas on how this non-pre-loading would work? What I see is that you coded a chain of requests, as you need some information from the first results to form new queries. What I proposed was already showing the information you have to the user, so it seems as if he had to wait less (of course, he still has to wait; it just seems snappier becuase he already sees the planets in the system while waiting for the zone information to load.)

If you interpret non-pre-loading as 'waiting for load time with each click' (which I get from your previous post) then yes, that wouldn't work very well.

[Mercury]

I can show certain information when I load that, but this means the screen continues to dance with changing values, buttons need to be enabled and disabled, place-holder values may need to be set and replaced, etc. This all creates a circus of events both behind the screen and on it.

I don't know about you, but my eye is immediately drawn to screen changes, like a freaking twitchgame. So if I show some data and then some more and then some more, my eyes are jumping all over the screen until everything is loaded before I have time to actually read anything. A loading bar which is then replaced by all the data in one go is way easier on the eyes and a tool where you cannot read information because everything is dancing is not very useful anyway, at least until it stabilizes.

[Mercury]

For example, I can show the system in the system viewer a little sooner than I show the zones, but then when you click a planet to actually show that, the interface does not react correctly and shows you garbage, even while everything on the screen is still changing.

Moreover, you could have clicked away from your current planet, see it load (with invalid data) and then have it replaced by the data you were originally loading, thus losing your click.

I prefer waiting until the entire thing is done over that.

[Brend]

In agree that you don't want a circus of visual changes. But that's not what I'm talking about :'(

It seems I am (once again) unable to communicate my full intentions over the forum. I'll refrain from further trying to explain it over this medium.