Jump to content
Sports Interactive Community

Search the Community

Showing results for tags ' guide'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Football Manager General Discussion Forums
    • Football Manager General Discussion
    • Football Manager Touch General Discussion
    • Football Manager Mobile General Discussion
  • Football Manager Technical Help and Bugs Forum
    • Football Manager 2020 Bugs Forum
    • Football Manager 2020 Touch Bugs Forum
    • Football Manager Mobile Technical Help and Bugs Forum
    • FMdB Bugs Forum
    • Football Manager Previous Versions Technical Issues
    • Public Beta Forum
  • Football Manager - Help Us Make FM Even Better
    • Football Manager Feature Requests
  • Football Manager Game Help Forums
    • Tactics, Training & Strategies Discussion
    • Good Player & Team Guide
    • Editors Hideaway
    • Skinning Hideout
  • Football Manager Specific Playing Styles
    • FM Career Updates
    • Challenges, Sign-Ups & Experiments
    • FM Online Careers and Game Modes
    • FM Stories
  • Football Manager Local Language Forums
    • Football Manager Chinese Language Discussion
    • Football Manager German Language Discussion
    • Football Manager French Language Discussion
  • Eastside Hockey Manager
    • General Questions for Eastside Hockey Manager
    • Eastside Hockey Manager Bugs Forum
    • Eastside Hockey Manager FAQ and Knowledgebase
  • The Community
    • Football Manager Channels, Streams and Community Links
  • Non SI/Football Manager Related
    • Off Topic Forum
    • Football Forum
  • House Rules and Forum Guidelines
    • Hall of Fame
    • House Rules & Forum Guidelines
    • Football Thread Vault
  • Forum Software Issues
    • Forum Feedback and Known Issues
  • Reference

Categories

  • Articles
  • Other Football Game
    • More football stuff

Categories

  • Football Manager 2020
    • Getting Started
    • How To
    • Technical Support
    • Pre-Release Beta Specific Questions
  • Football Manager 2019
    • Getting Started
    • How To
    • Technical Support
    • Pre-Release Beta Specific Questions
  • Football Manager 2019 Touch
    • iOS
    • Android
    • Cross-Sync
    • Store and Unlockables
    • Nintendo Switch
  • Football Manager 2019 Mobile
    • Android
    • iOS
  • Football Manager 2018
    • Getting Started
    • How To
    • Technical Support
    • Gameplay
    • Pre-Release Beta Specific Questions
  • Football Manager Touch 2018
    • iOS
    • Android
    • Nintendo Switch
    • Cross-Sync
    • Store and Unlockables
  • Football Manager Mobile 2018
    • iOS
    • Android
  • Football Manager 2017
    • Getting Started
    • Pre-Release Beta Specific Questions
    • How To
    • Gameplay
    • Technical Support
  • Football Manager Touch 2017
  • Football Manager Mobile 2017
  • Football Manager 2016
  • Football Manager Touch 2016
  • Football Manager Mobile 2016

Categories

  • Football Manager 2020
  • Football Manager 2020 (FR)
  • Football Manager 2020 (DE)
  • Football Manager 2020 (IT)
  • Football Manager 2020 (ES)
  • Football Manager 2020 Touch
  • Football Manager 2020 Touch (FR)
  • Football Manager 2020 Touch (DE)
  • Football Manager 2020 Touch (IT)
  • Football Manager 2020 Touch (ES)
  • Football Manager Mobile 2020
  • Football Manager 2019
  • Football Manager 2019 (FR)
  • Football Manager 2019 (DE)
  • Football Manager 2019 (IT)
  • Football Manager 2019 (ES)
  • Football Manager 2019 Touch
  • Football Manager 2019 Touch (FR)
  • Football Manager 2019 Touch (DE)
  • Football Manager 2019 Touch (IT)
  • Football Manager 2019 Touch (ES)
  • Football Manager Mobile 2019
  • Football Manager 2018
  • Football Manager 2018 (FR)
  • Football Manager 2018 (IT)
  • Football Manager 2018 (ES)
  • Football Manager Touch 2018
  • Football Manager Touch 2018 (FR)
  • Football Manager Touch 2018 (IT)
  • Football Manager Touch 2018 (ES)
  • Football Manager Touch 2018 (Console)
  • Football Manager Mobile 2018
  • Football Manager 2017
  • Football Manager Touch 2017
  • Football Manager 2017 (FR)
  • Football Manager 2017 (IT)
  • Football Manager 2017 (ES)
  • Football Manager Touch 2017 (FR)
  • Football Manager Touch 2017 (IT)
  • Football Manager Touch 2017 (ES)
  • Football Manager Mobile 2017

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Biography


About Me


Interests


Favourite Team


Currently Managing

Found 2 results

  1. Football Manager 2015 Skinning Guide Part 5: Editing the xml files Welcome to the fifth part of my updated Skinning Guide for FM2015. Before reading this guide make sure you have read the previous parts of the guide as well as the extracting files guide, as this guide will assume you have followed those guides. The previous parts of the guide talked you through creating a new skin, changing the fonts, changing some of the font settings and colours, with the last part detailing how to change the skin graphics. This part of the guide will talk you through some of the basics of how the xml files work. Due to how Football Manager works it isn't possible to give you a full guide on how to edit the xml files however this guide should give you some basic information to get you started. I also have some more detailed posts on this forum/my website that talk you through modifying certain screens and if you combine those guides with the basics learned here you should get a good understanding of how the xml coding in Football Manager works, after that the best way to learn is just from the experience of looking through and editing the xml files. Editing the xml files is fairly simple once you know where to start and as such it doesn't actually require any coding experience, though some very very basic knowledge of coding or even webpage editing will give you a quicker start (even the simple knowledge of how to manually format your posts when posting on the forum is all you really need to start with). You should also only rarely need to actually write your own xml code, most if not all of your xml editing will involve copying code from one place/file to another to change where it displays or will involve deleting of some code if you want to hide certain things, so you mainly need to know how the code links together and what is part of the same code. The hardest thing you'll probably have to do is to adjust the code you copied so it matches the format of the existing code as the code can change slightly depending on where and how it's displayed. Before starting I advise you have the following folder locations open: - Your 'Working' Folder Location from the previous guide (which is where you extracted the default game files to). - The my_first_skin folder within your Saving Location. You will also need to have your preferred xml file editor open as well as FM2015. The basics of the xml file Before you start editing the xml files you need to understand how the files work on a basic level. If you want some background information on xml coding in generally then check out the XML Tutorial offered by w3schools.com – though for FM purposes you only really need to know the first few chapters anything past the Attributes chapter isn't really needed for FM. The first thing you need to know is there are three kinds of tags you'll come across in the xml files; <record> </record> <record/> The first one <record>is an opening tag this starts off some code which is then closed by the second tag </record>which is a closing tag. For each <record>tag that you have you also need to have a </record>tag in the file as the opening and closing tags must always balance, if you don't balance the tags you'll get an error in game. In addition a closing tag will only close a tag of the same name so a closing tag </string>will not close or balance out a <record> tag to close the <record>tag you need a </record>tag. A </string>tag will only close a <string>tag. The third tag <record/> is a self-contained tag it opens and closes itself and as such doesn't need to be balanced. For a simple example open up the 'skins\my_first_skin\skin_config' xml file. On the second line you'll see a <record>tag this opens up a record element. In the middle of the file you'll notice several lines like these: <string id="name" value="My First Skin (Dark)" /> <string id="skin_name" value="my_first_skin" /> <string id="author" value="michaeltmurrayuk" /> <translation id="description" translation_id="249669" type="use" value="This is my first skin based on the Dark Default Skin" /> <string id="version" value="1.0" /> <flags id="parent" value="fm dark-widgets" /> All of these are self-contained tags, you'll notice that each of these have more than one word/element to them and in case of the translation one it might even be spread over more than one line yet they are all self-contained tags, that is because the tag type is only determined by the first word and by how the tag is opened and closed. In this example we have three different elements; four string elements, a translation element and a flag element, these are determined by being the first word after the < which opens the element, and we know they are self-contained tags because the elements are closed by /> Finally at the bottom of the file we have a </record> tag which closes the record element, and balances out the file as we have one <record> tag and one </record> tag which opens and then closes a record element, with the rest of the tags being self-contained tags that don't need balancing. The other thing you'll notice in this file are lines that contain <!-- and --> these are comment tags and work in the same way as the open and close tags, <!-- will open a comment and-->will close a comment, you'll notice that comments can either be contained to one line or span several lines. Comments aren't read by the game but are notes for the user that will either contain notes about what a bit of code does or will disable some code. You can also add your own comments as you go to remind you what a certain piece of code does or id pertains to once you have worked it out, which can be handy if you come back to the file in the future and forgot what you had done to it. The next thing you need to know about is nesting. With the xml code you can nest elements within other elements of the same or different types. Nesting affects how various bits appear in the game and is used to group items together or to apply properties to a certain item. What you need to know at the moment is that nesting is affected by where you place the close tags within the xml file, so when messing around with the tags you'll need to ensure you place them in the correct place. You can see a quick example of nesting by opening the 'my_first_skin\fonts\text' xml file that you should still have from a previous part of the guide, around the middle of the file you'll notice some code that looks like this: <!-- shadowed style --> <record style="shadowed"> <list id="shadows"> <record> <integer id="x_offset" value="0"/> <integer id="y_offset" value="1"/> <integer id="blur_radius" value="2"/> <integer id="colour_red" value="0"/> <integer id="colour_green" value="0"/> <integer id="colour_blue" value="0"/> <integer id="colour_alpha" value="75"/> </record> </list> </record> The first line is a comment which lets us know the following code affects how the shadow on this text appears, the next line opens up a record element, then we open a list element and then open another record element, we then have seven self-contained integer elements, we then have a tag that closes one of the record elements, with the element it closing being the second one (<record>), we then close the list element before finally closing the remaining record element. To simplify the above code opens up a record1 element, then a list element, then a record2 element (we can ignore the integer elements as they are all self-contained), it then closes the record2 element, then the list element before finally closing the record1 element. You'll also notice that the <record style="shadowed"> element is closed by just a </record> tag this is because closing tags should only ever contain the one first word that determines the element type. Element Types The next thing you need to know are what the most common element types are and what they do. Container The container element as its name suggests acts as a container, these are mainly used to group bits of code, and you can also use blank containers to add some padding between items. Widget The widget element is used to display pretty much any kind of graphic or text in the game. Layout The layout element as its name suggests is used to position your containers and widgets on the screen. You'll quickly come to find this element rather frustrating as there are multiple layout attributes that often have to be used to together but it's not always clear which ones need to be used on certain screens or in certain places. These are the three most common and basic elements used by Football Manager, however as you'll have seen from the previous examples there are also various other elements, however for the most part you won't need to adjust these unless you are doing something in particular (in which case the instructions will be covered in that particular guide) and if you do they act in the same way as these elements so once you have understand the basics of these three common elements you should be able to understand what the other elements do. Element Attributes Next up are the element attributes, if you refer to the following line in the 'my_first_skin\skin_config' xml file: <string id="author" value="michaeltmurrayuk" /> By now you should recognize that this is a self-contained tag because it starts with < and ends with /> and as the first word is 'string' this is a string element. The other items 'id' and 'value' are called attributes whilst the 'author' and 'michaeltmurrayuk' items are referred to as attribute values. Element attributes always have to be formatted in the following format; attribute="attribute_value" The first word sets the attribute, you then follow this with an = and then place the attribute value inside " marks, if you don't do this correctly the game won't read the attribute and it will flag up an error. The = sign is telling the game to assign the following value to this attribute, whilst the "marks are needed to tell the game where the attribute value starts and ends as some attributes can contain more than one attribute value; alignment="top, left" In this example we are setting the alignment of something and we are wanting it to be in the top left position, so when including more than one attribute value for an attribute you separate them by a coma (,). The space after the coma is optional as the game will read both values without the space, the space just makes it easier for you to read. You'll also notice quite often that you will have two related attributes following each other, in the first example the first attribute is telling the game we want to set the author variable and the value we are assigning it is my name (michaeltmurrayuk). In the second example the alignment attribute will normally be followed by an inset code so it looks like this; alignment="top, left" inset="10" In this case we want to place something to the top left corner and want it to appear 10 pixels in from the top and left sides. Attribute Types There are countless attribute types that you can declare in the game, these attributes are used to apply properties to the various elements. The attributes you can use are fixed as they are telling the game you want to set a certain attribute and as such the game needs to understand what attribute you are setting, whilst with attribute values you are generally free to put in what you want, though some attributes will only take certain values, but for the most part you can generally tell what values an attribute wants from its name. What I am going to do now is talk you through some of the common attribute types for the three main elements (container, widget and layout). First I want you to browse to the 'panels' folder inside your 'Working' folder and copy the 'player profile' xml file. We will use this file to get some examples from as it’s a relatively simple file and corresponds to a screen nearly everyone should know. Now open the 'my_first_skin' folder in your Saving Location and if you haven't already create a new folder called panels and paste the 'player profile' xml file into this folder, so the panels folder of your 'my_first_skin' should now look like this: Next load up Football Manager 2015 and set your skin to 'My First Skin (Dark)' and then browse to the Overview -> Attributes panel for any of your players. Now open the copied 'player profile' xml file. I will use this file to run through some of the various attribute types you'll come across. Container Attribute Types If you look on line #23 you should see this code: <container class="bordered_box" id="pdet" file="player profile personal details" /> The first attribute you will normally see is the class one this determines what kind of container we are wanting, and for containers the class determines the appearance of the container and you should remember from the graphics part of the guide that when we changed the attributes box graphic it didn't change the box around the profile, that is because as you can see this container is a bordered box whilst the attributes container was a subsection box. There are several different box types you can set the containers to (you can get a list of names from the subfolders listed in the skins\fm-widgets\graphics\boxes\ folder from your 'Working' folder). To change the type you just change the bordered bit to a different box, so if you want it to look like the attribute container change the above line to the following; <container class="subsection_box" id="pdet" file="player profile personal details" /> Which should then look something like this in-game (if you haven't reverted the changes from the previous guides): The main difference between the default subsection and bordered boxes is the fact that the subsection box has a space for a panel title whilst the bordered box doesn't. If you want you can experiment with the different styles to see what they look like, the two other types you'll normally come across are titled and plain with both of these giving you transparent panels one with space for a title and one without. The next bit is the 'id'attribute which is used by the game to identify certain items, this can be a bit of a tricky one as some containers need a set id to display their contents correctly, others don't need one at all and in some cases the game needs each container to have its own unique id, for the most part you shouldn't need to adjust this, you only need to adjust this if you are using existing code as a template for something you have added. The last attribute on this line is the 'file'attribute, this as the name implies is used to grab data from another file, in this case it Is telling the game to populate the contents of this container with the code found in the 'player profile personal details'xml file. Now if you look on line #16 you will see the following different attributes for a container: <container class="vertical_adaptive_container" id="PLPR" inset="0" offset="0" gap="8"> In this case we are still setting the class of the container but instead of just assigning it to a box we are setting it to something called a 'vertical_adaptive_container'and what this does is tell the game to change how many of the nested containers will appear on screen determined by our screen resolution, in this example we want to change the amount of vertical containers with the height of our screen, so if you are playing at a vertical resolution of 768 pixels you'll notice that we have the three classic rows of containers (Personal Details, Selection Details and Statistics) however if you increase your vertical resolution enough you'll notice that a fourth row (Positions) appears. There is also a 'horizontal_adaptive_container'class that operates in the same way but on the horizontal axis (think the Player Overview -> Profile screen). The next attributes we are interested in on this line are the 'inset'and 'offset'attributes and these determine how close to the edge of the container the content and graphics will appear, in this case the inset value determines how many pixels from the left and right of the screen the nested containers content appears and the offset determines how many pixels from the top and bottom of the screen the content appears. If you play around with these values you'll notice that the position of the Attributes, Positions and Selection Details panels with respect to the edge of the screen changes, however you'll notice that the Statistics panel isn't affected, this is because it turns out the Statistics panel isn't nested within this vertical_adapative_container and as such isn't affected by any changes we make to this line of code. Note that the inset doesn't always just adjust the left/right margins and the offset doesn't always just adjust the vertical margins, how it acts depends on the element and preceding attributes, the quickest way to see what they actually do in other places is to adjust the values then reload your skin and see what direction the item has moved. You can also use negative numbers and these will shift the content the other way, in this case it will cause the content to start closer to the edge or even off the edge of the screen. The final attribute on this line is the 'gap'attribute and this determines the spacing between each container in pixels, the higher the number the greater the gap between the panels and again you can use a negative number to bring them closer. Also note that this only affects the gap between the vertical panels it doesn't affect the gap between the horizontal panels. Another type of container can be found on line #18; <container default_height="384" priority="1"> These containers are used in conjunction with the adaptive containers, you'll notice in this case we haven't assigned the container a class that is because the class attribute isn't always needed for a container. The 'default_height'attribute as the name suggests sets the height of the panel in pixels and the reason why this is needed is because this container is nested within the adaptive container, and for the adaptive container to work it needs to have the height of the various panels set so it knows if it can display them or not. There are two values the height attribute can take either a positive whole number which will set a height of that many pixels or you can also use a negative number, if you use a negative number it will tell the game to stretch this panel to fill up the remaining space, if there is more than one negative panel the number will determine the split as a ratio (more detail on this will be coming later). In addition to the 'default_height'attribute there are also 'minimum_height'and 'maximum_height'attributes as well as 'default_width', 'minimum_width'and 'maximum_width'attributes for horizontal adaptive containers that all act in the same way. You can also combine these values to give your item a dynamic size depending on screen resolution, if you set both a default and maximum value then the game will display your item at the default size, but if it has space left it will expand up to the maximum size. Whilst if you set a minimum value then the game will only display the item if the available room is at least this amount. The other attribute on this line is the 'priority'attribute which is again linked to the adaptive container, this attribute tells the game which containers to prioritize showing when there isn't enough space, and the lower the number the higher the priority, so a priority value of 1 means it will always show, which is why the Position and Form panels disappear at lower resolutions as they have a lower priority and there isn't enough room to show them. Widget Attribute Types To show some examples of the widget attribute types a better example to use is the 'match title bar score' xml file which is the file used to display the team names and scores on the match screen pitch when you have the titlebar hidden. First as an exercise I want you to locate and copy over the default file to the 'my_first_skin/panels' folder. Now I want you to locate this code on line #25; <widget class="text" id="Mclk" size="12" width="80" alignment="centre" style="semi_bold" colour="match text"> Like the container element the widget element starts with a 'class'attribute which determines what kind of widget we are going to be using, in this case we have a text widget which as the name implies is used to display some text on the screen. The next attribute is the 'id'attribute and this tells us what kind of text to display in this case the id tells the game to display the match clock. The next attribute sets the size of the text that displays, the 'width'attribute sets the width of the widget. The 'alignment'attribute determines how the text is positioned in this case it is centred in the widget, you can also have it left or right aligned as well as top or bottom, you can also combine vertical and horizontal alignments to have "top, left"for example. The 'style'attribute determines what style font is used (i.e. bold, italic, shadowed, embossed etc. Lists of styles can be found in the xml files in the fonts folder). The 'colour'attribute sets the colour of the font; though note that this can in some cases be overridden by values set elsewhere or for some annoying items is hardcoded. Another example for the widget can be found on line #38; <widget class="picture" id="T1bp" auto_size="vertical" file="boxes/custom/match/scoreboard/team/paper" cached="true" rthr="68"> This case shows an example of the picture class widget, and again has similar attributes to the other elements, first the class tells us this is a picture, the id tells the game we want to display the home teams background colour. The 'file'attribute tells the game what graphic to display, note that it doesn't need the graphics folder declared but it does need the subfolders inside the graphics folder declared and you also need to point to an actual graphic rather than just the folder. The final attribute on this line we are interested in is the 'rthr'attribute and this is used when the game recolours a graphic from code, in this case the graphic becomes the home team background picture and is recoloured by the game to match the background colour of the home team. There are a load more classes of widgets in the game but they generally work the same as these two, there are also a lot more attributes that can be applied to the widget elements, the easiest way to find these is to look through the xml files and look at the attributes assigned to the various widgets, most of them should have simple names that describe what they do. Layout Attribute Types Finally we are going to look at some of the attribute types for the layout element, now these can be fairly tricky to work out as you sometimes need to use combinations of them and different screens require different layout values, if you get stuck with these when moving items the best thing to do is to see how the elements near where you are placing your code is written and try and copy that, and if you are modifying items rather than moving them then the best method is to adjust the values of one attribute in the element and see what it does before adjusting another. The below layout element is probably the most common one you'll come across; <layout class="stick_to_sides_attachment" alignment="all" inset="2" /> The 'stick_to_sides_attachment'class tells the game to stick the related item (normally a container or widget) to the side of its parent. The 'alignment'then tells the game what side to stick it to, with the 'inset'(or 'offset') attribute telling the game how far from the edge to stick the item. In this example the inset value of two tells us we want the item stuck two pixels away from the side with the all alignment telling the game we want it stuck two pixels away from all the sides. Inset and offset values have to be whole numbers but can be negative or positive. Alignment values can also be top, bottom, left, right, horizontal or vertical; you can also combine them "top, left"or "top, right"etc. Also if you want to have a different inset from different sides you can split the line up to read something like; <layout class="stick_to_sides_attachment" alignment="top" inset="2" /> <layout class="stick_to_sides_attachment" alignment="right" inset="10" /> These set your item to appear two pixels in from the top and 10 pixels in from the right. Another example line is; <layout class="arrange_horizontal_attachment" offset="0" layout="-4, -6" gap="8" /> In this case the 'class'attribute means we have several items we want to display side-by-side; this is normally used when you are displaying multiple containers. As the layout attribute has two values this means we have two items to show side by side, with the negative numbers meaning we want both of these items to scale with resolution rather than be a fixed size. With the actual numbers telling the game what ratio of space each item should take up. To calculate the ratios you add the two numbers together in this case we get 10 (4+6) which then gives you the ratio of each item, in this case the left item will take up 4/10 of the space whilst the right item will take up the remaining 6/10, if you want both items to use up the same space set them to the same value (-1 normally). There is also an 'arrange_vertical_attachment'class that works in the same way but vertically rather than horizontally and will display items on top of each other. The other layout class you will come across is this; <layout class="fit_children_attachment" alignment="horizontal,fill" gap="0" offset="0" /> This class also tells the game you want to display several items one after another and is generally used for displaying multiple widgets. The alignment value this time determines how they appear, with a horizontal value setting them side-by-side and a vertical one putting them on top of each other, the fill value tells them to fill out the space one after another. Summary The container, layout and widget elements combine to form the vast majority of the coding in the xml files. First you will generally call a container to group the content together, next you will use several layout elements to determine how the grouped content is laid out then finally you will use the widget elements to display an item in game before closing the container. A full example of how each of these elements interacts can be found in the 'match title bar score' xml file; <container class="bordered_box" appearance="boxes/custom/match/scoreboard/container/paper">< <layout class="arrange_horizontal_attachment" alignment="horizontal" gap="0" offset="0" /> <layout class="fit_children_attachment" alignment="horizontal,fill" gap="0" offset="0" /> <layout class="stick_to_sides_attachment" alignment="vertical" layout_children="true" inset="0" /> <container width="10" /> <!--home button--> <widget class="icon_button" id="homb" click_event="home" height="30" width="40" appearance="buttons/custom/match/exit/button" icon="icons/16px/home" icon_alignment="centre"> <layout class="centre_in_parent_attachment" alignment="vertical" offset="0" /> </widget> <!--clock--> <widget class="text" id="Mclk" size="12" width="80" alignment="centre" style="semi_bold" colour="match text"> <layout class="stick_to_sides_attachment" alignment="top" inset="1" /> </widget> <widget class="text" id="Mijt" size="8" width="40" alignment="centre" colour="match scoreboard added time" style="semi_bold"> <layout class="stick_to_sides_attachment" alignment="top" inset="1" /> </widget> ... The first line tells the game we want the following content nested inside a container with the settings of a bordered_box but with a custom appearance. The layout elements then tell the game we want the nested items to display side-by-side with no gap, and we have several widgets to be displayed in a row, then as the other lines have set our horizontal placement we use the another layout element to set our vertical placement. Next we have a blank container element; a width value is set to give us some padding from the left of the screen. We then follow with some widget elements to display some items in game; we first display a home button and nest a layout element inside the widget element to centre it vertically. Next we use some text widget elements to display the time and added time. I haven't pasted in the rest of the code from that file, but if you look at the xml file you'll see the file contains similar code to create a new container nested inside the existing one to display the team name on top of the team background bar rather than alongside it like the rest of the content, this is because these widgets positions within the nested container are determined by the layout code within their container rather than the layout code within the parent container, the parent layout code only applies to the position of the nested container but not the code nested inside the container, thus by nesting the team name code within a new container you are able to display the name on top of the graphic when the previous code had items displaying side-by-side, then when you close the team name container we have another widget this time displaying the scoreboard which appears side-by-side again, we then finish with an away team container and an aggregate score widget before finally closing the initial container. Other bits If you are using Notepad++ to edit your xml files you'll notice that it gives different items different colours; tags and elements have a blue colour, attributes are red, attribute values are purple and comments are green. You can use this to give you a quick visual notification to make sure you haven't mistyped something. (Other programs may also colour the code but might use different colours). Notepad++ can also try to help you by drawing grey vertical lines to try connecting open tags with the corresponding closing tag, though be aware this feature doesn't always link the correct ones. You may also have noted that various lines are indented differently with nested items having a further indent than their parent and linked open and close tags having the same indentation that can help keep track of which tags are linked. You can find downloadable versions (pdf and docx versions at the moment) of this guide at the bottom of this page on my website. --- Redistribution Terms You are free to post this content to your website provided: 1. It is not sold or behind a paywall. 2. You don't advertise it as being exclusive to your website. 3. My username and blog address are included: http://michaeltmurrayuk.blogspot.co.uk/ If linking to the guide please link to this page rather than the direct download links as the links may change with updates.
  2. Football Manager 2015 Skinning Guide Part 4: Editing the Skin Graphics Welcome to the fourth part of my updated Skinning Guide for FM2015. Before reading this guide make sure you have read the previous parts of the guide as well as the extracting files guide, as this guide will assume you have followed those guides. The previous parts of the guide talked you through creating a new skin and then changing the fonts and some of the font settings, before telling you how to change most of the text colour. This part of the guide will talk you through how to change the appearance of the actual skin graphics. As it is fairly long I have also included a quick recap at the end. Before starting I advise you have the following folder locations open: - Your 'Working' Folder Location from the previous guide (which is where you extracted the default game files to). - The my_first_skin folder within your Saving Location. You will also need to have your preferred xml file editor and image editing programs open as well as FM2015. Locating the default graphic files Like with the font settings (and everything else) the skin graphics work on a hierarchy system which means you only need to copy over files you are planning on editing into your skin, if you don't copy the files over the game will just use the default files. The first thing you need to do is locate where in the 'Working' Folder the default skin graphics are located, and like with the text settings they are located in various places, however instead of being located inside the settings folder the graphics are aptly located inside the graphics folder. The first location you need to check are the folders for the parent skin to your skin (when skinning this should always be the first place you look for files), if you cannot remember which parent skin you set then open the 'skin_config.xml' file located within the 'my_first_skin' folder and locate the parent line that looks like this: <flags id="parent" value="fm dark-widgets" /> In this case the parent skin we need to look in is 'fm dark-widgets'. So in your Working folder browse to the 'skins\fm dark-widgets'folder, but notice that there is no graphics folder for this skin, that is because this skin has no unique graphics and inherits from its parent skin. Now what you need to do is locate the parent skin for the 'fm dark-widgets' skin and check if the parent skin has a graphics folder. The parent skin to the 'fm dark-widgets' skin is the 'fm' skin and whilst this skin has a graphics folder it is empty apart from a config file, so you now need to look in that skins parent skin. Now you should be in the 'skins\fm-widgets\graphics' folder and notice a load of folders these folders contain the skin graphics for full mode skins. This folder is where you will be taking most of your skin graphics from. Graphics are also located in the 'graphics' folder located in the root of your Working folder; this location contains the general game graphics (logos, kits, pitch graphics etc…) but you shouldn't really need to touch these for basic skins, you might touch the main menu folder if you want to change the title screen but that is about it for a skin. Graphics format Now you have located the default graphics you need to understand how they work. The first thing to understand is that the format of the skin graphics in FM15 has changed from previous versions, and whilst it may look more complicated at first it actually makes things easier long term. The easiest way to explain how the graphics work is to show you in an example, so what I want you to do is to browse to the following location within your 'Working' Folder: \skins\fm-widgets\graphics\boxes\subsection\standard Then if you haven't already load up FM15, make sure the 'My First Skin (Dark)' Skin is loaded (or whatever skin it is you are creating if you gave it a different name) and browse to the Overview -> Attributes screen for one of your players. Inside the standard folder you will notice several png files and an xml file, skin graphics consist of three items, two of which you can see here; Png graphic This controls the basic layout of the graphic, in this folder you can see we have a png file called paper which is a pinkish colour with round edges, it is pink because the file has some transparency but we will explain the reason for the actual colour in bit. This graphic controls among other things the shape of the box that surrounds the player attributes panel on the player profile screen that you should be on in the game – note how the attributes box in game has rounded corners and has some transparency to it. There is also a png file with the @2x bit in it, these files are used when you use one of the zoomed in modes and are to ensure that the skin still looks sharp when zoomed, and in basic terms you just create this with double the dimensions of your normal graphic. Xml file The next file we are interested in is the xml file, the xml file will take the same name as the base graphic (in this case paper) and this controls the settings of the graphic, however for basic skinning you shouldn't really need to edit these files, you'll mainly use them as a reference to see how the colours are controlled, but I'll explain in detail what each of these settings do in the next section of this guide. Colour Settings You'll notice that whilst the actual paper png file is pink, in game the box appears dark grey, this is because as alluded to in the previous guide graphic colours are now controlled by the same code that colours the text rather than by the actual graphics. I'll cover this in more detail later but it basically makes recolouring your skins a whole lot easier than in the past as you no longer need to manually colour and recolour loads of png files (the other advantage is that all the default graphics are now located in one place rather than several like in the past). Changing the appearance of the graphics Now I am going to run you through some basic examples of how to edit the skin graphics, we will again use the subsection box graphics as an example. First you need to copy some of the existing contents of the standard box over to your 'my_first_skin' however when copying files over they need to keep the same file structure so to copy over the contents of the standard folder you will also need to create the same file structure as found in the default files. So browse to your 'my_first_skin' folder and inside it create a new folder called 'graphics', then inside that folder create a new folder called 'boxes', then inside that create a new one called 'subsection' and then inside that create a new folder called 'standard'. Finally from the Working folder copy over the 'paper.xml' file (we don't need the other ones for this example) to your newly created standard subfolder, so inside your 'my_first_skin' folder you should have something that looks like this: Now what I want you to do is to open your preferred image editing program and create a square image, of 400x400 pixels. Now make the right hand side of the image red (RGB: 255, 0, 0), the left had side blue (RGB: 0, 0, 255) now cut a triangle out of the bottom left corner and a curved bit from the top right hand corner leaving the cut areas transparent. Now add a green (RGB: 0, 255, 0) trim around the edges of the coloured bits so you are left with a shape that looks like this (the exact shape doesn't really matter, and you can save and use my example if you want to save some time): Now save the image as a png file (make sure the transparency/opacity option is set if available) call it paper and save it into the above location. Now reload your skin in FM and the attributes part of the player profile screen should now look a bit like this: You'll notice that the in game image doesn't quite look the same as the image you created (colour is different and shape is slightly wrong) this is because the graphic is also controlled by the 'paper.xml' file that is also located in the folder. Now open the 'paper.xml' file and you'll see various bits of code, most of this code is commented to explain what it does but I'll give you a quick explanation and some examples below. Image Borders <record id="image_borders" left="10" right="10" top="35" bottom="5"/> This determines how far inset from the sides the content of the box appears, so for example if you adjust the left value to 50 and then reload the skin you'll see the margin on the left has increased, however note that the title hasn't shifted over as this line doesn't affect the title, which is why you'll notice that the top value is set to 35 and not 5 like the bottom, if you set the top value to 5 and reload your skin you'll see the attribute tables have shifted upwards and now cover the title text. Title Inset <integer id="title_top_inset" value="8"/> <integer id="title_bottom_inset" value="0"/> <integer id="title_left_inset" value="10"/> <integer id="title_right_inset" value="10"/> These bits of code determine the position of the title text for the box, and act in the same way as the image_borders code. The other option is the title properties one but this just controls the font used for the title text, you can change the value to point to a different font if want, for full details on how to change the font settings check the previous parts of the guide. Though for the most part you shouldn't really need to mess around with either of these settings as the default settings will be fine most of the time, the only reason to really adjust them is if you want to free up some extra space or you have a fancy pattern that you need to fit the text around, though bear in mind if you increase these values too much content might start disappearing if it cannot fit in as there is only so much space available (also be aware that the box and panel sizes change depending on your resolution, so if you are making a skin for the community keep in mind that your fancy design might not work well at a smaller resolution – a good thing to do when skinning is to test your skin at both the resolution you play in and shrunk down to the smallest supported resolution of 1024x768 to ensure the greatest user base for your skin.) Image Slices <record id="image_slices" left="8" right="8" top="8" bottom="8"/> The next bit of code is new for FM15 and determines how the graphic is split up so it can be resized to fit in the space assigned, in the past you had to manually slice up your graphic files; however this is now done in code for FM15 which makes things a whole lot easier. Unless you are radically altering the shape of the graphics you shouldn't really need to worry about messing around with these settings. Though in this example I have purposely made a shape that is misaligned in the bottom left corner using the default values. In basic terms what the game does is split each graphic up into pieces (either 3, 6 or 9 pieces depending on how many directions the image needs to stretch) so the game can dynamically size the skin graphics in the game without either the skinner having to create multiple individual graphics of fixed sizes to fit each situation or leave the game with fixed sized content. In this example the image is sliced at 8 pixels in every corner which gives you something like this (with the black dotted line roughly representing where the image is split): Which gives nine pieces for this graphic – the top left and bottom right corners are solid green, whilst the top right and bottom left corners are both transparent, these pieces will be fixed 8x8 images in game. Next we have the top and bottom slices, these will have a height of 8 pixels, but their width will be resized to fit whatever the width of the panel is in game, however it will keep the same dimensions, so the percentage of the width that is transparent compared to the solid colour (outside of the corners) should be the same no matter the width of the box. (You can test this in game by changing your resolution and you'll notice the attribute panel box resizes but the transparent part is kept in proportion with the solid part no matter the size of the panel). A similar thing happens with the left and right side pieces, but these will be a fixed 8 pixels in width whilst stretching vertically to fill the space, again keeping the transparent section in portion no matter the height of the box. Finally you have the middle section that is resized both vertically and horizontally to fill up the rest of the space. In this example due to the way the slices are drawn the border in the bottom left diagonal doesn't line up with the bottom, so we will need to adjust the slicing to get them to fit. If you have to adjust the slicing values to fit a shape in it is best to adjust the slicing so the shape is within a static part (Ideally in a corner). In this example we can either adjust the bottom slicing or the left slicing. In this example the diagonal piece takes up about 120x120 pixels – you can get the value by either trial and error or by creating a copy of your image (so you don't accidentally overwrite your actual image) and then cropping the bit you want to get its size. So to get the corner to line up perfectly and keep the same shape you want to set both the left and bottom slicing to the same values of about 120 pixels, this then changes the left bottom corner piece from a 8x8 pixel transparent square in a 120x120 pixel which includes the diagonal border bit and as this is now a static piece it fits in with both the left and bottom sides: However note that the middle of the panel is no longer split half black half grey, this is because when we changed the left slicing we changed the middle piece from being half black, half grey to more like 2/3 grey and 1/3 black. You can even this back out by just increasing the right slicing to 120 making the middle piece again half black and grey. Another thing to consider is when creating actual graphics for your skin you don't need to make them this big, if you noticed the default graphic is only 32x32 pixels. The less complicated your pattern the smaller you can make your graphic. Changing the Graphic Colours You'll notice despite making our graphic out of red, green and blue colours the game has recoloured our graphic to black and grey, this is because the other new skinning feature for FM15 is that the skin graphic colours are now controlled by code in the xml files rather than by the actual graphics, which again is a bit complicated at first but in the long term will be a great time saver, as it now means recolouring a skin is just a case of changing some values in an xml file instead of you having to manually recolour or even recreate hundreds of png files. The first thing to know is that when creating new graphics (or modifying existing ones) is that you only want to use three colours in the graphic; Red (255, 0, 0), Green (0,255,0) and Blue (0,0,255). The normal convention is to use Red as the main colour of a graphic whilst using Blue and Green for highlights such as a border, pattern or shadow effect. Though the game doesn't care what order you put the colours in or how you use them as they are defined by yourself later anyway, it's just easier to keep to the same system used by default as it means you don't need to keep on looking back at the actual graphics when you are recolouring it later in the code. So still using the same example as before I want you to look in the 'paper.xml' file and near the bottom you will see the following lines of code: <colour id="red_replacement" name="box_background"/> <colour id="green_replacement" name="box_shadow"/> <colour id="blue_replacement" name="box_border"/> These lines tell the game what Colour Name Variable to assign to the Red, Green and Blue bits of your graphic, so in this example the Red colour is assigned to the box_background Colour Variable. However there is nothing in this file to tell us or the game what colour the box_background colour actually this. This is because like with the text settings the actual colour is determined by the settings set by the xml files in the settings file and these values are edited in exactly the same way as the text colours are. If you look in the 'my_first_skin\settings\my_first_skin settings.xml' file you will see we don't have any of the three above Colour Names declared in this file, which means the colours are being set by either the settings for our parent skin or by the default colour settings. As a simple exercise I want you to locate the three above colour names (box_background, box_shadow and box_border). Hopefully you should have found those three variables near the top of the 'fm dark-widgets settings.xml' file which look like this: <!-- Standard Box - titled box, subsection box, bordered box, tabbed box etc--> <colour name="box_background" red="49" green="52" blue="63"/> <!-- Box background colour - red_replacement --> <colour name="box_border" red="30" green="30" blue="30"/> <!-- Box border- blue_replacement --> <colour name="box_shadow" red="0" green="0" blue="0"/> <!-- Box shadow colour - green_replacement --> You'll notice that with these lines are some comments that tell you what colours they replace by default which should help you out at the start, though note in our case the graphic we designed used the green colour as the border not the blue, so adjusting the box_border value wouldn't in this case change the green border of our graphic but the blue half of our graphic – the names of the Colour Variables aren't important, the important bit is what colours they replace. There are several methods to actually change the colours. The simplest method is to just change the RGB values of the Colour Names the replacement colours are set to. To adjust the colour you need to change the values for each component. Valid values range from 0 to 255, where 255,255,255 is white, 0,0,0 is black, 255,0,0 is red, 0,255,0 is green etc… Next you need to know the RGB value of the colour you want, the easiest way to get this is from an image editing program. (Or you can use trial and error to get close to what you want, one thing I would suggest is avoid setting values to 255 as they can be a bit bright, using 248 or 240 tends to give a softer colour that looks better). So load up paint.net, and in the Colors panel at the bottom left click the more button to expand the panel and it will now show the RGB value of the selected colour and as you change the colour on the colour wheel you'll see the RGB values change. Alternatively there is a colour picker included within the game – just go to Preferences -> Interface -> Skin Colours, then click on one of the existing colours and a colour selector pops up where you can select a colour and get its RGB value. So what you now need to do is to copy the box colour codes from the 'fm dark-widgets settings.xml' file into the 'my_first_skin settings.xml' file. Now I want you to adjust the RGB values of each item, the values aren't important but these are the ones I have used as an example: <colour name="box_background" red="50" green="150" blue="150"/> <colour name="box_border" red="150" green="50" blue="50"/> <colour name="box_shadow" red="248" green="200" blue="0"/> Which gives me something that looks like this in game: So with a simple change of the RGB values above I have managed to make the blue part of our actual graphic appear red whilst making the red part appear blue and the green appear yellow, if I am not happy with these colours or the shade changing them is now just a matter of tweaking the RGB values until I am happy, which is a whole lot easier than previous games where you'd have to actually adjust the colour of your graphic until you are happy. However one problem you'll have noticed is that when we recoloured this box it also recoloured the rest of the boxes on this screen even though they actually use a different graphic, this is because as you may have noticed from the comments in the file these three Colour Variables control the colours of most of the boxes in the game. In a normal situation this is exactly what you want to happen, by just changing those three lines of code you have recoloured most of your skins graphics, however you'll notice that the other boxes are a different shade of blue and have no yellow or red in them, this is because they are still using the default graphic file which if you remember was just a slightly transparent red image, as their base image has no blue or green in it there is nothing for the game to recolour, if you wanted these images to change you'd need to actually change the base graphic that makes up these boxes as we did above for the subsection box. As this is a guide what we want to do next is assign the subsection box graphic to its own unique colours. To do this what you need to do is go back to the 'paper.xml' file and locate these three lines again; <colour id="red_replacement" name="box_background"/> <colour id="green_replacement" name="box_shadow"/> <colour id="blue_replacement" name="box_border"/> And what we are going to do is change the name they are assigned to. There are a couple of ways to do this the simplest one is to simply assign them to a different pre-existing Colour Name, and to make matters easier the Colour Name doesn't need to be declared in your skins settings file the game will still read the values from your parent skin or from the default files (if you want to use a colour not from your parent skin you need to ensure the colour isn't declared in the parent skin otherwise you will need to copy the colour over to your skin). As an example I am going to reassign the above values to the below names: <colour id="red_replacement" name="low attribute"/> <colour id="green_replacement" name="yellow card"/> <colour id="blue_replacement" name="colour side bar"/> So the Red parts of the graphic have been assigned to the 'low attribute' Colour Name, which if you followed the last guide should be declared in your 'my_first_skin settings.xml' file. (Which should be a Red colour) The Green parts have been assigned to the 'yellow card' Colour Name which is drawn from the 'fm dark-widgets settings.xml' file. (Bright Yellow) The Blue parts have been assigned to the 'colour side bar' Colour Name which is drawn from the 'fm colours.xml' file. (Dark Grey) When assigning the Colour Names it doesn't matter if you use ones that are normally assigned to text colours, as the game doesn't make any distinction between text and graphic colours, you just need to be careful if you change the RGB values of a variable that is also assigned to a bit of text as it will also change the text colour. After you have carried out the above changes, reload your skin in FM15 and your player profile screen should now look something like this: As you can see the attribute box has been recoloured to red and black with a yellow border, whilst the other boxes have kept the previously set blue colour (if you want you can delete the three box lines we previously added to the settings file to set them back to the default grey colour). Another option if you cannot find existing colours that suit is to just create your own custom Colour Name variables and assign them the RGB values you want, you can call these variables anything you want you just need to make sure you are using unique names that haven't already been used elsewhere by the game otherwise you'll end up recolouring random bits of your skin. To do this you first need to change the names the replacement colours are assigned to in the 'paper.xml' file so for example I am going to change them to the following names: <colour id="red_replacement" name="example_red"/> <colour id="green_replacement" name="example_border"/> <colour id="blue_replacement" name="example2"/> Next you need to add and declare these custom Colour Names in the settings file so in the 'my_first_skin settings.xml' file paste in the following code: <colour name="example_red" red="150" green="175" blue="150"/> <colour name="example_border" red="75" green="75" blue="75"/> <colour name="example2" red="175" green="125" blue="125"/> This gives you this in game (with the old box colours removed so the other boxes reset to default colours): You can add as many custom Colour Names to your skin as you want, you just need to remember to locate the xml file that declares what Colour Names the replacement colours are assigned to, a future guide will give you some hints on how to find these files, though some bits are hardcoded to either a certain colour or a certain Colour Name so your ability to adjust these items are limited. How to only recolour the skin If you only want to change the colour of the skin and not the shape or pattern of the graphics that make up the skin, then you can skip a few steps. In this case the only file you need to really edit is the 'my_first_skin settings.xml' file and is done in pretty much the same way as you editing the text colours. What you need to do is copy over the colour code from the default settings and colours xml files that corresponds to the part of the skin you want to recolour. Now most of this code is commented so it should be relatively easy to work out what it controls, if you aren't sure you can copy the code over and then adjust the RGB value to a distinct colour and have a look at what has change in game. I'll give some hints on how to found out what does what in a later guide, however for the moment some trial and error should get you most of the way and if you still cannot find out what controls something just have a look in the forum to see if it has already been asked and if not just open up your own thread and hopefully someone will have found the answer. What I would advise when doing this is to copy over the code for one item, recolour and check it, then paste the code for the next item and repeat until everything is recoloured, as if you copy over all the colour settings at the start you might get a bit lost regarding what you have changed. What you can also do is add your own comments to the xml files, so you can note that you have changed something, or if you have just found what something controls you can make a comment telling you what it controls. Recap As this has been a fairly long guide I'll do a quick recap. The first thing you need to do is locate where the default graphic files are, which for dark full-mode skins should be contained within the 'skins\fm-widgets\graphics' folder. The exact location can be a bit tricky to work out, but I'll give you some tips in a later guide. Next if you want to edit the actual graphic or change the settings within its xml file you need to copy the png or xml file you want to edit into the same location for your skin, which involves creating the same folder path if not already present within your skin. (Though instead of copying the png graphic over you can create a new png file in the same location for your skin, you can also create a new xml file if you wish and manually type the code but it's easier to just copy the xml files and then edit). If you are editing the shape or pattern of the graphic the only three colours you can use are Red (RGB: 255,0,0) Green (RGB: 0,255,0) and Blue (RGB: 0,0,255) as the game now recolours the graphics. (If you use other colours the game will still recolour them but it might not recolour them correctly). If you have given your new graphic a non-uniform shape or pattern the next thing you need to do is make sure everything lines up correctly in game. If it doesn't then you may need to adjust the image slicing, the image borders or the title inset values in the xml file until everything fits. When recolouring the skin graphics there are a couple of methods depending on what you want. The first thing you need to do is to work out what Colour Names each base colour is replaced by, to do this you need to check in the xml file which has the same name as the graphic and is located in the same folder. If you are wanting to recolour the skin in general, then once you have located the correct Colour Names it is just a case of copying these into the xml file inside the settings folder for your skin (if not already present) and then adjusting the RGB values to suit. However if you are only wanting to adjust the colours of this particular item, then you can change the Replacement Colour Names in the graphics xml file and either assign them to an existing variable that has the correct colour or create a custom Colour Name and then declare its RGB values in the settings xml file. Once that is done check how it looks in game and if you are happy then move onto the next item. And in no time at all you should have a nicely recoloured skin. You can find downloadable versions (pdf and docx versions at the moment) of this guide at the bottom of this page on my website. --- Redistribution Terms You are free to post this content to your website provided: 1. It is not sold or behind a paywall. 2. You don't advertise it as being exclusive to your website. 3. My username and blog address are included: http://michaeltmurrayuk.blogspot.co.uk/
×
×
  • Create New...