Difference between revisions of "Programming Work"

From FreeOrionWiki
Jump to: navigation, search
(Referenceable Object Properties)
(Misc)
Line 18: Line 18:
 
* Replace deprecated functions for file control operations from fcntl.h used in FileAppender.cpp from log4cpp with maintained logger.
 
* Replace deprecated functions for file control operations from fcntl.h used in FileAppender.cpp from log4cpp with maintained logger.
  
* Modify ClientUI::GetFont and related title / bold font functions to check the validity of the font they attempt to get, and to try again to get the default font if the first attempt fails.
+
* Modify ClientUI::GetFont and related title / bold font functions to check the validity of the font they attempt to get, and to try again to get the default font if the first attempt fails.  The GG::GUI::GetFont function thows a GG::Font::BadFile exception when there is a problem getting a font for the first time.  The call in ClientUI::GetFont could be put in a try-catch block for this exception, and if it is caught, another call to GetFont could be done using the default value of the "UI.font" option.
  
 
* Add a binary flag and related checkbox in the options screen to make the game use the default location for the resources directory, rather than using the version stored in config.xml.  Currently, if more than one freeorion is installed on a system, and their resources directories contents are incompatible, it's necessary to delete the config.xml every time to make the game use the proper set of resources.  With this switch, the game would automatically determine its own resources location (using the existing code that determines the default location of these files) and both versions could be run and would use their own, separate, automatic default locations for the resources dir without requiring the user to update it each time the version is changed.
 
* Add a binary flag and related checkbox in the options screen to make the game use the default location for the resources directory, rather than using the version stored in config.xml.  Currently, if more than one freeorion is installed on a system, and their resources directories contents are incompatible, it's necessary to delete the config.xml every time to make the game use the proper set of resources.  With this switch, the game would automatically determine its own resources location (using the existing code that determines the default location of these files) and both versions could be run and would use their own, separate, automatic default locations for the resources dir without requiring the user to update it each time the version is changed.

Revision as of 12:06, 16 July 2011

A list of things that must, should or could be done by programmers.
Please, only programmers change this!

Ask Geoff the Medio if you'd like to help, or need help, with a programming task on this page.


Misc

  • Keep MSVC and XCode project files and CMake build files updated (if anyone adds or removes source files)
  • Replace deprecated functions for file control operations from fcntl.h used in FileAppender.cpp from log4cpp with maintained logger.
  • Modify ClientUI::GetFont and related title / bold font functions to check the validity of the font they attempt to get, and to try again to get the default font if the first attempt fails. The GG::GUI::GetFont function thows a GG::Font::BadFile exception when there is a problem getting a font for the first time. The call in ClientUI::GetFont could be put in a try-catch block for this exception, and if it is caught, another call to GetFont could be done using the default value of the "UI.font" option.
  • Add a binary flag and related checkbox in the options screen to make the game use the default location for the resources directory, rather than using the version stored in config.xml. Currently, if more than one freeorion is installed on a system, and their resources directories contents are incompatible, it's necessary to delete the config.xml every time to make the game use the proper set of resources. With this switch, the game would automatically determine its own resources location (using the existing code that determines the default location of these files) and both versions could be run and would use their own, separate, automatic default locations for the resources dir without requiring the user to update it each time the version is changed.
  • Stringtable entries can be formatted with <i>italics</i> or <rgba 0 255 0 255>colours</rgba>. It would be nicer if there were a few named colour tags available instead of requiring the clunky rgba as illustrated. <red>, <green>, <blue>, <white>, <black>, <defaultcolor>, etc. could be handy.
  • Modify the Process class implementation so that AI process / thread priroity is modified intelligently. Presently, as soon as the server sends out turn updates, all AI clients run a full priority and use up all the CPU (at least on a dual core system with > 8 or so AIs). This means that even though the client has received its turn update, it sits showing the player "Downloading new game state" until all the AIs have finished playing their turns. Then the AIs sit idle waiting for a new turn update until the player ends his/her turn. It would be better to have the server send messages to the AI clients to get them to modify their process priorities, or to directly modifiy those priorities if possible, in response to player actions. In particular:
    • While processing turn updates (all player orders received, executing them and updating gamestate, sending out new turn updates), the server process should be high priority, and the AIs low priority.
    • While the human player plays his/her turn, the AIs should stay low priority, only using a CPU when there is some extra to spare. This is so that the human client gets lots of CPU to process its turn update immediately after receiving it and let the player play their turn in a responsive UI.
    • When the human player ends his/her turn, if the AIs aren't finished their turns yet (the server hasn't received all AI turn orders), the server should set any AI processes that still have to send in their orders to high priority, and set each AI process to low priority again as soon as the server receives that AI's orders.
    • The client should always be high priority.
  • Make planet appearance on the sidepanel vary depending on its in-game state, including presense of specials (including a Gaia special) or industry meter level. Planets should also have separate night-side textures (lights in dark), and be able to have ring systems surrounding them (mutually shadowing with planet), and battle damage (if not treated as a special). There are currently hard-coded adjustments to rotation speed or axial tilt, but these would be better treated as scriptable properties of the specials themselves. A future-proof / extendible format to specify this sort of change, or other appearance alterations of in-game objects due to specials (or other similar content types) would be useful. Note that this is probably not suitable for a first-time contributor, as it likely requires significant artist interaction and understanding of how FreeOrion planets, effects, techs, and other content work, both conceptually and in-code.
  • Currently all keyboard bindings in-game are hard-coded. It would be much nicer to have a GUI or configuration file-based method to reassign keys. Likely key bindings could be stored in config.xml the same way other information is stored in it. Entries in config.xml can be added by adding a function like void AddOptions(OptionsDB& db) in the anonymous namespace in ClientUI.cpp or MapWnd.cpp in files that don't already have one, or adding entries to an existing function of that sort in the file where a stored windows position needs to be retreived. There should be a new option for each action a keypress can take, and the stored value would be some representation of the keypress or keypress and modifier key (eg. shift, ctrl, etc.). MapWnd::ConnectKeyboardAcceleratorSignals and MapWnd::SetAccelerators need to be modified to get the keys to bind to various commands from the options DB using the standard GetOptionsDB().Get<TYPE>("option-name-text") lookup. It might be possible to make the option TYPE std::pair<GG::Key, GG::Flags<GG::ModKey> > to store the key + modifier combination, but I don't know if this will automatically convert to text, and if so, if the conversion is easily editable. If not, a bit of custom code to convert to and from a string representation would be needed.
  • Change victory conditions so that players can continue in the same galaxy after defeating all other empires PARTLY DONE IN SVN, should they be so inclined. Optionally, add multiple victory conditions and a way to choose between them during galaxy setup. Perhaps start or continue a forum discussion about what victory conditions there should be.
  • Shaders, shaders, shaders. Competent GLSL programmers are welcome to write swanky visuals and effects via shaders, for use in the combat demo or on the galaxy map or related screens.
  • Visual effects. If you have some interesting particle, shader-based, or GL fixed-functionality special effects, such as for explosions, or shield effects, or ray guns up your sleeve, please contact Tzlaine.
  • Write initial Python AI. Note that most or all of the high-level game design is in flux as we add features. The lower-level stuff (like how to move around and select targets in the combat system) may be possible to write once and for all right now. It would be good if the AI could be updated to build ships and buildings and research techs.
  • Improve and extend the functions and data exposed to Python for AI.
    • Add a "__str__" function to the Universe class and the UniverseObject class, which uses the existing Dump functions of UniverseObject and ObjectMap to output a text representation of an object. Note that similar code exposing such a function already exists in the set wrapping header.
  • Design and implement FreeOrion galaxy map saving and loading routines. It should be possible to load a map when starting a new game, instead of randomly generating one, and to save maps from the GUI or extract them from FreeOrion saved games. Maps should store stars, planets and planet specials. When loading, it should be possible to use only the stars (and randomly populate the systems), or use only stars and planets (and randomly add specials), or use all of the data.
    • A way to do this might be to use a SVG image to store map data. Positions of stars would be indicated by circles in the image, and star colour would be indicated by the colour of the circle. Starlanes between systems could be indicated by lines between the system circles. Planets could be indicated by circles within the system circles, and planet type would be indicated by colour as well. Names of systems and planets could be text within their respective circles. Specials on objects could be indicated by boxes within the circle of a planet or system that contain the text that indicates the name of the special. Buildings on planets could be indicated by a different colour box that contains the name of the building. A zoomed-out (to see the whole universe) rendering of this SVG would resemble the in-game map, and zooming in would reveal details of the contents of systems and objects in systems or on planets in systems.
  • Create a FreeOrion scenario and / or map editor. This can probably be done as a modification of the in-game GUI, so the standard MapWnd, SidePanel, etc. could be modified to add this functionality when the client is in editor mode. Should be possible to load maps and saved game, and save maps and saved games from in the GUI.
  • Expose a Python scripting interface for server-side universe creation and game start setup scripts. The starting unlocked items, ship designs and starting fleets are currently defined in content files in the default directory, but the addition of a shipyard and palace and the homeworld special to the homeworld are hard-coded in C++ during empire generation. It would be better if they were scripted and adjustable. There is also currently no way to significantly alter the game start conditions... Useful things might be to mark other systems as explored, give different types or numbers of planets to empires. Even more significantly, the placement of systems and planets and starlanes should be fully scriptable. The existing C++ universe generation functions can be exposed to and called from python to provide a way to replicate the existing functionality, but it should be possible to implement new generation routines in Python that just call an exposed C++ function to add a system, planet, starlane, special or building. Placement of empires and their homeworlds should also be scriptable in the same way.
  • Write code to get GG::Clr defined in a text file to determine the colours of meters in the GUI. The function GG::Clr MeterColor(MeterType meter_type) in InfoPanels.cpp should be updated to use this instead of hard-coded meter colours. Code to read colours already exists and is used for parsing tech category definitions in techs.txt, so doing the same for meters should be relatively simple.
  • Bug of sorts: When building an Imperial Palace, the empire stockpile location is moved. When doing this, if the old and new stockpile locations aren't able to share resources, the new stockpile location shouldn't retain the old location's stockpile. Instead, the stored amounts of minerals and food should be set to 0.

Player order-giving improvements

  • There needs to be a way for players to set their fleets to "hostile" or "passive". This would determine whether they would initiate combat if an enemy fleet is in the same system, and whether they would block enemy fleets from passing through a system if already present. Stealthy fleets wouldn't reveal themselves if not set to hostile, but would reveal themselves to start battles or block ships if set to hostile. There needs to be UI support for this, so human players can control whether their fleets are hostile, and backend support so that the UI can issue orders to control this setting, and so that AIs can do the same.
  • Make it possible to queue fleet move orders
    • A possible interface for move order editing would be something like Google maps directions that allows one to drag waypoints from a long a route to another location. to have that location inserted into the route.
    • More important is appending destinations to the end of a move order sequence. Perhaps shift- or ctrl-clicking on a system would append that system to the end of the destination queue?
  • Also allow other fleet actions to be queued, like colonizing a planet
  • Make it possible to give multi-part orders, like colonizing a particular system or planet that a fleet is not located at, or making rally points for new ships away from where they are built
  • Add some player-helping AI scripts so the player can order a fleet to "explore"
  • The ExecuteImpl functions of the various Order subclasses in Order.cpp should validate the orders they're about to execute, to ensure that invalid orders can't be sent by players using modified clients or improperly written AIs. For example, in FleetMoveOrder, a player could write a custom client that sends a FleetMoveOrder with a move route that doesn't follow the rules about where players can send ships. A bit of validity checking has been added to that function, but it should also check the route so that when the order is executed on the server, there's no way for an invalid order to be accepted. This validate should ensure that the series of systems in the order's route are all connected by starlanes known to the player that owns the fleet that issued the order. Other Order subclasses likely have similar checks that could be added as well.

UI improvements

  • Investigate making dragging items on queues (production, research) determine where to drop something based on something other than the mouse cursor position. When dragging a box like a tech or production item panel around the queues, it's strange to have the apparent position of the box be different from the active position determined by the mouse cursor position. This means that if the box is dragged from the top, it will appear lower than it would if it was dragged from the top, for a given "active" position. (Where the "active" position is the mouse cursor position which is actually used to determine where in the queue the box it dropped). Ideally the centre point of the box would be used to determine where a box will be dropped, regardless of where on the box the cursor was when dragging started.
  • The chat entry box can autocomplete words if the user presses tab. Autocomplete will work for player, empire, and system names. It could be expanded to work for ships, as well as other content such as techs, species, specials, building types, ship designs, etc. The relevant function is MessageWndEdit::AutoComplete in ChatWnd.cpp and the code changes necessary should be fairly simple for someone new to work on.

Production screen

  • Make the buildable items list sortable, with resizable columns
  • When a building is selected in the buildable items list, get the building's effects groups and find all objects that would be targets of the building's effects if built at the selected location. Mark these objects in the UI somehow (discuss with graphics team).
  • Add lines in the top-left production summary for the currently selected system. Now the total empire PP and wasted PP are shown, but it would be good to also show the available and wasted PP in the selected system.
  • Make dragging a building from the buildable items list onto a planet attempt to order that building to be produced at the planet. Add the building to the end of the queue. Do the same for ships.
  • Make dragging a building or ship onto the production queue enqueue that building or ship at the selected planet. If no valid build location for the dragged item is selected, then do nothing.
  • Make dragging an item from the queue onto the empty space of the galaxy map, or onto the buildable items list, remove the item from the queue.

Research screen

  • Layout of panels and dependency arcs is currently somewhat broken. It's sometimes not possible to scroll to see all techs. This needs to be fixed.
  • Add a sortable list of techs as an alternative to the tech tree view - Partly done, but list view should be put in a resizable window and made sortable
  • Make techs on tree look a bit more like popup tooltips (discuss on forum first)
  • Change how the tree panel layout is done.
    • It shouldn't be necessary to redo the graph layout when zooming. Recalculating this for each zoom makes zooming feel clunky and slow.
    • Arrange the techs hoizontally according to some controllable logical positioning. The placement of tech panels presently seems to have no useful reasoning behind it.
  • Make layout changes persist between executions of the program. The user / player can rearrange and resize several windows on the tech screen, however these changes are lost when the user exits FreeOrion. The positions of the various windows could be stored in config.xml (similar to how galaxy setup selections are stored) and retreived the next time the program is run. Positions should probably be stored in a resolution-independent way, so that changing the resolution doesn't cause windows to disappear off screen, and/or sanity checks for size and position should be done when doing initial layout / retreiving from the options DB to ensure a reasonable layout. Entries in config.xml can be added by adding a function like void AddOptions(OptionsDB& db) in the anonymous namespace in ClientUI.cpp or MapWnd.cpp in files that don't already have one, or adding entries to an existing function of that sort in the file where a stored windows position needs to be retreived. The new options should store the x and y positions and height and width of the windows to have persistent locations between executions. The constructors for those windows could be passed (or modified to take) the positions and sizes as parameters, or the code that creates the new windows could reposition them, or an existing function to position windows could be altered to use them. Entries for these options aren't really needed in the Options screen.

The SidePanel

  • Fix up the top portion with the system resource summary, system droplist and star graphic
  • Design and add a "shipyard in system" box to the system info section
    • Show ships being built, similar to buildings being built on planet panels
  • Make it possible to toggle between opengl-rendered planets and static planet images (available in the art directory).
  • There is an option that can be set in config.xml or the command-line to hide the planets, but there should be a toggle / setting in the UI options menu tab as well.
  • Add a button to automatically select a colony ship, on planet panels or on the sidepanel separate from the planet panels. This button should only appear when there are selectable colony ships in a system, and a planet is not colonized or being colonized.
    • Bonus: add the colony ship selection button only on planets that would be colonizable by a colony ship that is in the system. Make clicking the button select a colony ship that could colonize that planet.

Galaxy map screen

  • Add tooltip to the empire resource summaries at the top of the map screen. This should list, with text explanation, the stockpile, income, expenditures, and net change.
  • On empire resource summary, list all + and - contributions to the production and consumption of each resource. Something like " ObjectType ObjectName +/- ### " in a column.
  • In MapWnd::RenderFleetMovementLines, move_line_animation_shift (a file-level static variable) is set each frame. It's then used in RenderMovementLine to determine where to position the first fleet move line dot after the start of the first segment of the move line. If several empires' fleets are all leaving the same system along the same starlane, these dots will overlap, and only one will be visisble. It would be better if there was an empire-id-dependent additional offset for the dot positions, so that multiple empires' dots can be seen moving along the same starlane.

Fleets Windows

  • Figure out a good way to move up and down the partition between the top third of the panel that shows fleets and the bottom panel that shows ships within the selected fleet. Some way to drag a partition would be appropriate. This needs to work whether or not there is a new fleet drop target in between the two.
  • Presently, the "active" FleetWnd is the one representing the last-clicked fleetbutton, or the one last clicked on by the player, or in which a fleet was clicked. This is only relevant when there are multiple fleet wnds on screen, which can be enabled in the options menu. The active fleet wnd can be determined by seeing which fleet button has white (for selected fleet) move line dots coming out of it on thoe map. It should be possible to set the selected fleetwnd by clicking on just about anything in it. This should include changing ship selection in fleet info section of the fleetwnd (at the bottom). Making this happen would require getting some signals of selection changes or clicks on the relevant list box, and propegating these as is done for the fleets list box at the top of the fleetwnd. This shouldn't be too complicated to figure out.
    • It might also be nice to indicate somehow which FleetWnd is selected.
  • Create a full-screen fleets summary view
    • List all fleets, friendly and enemy
    • Expandable to show ships in fleet
    • Show destination, location, other stats and info
    • Sortable
    • This could be part of a list to show *everything* in the universe... sorted by owner, type (fleet, ships, planets, systems), or other properties.

Design Window

  • DesignWnd::MainPanel::AddPart in DesignWnd.cpp could be improved. This function should "intelligently" find a slot in which to place the passed part, moving around other parts within the design if necessary. Currently it just tries to find an empty slot that can accept the part, and makes no effort to adjust things to accomodate a new part if only possible nontrivially.
  • Add DesignWnd::MainPanel::CanBeAddedToHull that returns true if a passed PartType can be added to the current in-progress ship design without any other modifications. That is, return true if MainPanel::AddPart would be able to add the part, and false otherwise. This will be used to grey out / disable parts that can't be added to the current design, due to being unable to fit in any slots, or any unfilled slots.
  • Add tooltips to SlotControls. PartControls (in the parts list, or after being dropped into a SlotControl) have tooltips indicating what kind of part they are. Empty SlotControls (in the middle panel where parts can be dropped after selecting a hull) could also have a tooltip indicating what kind of slot they are. This should be fairly simple to do by copying what's done for PartControls. Make sure that SlotControl tooltips are replaced by PartControl tooltips when a PartControl is dropped into a SlotControl, though, or modify the PartControl tooltip when it is in a SlotControl, to indicate what kind of slot the part is in (this would be preferred).
  • Make the parts list accept drag-drops of PartControls. If a PartControl is dragged from the parts list to itself, do nothing. If the PartControl is dragged from a SlotControl in the main design panel, then remove the part from the slot.

New Effects

  • Set research progress for a tech for an empire
  • CreateSystem - similar to CreatePlanet and CreateBuilding, but for systems. Should not allow creating systems at the location of another system (or too close to another system?). Would be nice if creating a system at a location through which an existing starlane passes would cut the starlane, perhaps connecting the two new starlanes to the new system and the ends of the cut starlane.
  • SetRotationSpeed / SetAxialTilt - A few specials (Slow Rotation, Tidal Lock, High Axial Tilt, Gaia) should modify their planet's appearance. Currently the rotation and tilt specials are checked for during universe generation, and any planets with them have their rotation or tilt modified. It would be better if the specials could do this with an effect themselves, so that we can remove the hard-coded special names from the c++ code, and could add these specials later in the game and have their effects be visible.
  • SetTexture - Specials could set the texture used to render a planet, allowing specials to drastically change a planet's appearance. A likely use is to make Gaia planets look different. Could be later extended to other objects, as appropriate and as needed.

New Conditions

  • Age / CreationTurn - matches objects that are within the specified range of number of turns since they were created, or matches a range of creation turns
  • PlanetSlot - which slot a planet or other object is located in, in its system
  • Speed - distance per turn an object is currently moving (and perhaps also max speed?). Most applicable to fleets and ships travelling between systems.
  • ShipDesign id - similar to Building name, matches ships with a particular design. Ship designs are created in-game by players, while building names are defined in contenxt text files, so it will be necessary to be able to reference Source.DesignID or similar for this condition to be useful.
  • Other ShipDesign details: designing empire, designed on turn / age of design
  • OwnerControls - takes a special, building, ship hull or ship part name (which appropriate type indicator in the parameter) and a minimum and maximum number. Matches any object owned by an empire than also owns the a number of the indicated item that falls into the indicated range. This will be useful for, for example, limiting an empire to only owning one of a particular building or ship hull. For specials, the empire needs to own planets (or anything else that can have specials on it) with the indicated special attached to them.

Referenceable Object Properties

For effects and condition definitions:

  • DistanceToTarget - just like DistanceToSource, but relative to an effect's target object, rather than the source object.
  • SourceTargetJumps - number of starlane jumps between source and target being acted on, using starlanes known of by source's empire
  • PlanetSlot - which slot a planet or other object is located in, in its system
  • Speed - distance per turn an object is currently moving (as opposed to the BattleSpeed and StarlaneSpeed properties that indicate the movement speed if moving, which is different if the object isn't moving at the present time).
  • ID of empire that created ships or buildings. This information is tracked, and just needs to be exposed for content scripting, which should be fairly easy based on existing examples.

It would also be nice if it were possible to reference properties of an entire effects group when defining effects that (like all effects) act on a single object. This would allow the CreateSitRepMessage effect to say something like "The explosion destroyed 10 ships!" instead of showing 10 variations of "The explosion destroyed %ship%!".