GIS Patches

[Conzar]

This thread will be dedicated to patches developed for Glest In Space total conversion mod.  The eventual goal for the GIS team is to get our changes applied to the mainline (so that we eventually won't have to maintain our own source besides the mod specific files).
Patch Screenshot Gallery

Updated 2011/01/31
I combined both patches from 2011/01/30 into 1 patch.
Patch File: Complete Patch

Updated 2011/01/30
Multi Select Tabs
This patch allows an arbitrary number of units to be selected removing the standard 16 max units.  When more then 16 units are selected, tabs appear next to the unit icons.  This allows the player to toggle through the tabs to see all the units' portraits that have been selected.  The player can either click on the tab itself or use the TAB shortcut.

Programmers Notes
There were several files that needed to be modified for allowing multi-select.  Right now, a GraphicalButton is being used for the tabs.  But I think if this is something desired for the mainline, that the tab buttons be apart of the faction sets and can be skinnable.

Patch based on SVN Revision 1666
Patch file: Complete Patch
A patch for the above patch that fixes the Free Morph Command: Patch for Free Morph



Updated 2011/01/19
Free Morph Command
In the mainline, the morph command requires a cost in resources in order to execute this command.  For instance, if an initiate is to be morphed into a battlemage, then the morph command costs the value of the battlemage as set in the battlemage's xml (I think its 75 gold).  If a modder wants to make the battlemage morph free, at this point he cannot.  There is a means of refunding resources but the player requires whatever resources the unit costs at the start of the morph command, and only gets the funds back when the morph command finishes. This patch enables modders to make a free morph.  Meaning, the morph is free and doesn't require any up-front resources.

In order to enable a free morph, add the following element to the command xml.  If value is true, then the morph is free, and false is the default behavior.  Also note, if the morph-free element doesn't exist in the xml, then the morph command also uses the default behavior (so this won't effect any existing tech trees).

Code: [Select]

<command>
    <morph-free value="true"/>
</command>

Programmers notes
This was a fairly straight forward implementation.  I added the necessary code to parse the xml.  Then I added several if statements to check for free morphing.

Patch based on SVN Revision 1563
Patch file: stand alone patch

Screenshots of applied patch
A test on the mage tech's initiate to battlemage morph


Updated 2011/01/12
HUD Unit Placement Patch
The hud unit placement patch enables modders to move the unit's icon, information, stats, and commands via xml.  The placement of these components are determined by keywords in the xml like: left, right, mid, top, and bottom.  An example of the xml is listed below:

Code: [Select]

   <hud value="true" >
        <unitinfo x-axis="right" y-axis="top"/>
    </hud>
Where x-axis is the horizontal placement of the unit information and valid values are left, right, and mid.  y-axis is the vertical placement of the unit information and valid values are top, bottom, and mid.

Programmers notes
The code isn't exactly straight forward to move the unit portraits and information around.  The coordinates for the components were hard coded without any explanation of why the numbers were used.  So I converted the coordinates to be relative to the size of the screen ... so the hud should look uniform regardless of resolution.  

Patch based on SVN Revision 1518
Patch file: Complete Patch

Patch based on SVN Revision 1468:
Patch file: Incremental Patch
Patch file: Complete Patch

Screenshots of applied patch


Updated 2011/01/08
Patch based on SVN Revision 1468:
Patch file (including minimap, resource position, & overlay patches): Complete Patch

Updated 2011/01/06
HUD Overlay Patch
The hud overlay patch enables modders to add an overlay to the hud specified in the xml.  The overlay is one tga file and can be located anywhere; however, I suggest putting it in the faction home directory with a new directory called hud.  Also, make sure the tga file (when saved/exported) has compression turned off.
The new xml for adding the overaly is shown below.

Code: [Select]

   <hud value="true" >
        <overlay path="hud/hud.tga" value="false"/>
    </hud>
Where path is the local path to the overlay image.  value enables the overlay to be enables or disabled (false = disabled and true = enabled).

Patch based on SVN Revision: 1413
Patch file (including minimap & resource position patches): Complete Patch
Patch file (have to apply minimap patch, then resource position patch): Incremental Patch

Screenshots of applied patch


Updated 2011/01/05
Resource Position Patch
The resource position patch allows modders to change the position of the resource indicators in 1 of 3 positions: Left, Mid (default), and Right.
The max resource quantity is also toggable: meaning, the maximum information is either displayed or not.  There is one exception, consumables will always display their maximum regardless of this setting.
The resources can also be sorted by consumables in 1 of 3 sorts: unsorted (default), left, and right.
In order to use this feature, add the following to the faction xml file (its per faction specific like all HUD enhancements)

Code: [Select]

  <hud value="true" >
        <resources position="mid" consumables="unsorted" showmax="true"/>
    </hud>
Where valid values for position are left, mid, and right.  Valid values for consumables are unsorted, left, and right.  Valid values for showmax are true and false.

Programing Notes
In order to allow for sorting of consumables, a vector of pointers was created in types/tech_tree.cpp which contains the sorted list of resource_types.  When the renderer class draws the HUD with sorting turned on, it uses this vector instead of the default.

As always, please let me know if you have any suggestions, comments, or questions.

Patch based on SVN Revision: 1413
Patch file (including minimap patch): Complete Patch
Patch file (have to apply minimap patch first): Incremental Patch

Screenshots of applied patch

Resource Positions	GIS Usage

Updated 2011/01/03
Minimap Position Patch
The minimap position patch allows modders to position the minimap in 1 of six positions: Top Left (default), Top Right, Bottom Left, Bottom Right, Mid Left, and Mid Right.
In order to use this feature, add the following to the faction xml file (its per faction specific)

Code: [Select]

   <hud value="true" >
        <minimap x-axis="left" y-axis="top"/>
    </hud>
Where valid values for x-axis are left and right.  Valid values for y-axis are top, bottom, mid.

Programing Notes
In order to create a "dynamic" minimap location, the global/metrics class needed to be changed from a const singleton class to a dynamic singleton class (sorry if the terminology isn't correct).  The reason for this is that data members cannot be changed in a const class after instantiation (from my limited understanding of const's in C++).  If there is another way of modifying the data members of the const singleton, then I would be glad to fix it (if so desired).  The result of this patch is that the updated Metrics class returns a pointer instead of a const reference and so I had to modify several files that were dependent on Metrics.

Please let me know if you have any suggestions, comments, or questions.

Patch based on SVN Revision: 1413
Patch file: Patch Version 2

Screenshots of applied patch

Top,Btm,Lt,Rt	Mid

[Coldfusionstorm]

I can't wait to test these changes out

[claymore]

Custom morph cost. You can now specify the cost of the morph command in the same way you specify unit cost, with <resource-requirements> tags. If not found, the morph unit cost is used by default.

If it works. I haven't actually tested it yet.  

Also, it ignores the "discount" parameter if used. Should be easy enough to fix.

EDIT: tested it, doesn't work yet

Regarding the patch above, it looks nice! But the top right is usually taken with unit status info, and the bottom left error messages. Would be nice if you also had the option of "centre", which would apply except when x-axis and y-axis are both this value. Still, this gives you 6 positions as opposed to 2.

[Conzar]

@claymore  I think I can easily add centre, thanks for the suggestion.  Also, this is the first patch in a series of planned patches for GIS.  We plan on implementing features to move the unit info as well as the error messages (thanks for pointing out the error messages though since I wasn't aware).

[titi]

The minimap patch is faction specific? Is this a good idea?
Please lets discuss things first before implementing them...

[Conzar]

@titi The minimap patch is faction specific because some of the other features we have planned also effect the HUD.  We think that factions should have not only a customized techtree but also to have a customized look and feel of the HUD. 

Additional HUD Features
* Placement of the resource stats
* Ordering of the resource stats (all consumables on the left or right)
* Unit Icons placement (top right, bottom right, bottom middle, etc)
* Unit actions placement
* Error message placement
* An overlay

So the question is where should the HUD features be controlled: globally or per faction? 

For GIS we want to have a unique "feel" for our factions.  An overlay with graphics specific to each race is important.  It provides a visual feel that their faction is different.  All of these features are toggleable and do not even need to be added to factions that want the default behavior of the HUD.  But we think that other mods could take advantage of this system to allow for a more customized mod.

An argument for making the HUD global is that its easier to move the HUD components around and have it effect all factions.  If this is really desired, I don't see why global HUD settings couldn't be implemented and over-ride faction based setting.

What are your thoughts ... its difficult for me to get onto irc to chat you guys up so I apologize.

[titi]

Thats exactly the kind of discussion I am talking about! 
What do others say? Is this a useful feature? Explained like this it makes sense to me.

[Omega]

Personally, I'm against faction unique HUD... They should be globally controllable, but not individual factions, as that will serve only to confuse, and, to be honest, I dislike the minimap anywhere else (what is your reasoning for moving it, besides wanting it to "feel different"?).

[Conzar]

@Omega The minmap position is subjection.  Many players that come from a C&C and SC background are comfortable with the minimap being in the lower left corner.  

As for unique huds, we plan on adding overlays that are unique to every faction.  For GIS, the minimap will remain in the lower left corner for all factions but the overlay graphics will change.

Also, the minimap position is for modders, its not indented to be a user feature.

[softcoder]

A few comments.

- Any visual change should be OFF by default unless we all decide we like it on.
- the patches above are created in git and don't seem to work on our svn repos.
- the patches above have FAR too many changes that are not required (but that is another issue). Please provide an svn patch so we can properly review it.
- I see no harm in adding these features as long as they are triggered by something in an xml to explicitly turn them on so that no-one is forced to use it unless their mod so chooses.

Thanks

[Conzar]

Softcoder, thank you for all of your great help and patients ... I am trying to figure out a good work flow so it might take me some time.

All of the changes should be turned off and does not even need the factions xml to be updated.  I've never tried creating a patch in git and then applying it into svn.  So this might take some trials.  I have created a new patch (see first post) (after merging with the latest from svn last night which was very easy to do in git) and used a different command for the patch (It should be more of a basic diff I think).  Please let me know if this works.

Also, what are the changes that aren't required?  Does it have to do with removing the ^M at the end of every line ... its old habit for me to do this b/c it makes editing the files difficult with those characters there (the characters are the result of development in windows).

Thanks again!

[softcoder]

If you look at the patch you'll notice you are changing things like the default network username (glest.ini stuff), disabling svn version stamping (in cmake files) and numerous other things unrelated to the code changes you are wanting merged. Also changing every call to Metrics to a pointer which is not required and makes for a harder read since it adds more changes than what you are trying to accomplish with the hud etc.

Remember a & and a * are basically the same so there was no need to change the reference to a pointer.

[Conzar]

If you look at the patch you'll notice you are changing things like the default network username (glest.ini stuff), disabling svn version stamping (in cmake files)

I will remove these in the next patch. 

Also changing every call to Metrics to a pointer which is not required and makes for a harder read since it adds more changes than what you are trying to accomplish with the hud etc.

The reason I had to change the return type for Metrics was that the getInstance returned a const and the hud code needed a non constant because data members of the metrics class need to be changed.  From my understanding of C++, a const reference is disallowed from calling any function that modifies the data members.  Am I wrong in my understanding?  If so, how should this be coded?

[silnarm]

If so, how should this be coded?

You could make the instance a static member of the class, and provide a pair of getInstance() functions, one const, one mutable. The 'spirit' of Metrics is to be const though and at the end of the day, the minimap and display panel's position and size should really be stored somewhere other than Metrics. So I don't actually suggest the 'pair of getInstance() class functions' as how it should be done...

<digression>
I may be misunderstanding your intent, I've only looked at the changes made in minimap.h... but if you intended to change the minimap position with functions like this,

Code: [Select]

int getMinimapX() {return minimapX;}
it will not work, as this returns a copy of minimapX, not 'minimapX' itself. You need either setMinimap?() functions or to return references.

[Conzar]

The function initMinimapPosition has been added to metrics.cpp.  This sets the minimapX and minimapY coordinates.

/**
 * Initializes the mini map position based on the faction.
 **/
void Metrics::initMinimapPosition() {
    Hud * hud= Hud::getInstance();
    if(hud->getMinimapPosition() == Hud::TopLeft){
        minimapX= 10;
        minimapY= 750-128-30+16;
    }else if(hud->getMinimapPosition() == Hud::TopRight){
        minimapX= screenW-minimapW-30;
        minimapY= 750-128-30+16;
    }else if(hud->getMinimapPosition() == Hud::BottomRight){
        minimapX= screenW-minimapW-30;
        minimapY = 5;
    }else if(hud->getMinimapPosition() == Hud::BottomLeft){
        minimapX= 10;
        minimapY = 5;
    }else if(hud->getMinimapPosition() == Hud::MidRight){
        minimapX= screenW-minimapW-30;
        minimapY = screenH/2 -minimapH/2;
    }else if(hud->getMinimapPosition() == Hud::MidLeft){
        minimapX= 10;
        minimapY = screenH/2 -minimapH/2;
    }
}

By using this function once the hud information is parsed, the renderer.cpp when drawing the minimap will get the right coordinates. 

[Conzar]

I may be misunderstanding your intent, I've only looked at the changes made in minimap.h... but if you intended to change the minimap position with functions like this,

Code: [Select]

int getMinimapX() {return minimapX;}
it will not work, as this returns a copy of minimapX, not 'minimapX' itself. You need either setMinimap?() functions or to return references.

Also, in the MG version of minimap.h; there is no getMinimapX function.

[silnarm]

The function initMinimapPosition has been added to metrics.cpp.  This sets the minimapX and minimapY coordinates.

Yeah, sorry... as I said, I only looked at the changes you made to the header, and not very closely obviously.

Also, in the MG version of minimap.h; there is no getMinimapX function.

I was referring to Metrics, I saw you had de-constified all the getters, but saw not setters and didn't notice the dec for initMinimapPosition() 

[Conzar]

I was referring to Metrics, I saw you had de-constified all the getters, but saw not setters and didn't notice the dec for initMinimapPosition() 

I misunderstood you as well ... so that makes us even 
Thanks for your help though!

[Conzar]

Released another patch today (see first post).  Please let me know (admins/moderators) if what I am doing is according to the rules, if not, how can I better follow them?

[Coldfusionstorm]

Looks good, btw, conzar, can you link me the .tga file?,so i could work with it without having to compile everything?

[Conzar]

Just released a RV 1518 patch (complete).

[Conzar]

Just released a RV 1563 patch that allows the morph command to be free.

[titi]

Is this the morph command as claymore wanted to do it? Please describe a bit more detailed how it works.

1. How does a possible xml look like
2. how is it technically done done ( not detailed, just to give us the idea )

[Conzar]

Is this the morph command as claymore wanted to do it? Please describe a bit more detailed how it works.

1. How does a possible xml look like
2. how is it technically done done ( not detailed, just to give us the idea )

Have you looked at the top of this thread?  I have details on this patch, if you have looked at the top, then let me know how I can describe it better.
Thanks!

[titi]

  ok, I missed it sorry