Difference between revisions of "User:Geoff the Medio"

Revision as of 17:19, 4 April 2005

forum profile

Musings

Emails to tzlaine Dump

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...