User:Geoff the Medio

From FreeOrionWiki
Revision as of 00:40, 4 May 2005 by Geoff the Medio (Talk | contribs) (link to testing notepad for bugs from email dump)

Jump to: navigation, search

forum profile

Musings


Emails to tzlaine Dump

Note: the bugs from the following have been rewritten on the Testing Notepad in a much more usable form.

1

For moving things around in the queue, it would be rather nice if the # Turns indicated on the box for the tech changed as you dragged the box up and down the queue. The number would indicate the number of turns it would take if you dropped the tech at the location where you current have it dragged. This way, you wouldn't have to actually drop it to find out how long it would take in a particular queue position. (You could also update all the other techs on the queue to show how long they would take if you dropped the tech you're currently dragging.)

IMO the double clicking (a tech on the queue) to remove from the queue isn't very intuitive. It also has the somewhat annoying side effect of centring the tree on the removed tech...

Could you add the ability to drag and drop a tech from the queue onto the tree window to remove it from the queue?

Similarly, being able to drag from the tree onto the queue might be good, though double clicking to add is sufficient for me... I note that you can't scroll the tree view by clicking on a tech and dragging, so there's no lost functionality if clicking on a tech and dragging has the same effect as it does for tech boxes on the queue.

2

A minor complaint: If I expand/collapse the subtree off a tech, the tech moves. It would be much more intuitive if that tech stayed in place, with just the stuff around it changing.

A semi-major complaint / request, that I doubt you'll be able to fix: It would be nice if techs were spaced horizontally according to the number of prerequisites they have.

This would be based on the longest path from the tech back to a tech with 0 prereqs. It would ensure that all 1st-tier techs (with 0 prereqs) are at the left edge of the tree, and all 2nd tier (with all prereqs having 0 prereqs themselves) would be at the same distance immediately to the right of 1st tier techs, and all 3rd theirs (all prereqs having 0 or 1 prereq them selves, and at least 1 tech with 1 prereq), etc.

It's rather odd looking now to have a 1st their tech floating around some 3rd tiers, as happens now with Orbital Construction and Industrial Farming in the All view (assuming your tech view displays the same as mine).

This is especially problematic in that it's hard to see much of the tree, and there's no quicklist of currently researchable techs, so unless you hunt around looking for every last tech, you could miss some currently available techs because they aren't grouped logically together near other techs of the same tier.

A related request: An alternate view in the tree window that just lists all techs, appropriately colour coded for available/researched/unavailable, in alphabetal order by category/all would be good. A few minutes ago I was trying to find a tech (Environmental Encapsulation), but couldn't remember what category it was in. It was rather difficult to find it. The alphabetical list could go in place of / alternate with the tree view, since you'd only need one or the other at any given time. Being able to sort by cost / research time would also be nice.

Also, a minor thing: The Requires / Unlocks listings at the top right could be compressed vertically. There's a lot of wasted space in there... You could chop about 6 pixels off the height of each tech box without problem, I think. An extra tech or two could then fit into the window without scrollbars.

You can't enqueue a tech that's not currently available (ie. for which not all prerequisites are known).

This is problematic because it means we can't enqueue a long series of techs, which means that a) the player has to keep going to the research screen to enqueue new stuff, even if they knew what they wanted beforehand, and consequently b) we won't be able to save / load research queues which include techs not currently available.

Various people have been quite keen on the idea of saving / loading queues...

It's hard to immediately know which category you're looking at in the tree view, especially after clicking on a quicklink at the top right. I realize that the tech you click is shown in the top middle tech info box, but the tech shown there isn't always in the category of the tree being shown, so isn't a reliable indicator of what category view you're looking at.

Could you make the buttons look like tabs, as in BreadMan's mockup, or could you highlight the button of the techview currently being shown

3

I figured I should check what would happen if we added a few more tech categories (see attached). ((NOTE: TEXT DIDN'T FIT IN BUTTONS IN IMAGE))

I'm not sure what to do about this...

Scrollbars for the buttons would be annoying... Going to multiple rows of buttons might work, I suppose... Adjusting the size of the buttons for the length of the text wouldn't look very good, I suspect.

I suppose you could make the buttons toggles that work independently that include or exclude each category's techs from the tree, rather than just having the "all" view and a view for each category. You could then toggle on any combination of categories you wanted to see, and get rid of the "all" button, to save some space... though if you did the toggle thing, having "all" would still be desirable (as clicking all the buttons each time could get annoying), and this would only add extra space for one button, which might not be enough extra room, especially if there are any more categories than my test added.

4

Add controls in-game to adjust autosave settings. Current command-line or config.xml options:

--autosave.multiplayer
    If true, autosaves will occur during multiplayer games. | Default: 0

--autosave.saves
    Sets the number of autosaved games that should be kept. | Default: 10

--autosave.single-player
    If true, autosaves will occur during single-player games. | Default: 0

--autosave.turns
    Sets the number of turns that should elapse between autosaves.
    Default: 5

5

Bug: single planet view crashes when switching to "No Building"

6

In a recent CVS update comment: "...also changed the same code to always show moving fleets first in the list."

I won't be able to get the updated code from CVS to check for at least a few hours, so I'm asking via email:

Does this mean that if one selects a fleet, then gives it a move order, it will change position in the list of fleets in the fleets window?

If so, is this change immediate, or only after closing and reopening the window, or doing something else like destroying or merging fleets or ending the turn?

If the ordering of fleets in the list changes significantly during a turn for reasons other than the player specifically doing the reordering (drag-drop or clicking a sort button), it could be confusing and difficult to keep track of which fleet is which... Though perhaps I'm overreacting? Even if I am, IMO it would still be better to use a marker icon or text on the fleet's box in the list of fleets to indicate orders given to the fleet, rather than reordering the list using an autosort by order type.

The icons would be in addition to the textual indication below when each fleet is selected. This could also be extended later to cover additional orders as they become implemented... for now "Moving" and "Idle" or somesuch would be sufficient, or appropriate icons. Later we could have "Patrol", "Blockade", "Intercept" or whatever is relevant. Indicating move destination or target of the fleet (when applicable) on the fleet box might be nice, but there's probably not enough room.

The icons don't need to be pretty right now, so it shouldn't be an art issue limiting such a feature... Even a red circle (or octagon) and a green circle for stopped and moving would be sufficient.

7

I actually made a tech with some effects to try in game, and I note that you've included the text effects summary in the research UI. IMO this is not a good idea, given how complicated and confusing some of the effects can get. It'd probably be better if you removed this, and we instead used the tech description to explain what effects the tech has...

Also, I made a tech with an effect (+1 Max Pop to all planets). The turn I research the tech, the increased population didn't show up... (though it did the next turn).

Also also, my effect gave +1 Max Pop to all planets, which includes asteroid belts. This allowed me to colonize an asteroid belt, which I did (which isn't a bug, as far as I know). However:

The next turn, my asteroid belt colony died due to starvation. This is odd, as I had plenty of extra food.

I'm not going to fix this unless you find that it happens onsomething other than an asteroid or gas giant slot. These are not supposed to be colonizable anyway. And, after the colony died, the asteroid belt has a "cancel" button (as though I had ordered it to be colonized that turn). Clicking cancel crashed the game.

Well, we might later change things so that planets that can't be colonized at all later become colonizable with advancing tech. This could apply to both main EP-wheel planets far from your race's ideal environment, as well as to asteroids or gas giants. For v0.3 you're OK though...

And this will be very annoying for writing effects that fire on mutiple planets. ie. we'll have to explicitly limit the types of planets that the effect fires on to those other than asteroids and gas giants. (I know... "welcome to programming"... but this will make scope conditions significantly larger... enough to make it worth fixing if there's no workaround, IMO)

In the hopes of finding a workaround:

Is a colonizable planet that hasn't been colonized a popcenter?

If they are not popcentres, if I make a tech with an effect that gives +1 max pop to all popcenters, would that effect apply to future popcenters that didn't exist at the time the tech was researched? (eg. colonies created after researching the tech.)

If the effect would apply later, that eliminates the above problem, in that the +1 to max pop effect could be made to just fire on popcenters, eliminating the need for complicated scope conditions to avoid firing on noncolonizable planets.

This would create a bit of a UI problem though, in that the planet size ( = max pop) of uncolonized planets wouldn't be accurate, as it would change after the planet was colonized, which would be annoying / confusing for the player. If this is the case, can you fix it?

If a colonizable planet that hasn't been colonized is a popenter, then the scope of the effects group (that has the +1 to max pop effect) could be set to only include popcentres that have max pop > 0. However, I'm not sure such a condition could be written, as the MeterValue condition checks for meter_value >= low, not meter_value > low. Is there a way to do this?

Again, in this case, would an effect in a group on a tech or building that increases max pop apply to colonies created after the tech was researched or building built?

Also, regardless the effect-induced colony starvation leaving a cancel button bug, the sidepanel indication of planet max pop (and other info, presumably) should update the turn you learn a tech, not the turn after. This applies to all planet types.

8

I'm having trouble figuring out how to make a building with an effects group that only fires on the planet on which the building is located.

I figured using this scope condition:

<Condition::Contains><Condition::Self/></Condition::Contains>

would work, but building-check reports this:

Objects affected: Any object that contains an object

This seems to contradict the description for <Condition::Self/> in the wiki:

Descr.: Matches the source object only.

What building-check reports is what I would have expected for the following scope condition:

<Condition::Contains><Condition::All/></Condition::Contains>

So is what building-check is saying correct? If so, how do I have a building that has an effects group that only fires on the planet on which the building is located? (And not any planet containing a building of the same type as the source building...)

It looks like the text description is just wrong. The description code is pretty simple so far, and this is a situation that has not been allowed for. I believe that that condition does in fact work as you intended.

9

I have a tech with an effects group with the following scope:

<scope>
 <Condition::And>
   <Condition::Type>OBJ_POP_CENTER</Condition::Type>
   <Condition::FocusType>
     <primary>1</primary>
     <FocusType>FOCUS_RESEARCH</FocusType>
   </Condition::FocusType>
 </Condition::And>
</scope>

tech-check, and in game, the scope is listed: Objects affected: Any object that is of type population center and that has primary focus balanced or research

Balanced shouldn't be in there. I'm not sure if it actually does affect balanced focus pop centers yet, but I'll test some more...

Update: The effect does not seem to fire on balanced focus planets, so it's probably just a text description issue.

10

I made a tech that creates a special which has this effect:

(summary below if you don't want to read it)

<EffectsGroup>
 <scope>
   <Condition::And>
     <Condition::WithinDistance>
       <distance>1</distance>
       <condition>
         <Condition::Type>OBJ_POP_CENTER</Condition::Type>
       </condition>
     </Condition::WithinDistance>
     <Condition::FocusType>
       <primary>1</primary>
       <FocusType>FOCUS_MINING</FocusType>
     </Condition::FocusType>
   </Condition::And>
 </scope>
 <stacking_group>TEST_SPECIAL_GROUP</stacking_group>
 <activation>
   <Condition::Self/>
 </activation>
 <effects>
   <Effect::SetPlanetType>PT_GAIA</Effect::SetPlanetType>
 </effects>
</EffectsGroup>

This should, I think, set the environment of all pop centers (planets) within distance 1 of the planet with the special, and which have primary focus mining, to Gaia.

This reveals two bugs:

Bug 1) When the special is added to a planet (controlled by focus condition check on the addspecial effect), every planet in the universe is changed to Gaia environment, regarless of whether it is populated, what its focus is if it is populated, or its distance from the planet with the special.

Bug 2) The max population of the planets that were originally asteroid belts or gas giants are not updated to reflect the change in environment to Gaia. (See the attached image.)

Sorry, I guess bug 2 (in quote) is due to the size of the planet still being SZ_ASTEROIDS or SZ_GASGIANT. Could you / will you implement some sort of fix for this, or is it something we'll have to check for in the effect description? Doing so would be awkward, and in some cases impossible, without a nested-if type structure...

11

I decided it would be more helpful to do a more controlled test of effect conditions, so I made a tech with an effect whose scope is all planets with primary focus research:

<scope>
 <Condition::FocusType>
   <primary>1</primary>
   <FocusType>FOCUS_RESEARCH</FocusType>
 </Condition::FocusType>
</scope>

Nothing happens on the turn I research the tech, or the turn after, but on the turn after, the effect fires on all planets with Primary Balanced focus or Primary Research focus. This includes uncolonized planets.

In tech-check or the tech description in the research screen, the scope condition is listed as "Any object that has primary focus balanced or research".

12

1) If all the ships in a fleet are destroyed by the Destroy effect, the fleet itself is not removed. When you click on the fleet icon or press "f", the game crashes.

There may also be problems with removing one ship, but I can't test this because figure out a way to remove just one ship in a fleet, rather than all ships in one fleet, without using the chance condition, and:

2) The Chance condition format is not accepted. If I use the format given in the wiki,

<Condition::Chance>
 <chance>0.3</chance>
</Condition::Chance>

the game crashes, and tech check gives this output for the tech:

ERROR: ZHP_EXAMPLE [Theory tech] ERROR: ZHP_EXAMPLE_DESC ERROR: ZHIPS_CATEGORY 1 RP / 1 turns

[No prerequisites.]

[No unlocked items.]

Effect 1: main() caught exception(std::exception): boost::bad_format_string: format-string is ill-formed

This happens whether the condition is used in the activation or scope sections.

13

Ok, I tried again with this effects group: ((ON A TECH THAT I RESEARCH))

   <EffectsGroup>
     <scope>
       <Condition::MeterValue>
         <meter>METER_RESEARCH</meter>
         <low>24</low>
         <high>999</high>
         <max_meter>1</max_meter>
       </Condition::MeterValue>
     </scope>
     <activation>
       <Condition::Self/>
     </activation>
     <effects>
       <Effect::Destroy/>
     </effects>
   </EffectsGroup>

And this is extracted from the save file a few turns after learning the tech with that effects group:

   <m_research>
     <Meter>
       <m_current>15.66666666666667</m_current>
       <m_max>30</m_max>
     </Meter>
   </m_research>

Which happens to be from my homeworld, but shouldn't be possible on any objects. This happens whether I set focus to raise the meter value before or after researching the tech.

Interestingly, changing the above effect so that it checks the current meter, not the max, does seem to work. I got the current meter above 30, then researched the tech, and the planet disappeared the turn after.

Researching the tech first, then raising the current meter works intermittantly... my first few tests crashed the server about 5 turns after the meter got above 25 or so. The crash was about 5 turns after the meter got high enough... (I think...). My last test didn't crash though, and the effect seems to have worked correctly, as the planet is now gone, and the server hasn't crashed.


14

4) I set up an effect with this scope:

     <scope>
       <Condition::FocusType>
         <primary>0</primary>
         <FocusType>FOCUS_INDUSTRY</FocusType>
       </Condition::FocusType>
     </scope>

tech-check gives this for the scope text:

Objects affected: Any object that has primary focus unknown or industry

In game, the effect fires if the focus is primary industry. Secondary industry has no effect, nor do other focii as far as I can tell.

I was under the impression <primary>0</primary> meant to check the secondary focus. (Just making sure...)

That's correct; it's probably another description bug.

It's not just a description bug... The condition should be checking the *secondary* focus, not the primary.

15

We previously discussed the RefineBuildingType effect, and how it allows adding of effects groups, but not removal. You suggested adding the opposite effect, where possible, to achieve the same thing, but this is rather unsatisfactory and limiting. So, I'd like to work out a way to make it possible to remove effects groups that you won't find too time-consuming or difficult to implement...

How about giving effects groups an optional text identifier tag (somewhat like stacking group)? To remove an effects group from a building type, you'd include an id tag in the effects group's description, and then indicate the id tag of that group in the appropriate effect description. New effects groups would be added the same way they are now (and could include id tags as well...)

Is there a huge design problem with this I'm not anticipating, or an underlying technical reason why removing effects groups would be problematic?

16

The AddOwner effec thas some odd results...

Here's my tech:

<Tech>
 <name>ZHP_EXAMPLE</name>
 <description>ZHP_EXAMPLE_DESC</description>
 <type>TT_THEORY</type>
 <category>ZHIPS_CATEGORY</category>
 <research_cost>1</research_cost>
 <research_turns>1</research_turns>
 <prerequisites></prerequisites>
 <unlocked_items></unlocked_items>
 <effects>
   <EffectsGroup>
     <scope>
       <Condition::PlanetType>
         <PlanetType>PT_OCEAN</PlanetType>
         <PlanetType>PT_TERRAN</PlanetType>
         <PlanetType>PT_OCEAN</PlanetType>
         <PlanetType>PT_BARREN</PlanetType>
       </Condition::PlanetType>
     </scope>
     <activation>
       <Condition::Self/>
     </activation>
     <effects>
       <Effect::AddOwner>Source.Owner</Effect::AddOwner>
       <Effect::SetMeter>
         <meter>METER_POPULATION</meter>
         <value>50</value>
         <max>0</max>
       </Effect::SetMeter>
     </effects>
   </EffectsGroup>
 </effects>
</Tech>

After researching the tech, each turn I get a whole slew of sitrep entries about "Your population at planet ERROR in system has starved to death" (there's an extra long space between "system" and "has", incase gmail decided to remove it for me)

I then have ownership of all the populated planets in the game (all enemy empires have homeworlds on terran planets), but all the systems are shown as half owned by me, and half owned by them... I'm not sure if a single planet can have shared ownership, but there's no indication of this on the UI if it can.

Parts of the UI also slow to a crawl. Dragging the map around is very sluggish or jerky, with about a quarter second delay between mousemove and graphical update. Dragging the sitrip around the screen is just as jerky, as is scrolling up/down through sitrep entries, or the sitrep scrolling is sometimes nonresponsive. Dragging fleets windows around seems to work fine, however, and the UI in the fleets window seems response, and giving move orders seems to work fine.

I'm also a bit unclear as to why all those planets are starving... I have plenty of food available. Unless maybe there's a quirk in the population loss algorithm so if you have waaaaay more population than the max, they all die... (I'm setting current pop to 50... though actually I haven't specifically tested the effect to set current meters... maybe I should do that...)

The server should also probably be updating me with info about those systems, like their names and starlane connections and contents, in addition to not killing all my people on thim... though I suppose that requires a full turn of colony ownership, which I suppose I'm not getting if they're all dying...

17

2) I imade a SetEmpireStockpile effect, and running it through tech-check gave this output:

Effect 1: Effect is always active Objects affected: Any object Sets the stockpile of mineral of the object's owner to ERROR: 9234

3) The effect seems to work in game, though the number I specified to set the stockpile to, 9234, was shown as the the number in brackets, which was a bit unexpected...

18

Now we need to show stockpile numbers somewhere.