Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Klofkac last won the day on September 20 2019

Klofkac had the most liked content!

Community Reputation

107 Excellent

About Klofkac

  • Rank
    Desert Warrior

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. So, here you go: https://www105.zippyshare.com/v/RV6oYsqt/file.html This is the second preview version, here is list of changes done from the first preview version: - Finished support for editor attributes. Editor attributes are no longer part of TILEATR*.BIN file, but are now part of tileset .ini file. The program will save editor attributes into .ini file when you save changes in tile attribute editor, so be careful to reload the .ini file if you have it open in any text editor. If you still have TILEATR*.BIN file used by older version of editor containing editor attributes in it, click the "Convert" button to convert editor attributes into the new form and save. - I also modified minimap color rules, fill area rules and spice restriction rule in original tileset .ini files to follow the changes in editor. For example editor attributes now use different hexadecimal values. You will need to modify your custom tiliset .ini file to make it work properly with new version of editor. - Added smooth spice rendering feature - Added support for editing tile hint texts - Added better support for custom TEXT.UIB files. Now when you test a map with custom TEXT.UIB file specified, the game will be launched with that custom TEXT.UIB file. The editor will also load and use texts from custom TEXT.UIB file and will display them in "Edit tile hint text" mode. One tip: if you are editing for example minimap color rules and want to immediately see the change, just save changes in your text editor and in Tile Attributes Editor, use Reload Attributes option. The program will reload .ini file and will redraw minimap. This is also useful with "Draw minimap colors" mode. Enjoy!
  2. Well, I still have some stuff to do. For example the editor should load texts from custom text.uib when loading a mission where it is specified. Right now it loads only the default text.uib (that can be at least defined in D2kEditor.ini file). This is a missing feature, in past it was not much important, as messages triggered by events would be specified in mission's ini file and not usually in custom text.uib anyway. But with this new feature it is more needed. But I want to release a preview version once this is complete, and then eventually finish other minor stuff. Well, I do not really much know all the stuff and story, that was rather a quick simple demo I made. But you know, those hint texts will be really very useful for players without knowledge, including me 😏.
  3. Surprise! It's indeed exactly what I thought it was! So the so-far unknown second section in TILEATR*.BIN files defines the hint text which displays when mouse cursor is moved over a tile. In original tilesets, it was used only on spice tiles. This is rather a cosmetic thing, but can be pretty useful too. Here I made some demonstration about how it can be utilized in your Heighliner tileset maps! You can give different hint text to supplies, MD pads, and any other sort of tile you like. And here is the most useful combo: Combination of "Occupied by Building" attribute and hint text. This way, cursor will turn into selection cursor and structure name will be shown. And in addition, the structure will be drawn in respective color on minimap. But beware that minimap color is driven by respective side's allocation index, so if you alter allocation indexes, the minimap color will change too. I already added this feature into D2kEditor: And you need to define the texts in your custom text.uib file: I hope you find this interesting and make use of this feature in your tileset and maps!
  4. Ooh, thank you! Honestly, I was not thinking that simple. I'll try this out and update the graphics with the editor! Well, to be honest, I do not play that much (sometimes I get some other interest than Dune2000), so I did not play through many custom campaigns yet, including this. But after I release D2kEditor v1.4, I'm hoping you would take advantage of all the newly discovered modding possibilities and update your tilesets and maps. Then I will definitely eager to play that maps! I'll just wait for it. Right now you can experiment with the preview version of attribute editor I published in the other thread. I did not get into this yet, will continue some other day. But I'm also looking forward to figure this out!
  5. Good idea, but I would rather like to mark those "special" tiles used by game and mention what purpose it is used for and explain how it needs to be handled with special care. Well, I did never notice myself either while playing the game for years. But once I wrote numbers on the tiles and filled whole map with thick spice, it was very easy to recognize the number pattern. Yea, good idea and I agree with you, but it was quite difficult and laborious to take an image of all the in-game buildings and units graphics. I needed to take screenshot from in-game and then join all the screenshots into one big image, and then take care about transparency etc. I don't feel like doing this work again, but still, good reminder. This is already fixed in version 1.4: editor will use only three concrete tiles which are used by game. Previously editor used all 6 because I did not know about this. Nope, even on extra tall buildings, the 3x2 basement is used. But you can confirm with all kinds of buildings to be sure. Humm, thaat sounds interesting! Actually, the TILEATR*.BIN files have two distinct sections: one with 800 attribute values, and the second with 800 strange values: it's #FFFFFFFF for all non-spice tiles, and some other value only on spice tiles. Maybe those values define the text that shows under mouse cursor when you move it over that tile. If this is right, that would even increase modding possibilities! I'll definitely check that out! Yea, I really enjoyed playing missions with custom tilesets (your Heighliner tileset and Cm_blast's Warcraft 2 tileset), which inspired and encouraged me to do all this stuff! Thank you for your work too!
  6. Hello, as I already mentioned recently, I'm working on new version (v1.4) of Dune2000 Map and Mission Editor. Right now I have two most important new features complete: built-in tile attribute editor, and newly: Smooth Spice rendering! No longer ugly blocky spice, but now it looks exactly like how it is drawn in game. It's so fun and satisfying to place spice on a map and see how the tiles prettily connect to each other! I still have a couple of minor improvement ideas to implement: just stay tuned, I'm going to publish a pre-release version soon. Feel free to give me any more ideas for features, bug fixes and improvements if you have any. As you may notice, my primary aim for new features in v1.4 is easier custom tileset creation. So while implementing smooth spice rendering feature, I also did some new research about some special tiles and how the game handles them. By special tiles I mean those tiles, which the game uses internally during gameplay to alter the map based on player's actions (building, harvesting spice etc). These tiles are used to draw for example concrete, basement of buildings, thin spice and thick spice, and most importantly, the tiles which game will draw on a place where spice has been harvested, or where building or concrete was removed/destroyed. This information may be very useful and valuable for custom tileset creators, and this also influences the limitations of custom tilesets. For my research, I used a modified version of tileset BLOXBGBS. I wrote numbers on some special tiles, and those numbers would show in-game so that I can better see which exact tiles the game uses. I marked some tiles with red color, which means, those tiles would never be used by game. Here it is: The most important is, that you can safely replace the red-marked tiles by whatever custom tiles you want, without breaking the game. Only 8 sand tiles (marked 1,2,3,4,6,7,8,9) are drawn by game on tiles where you harvest spice, and only 8 rock tiles (marked 1-8) are drawn by game on tiles where you destroy/remove a building or concrete. The 3x3 building basement is not used by any building. Only three tiles are used to draw concrete in game (marked 1,2,3) and the others (4,5,6) are unused. And the very first two full-spice tiles are not used as well, and finally, tile 795 either. Which, in result, gives you 33 extra tiles you can use, and which you previously mostly left intact to be safe and not break the game. Here you can see some in-game screens to see how it works: Only 3 different tiles are used for concrete. Only 8 different rock tiles are used on place where you destroy concrete or remove a building. Only 8 different spice tiles are used on place where you harvest spice. And the last, most interesting finding: The game draws thick spice in the same exact pattern always in all maps. The pattern is 8x8 tiles and repeats. I hope you found this information interesting and useful. Happy modding!
  7. Wow, you are still around FedaYkin! I thought you're not active anymore, so nice to see you again. The Dune 2000 modding community is not so strong as it used to be, I feel I'm doing new version of editor for less people than there are fingers on a hand. I hope these new possibilities will be somehow utilized in interesting ways. The main goal of new version of the editor is easier creation of custom tilesets.
  8. Actually the "unknowns" on vanilla maps are something completely different, not related to tile attributes. These are special values defined on the map itself (special value tells which building or unit should spawn on that tile when the map starts). But tile attributes are tied to tileset and are defined in TILEATRx.BIN tiles. Well, maybe. I don't know. We can only speculate.
  9. Hello all, most probably you already know something about tile attributes and those TILEATRx.BIN files. Tile attributes are defining the behavior of each tile, i.e. whether vehices and infantry can move on this tile, whether buildings can be placed on that tile, whether your units move slowly etc. Each TILEATRx.BIN file contains 800 entries (one entry for each tile, there are 800 tiles in tileset), each entry has 32 bits. 32 bits means there can be 32 different attributes for each tile (a bit can have two values: 0 or 1, off or on). In the original TILEATRx.BIN files shipped with the game, only 7 out of 32 attributes are used. Which leaves 25 attributes unused. Because the editor needs some extra information about tiles, which cannot be determined from existing attributes used by game, I decided to use 8 more bits (from those 25 unused bits) to store "Editor Attributes". These extra attributes tell the editor which tiles are sand tiles, rock tiles or dunes tiles, or the respective areas, so some of the features like fill area can work. I was assuming that using those 8 extra bits, which were not used in any of original TILEATRx.BIN files, would not affect the game behavior at all, but still, to be 100% safe, I decided to use two separate versions of same TILEATRx.BIN file: The original one for game, and the modified one (with extra attributes added into it) for the editor. However, later it turned out, that those extra "editor" attributes, which I thought were not used it game, are in fact used by the game, and are affecting game behavior. So if you take the TILEATRx.BIN file shipped with editor, and copy it into game folder, strange things will start happening, for example your units cannot move on tiles where they should normally be able to move. So I made some research in order to find out what's going on. And I discovered, that all those extra 25 attributes are game's internal attributes, which are added/removed from tiles by game logic during gameplay. These attributes were not meant by game authors to be used directly in TILEATRx.BIN files, however, you can exploit them to alter game behavior and have more modding possibilities. For example, you can place a real working concrete on you map! Here is the complete list of all those 32 attributes and their meanings. Attributes marked with * are those 7 attributes which are used in original TILEATRx.BIN files. 01: Building/Unit owner side (bit1) 02: Building/Unit owner side (bit2) 03: Building/Unit owner side (bit3) 04: Occupied by Unit 05: Occupied by Building 06: Occupied by Infantry (middle) 07: Occupied by Infantry (top-right) 08: Occupied by Infantry (down-right) 09: Occupied by Infantry (down-left) 10: Occupied by Infantry (top-left) 11: Wall 12: Concrete 13: Non-buildable 14: * Vehicles can pass 15: * Infantry can pass 16: * Buildings can be placed, Rock craters 17: * Sandworm can pass, Sand craters 18: Concrete owner side (bit 1) 19: Concrete owner side (bit 2) 20: Concrete owner side (bit 3) 21: Spice amount (bit 1) 22: Spice amount (bit 2) 23: Spice amount (bit 3) 24: Unknown/Unused 25: Unknown/Unused 26: Unknown (side bit 1) 27: Unknown (side bit 2) 28: Unknown (side bit 3) 29: Unknown/Unused 30: * Rock (wheeled +10% speed) 31: * Dunes (wheeled -50%, other -20% sp.) 32: * Rough Rock (all -50% speed) Now let's try to explain them. 05: Occupied by Building: Units cannot move on this tile and buildings cannot be placed. Cursor changes to "select" cursor when moved over this tile, like when cursor moves over a building or unit, but clicking will not do anything. The color of this tile on minimap changes to color of respective side, which this "building" belongs to (blue for Atreides, red for Harkonnen etc). The side who owns this "building" is defined by first three attributes: 01: Building/Unit owner side (bit1), 02: Building/Unit owner side (bit2), 03: Building/Unit owner side (bit3). Set those attributes to following possible combinations (0 = attribute not set, 1 = attribute set): 000 = Atreides 100 = Harkonnen 010 = Ordos 110 = Emperor 001 = Fremen 101 = Smugglers 011 = Mercenaries 111 = Sandworm If the owner is your side, you can place buildings near this tile, like when there was standing your own building. And same for the other AI players. 04: Occupied by Unit: Units cannot move on this tile and buildings cannot be placed. If you place any unit on a tile with this attribute with the Map and Mission Editor, the game will crash with error message "Tile already occupied by unit". Again, use first three attributes to define which side this "unit" belongs to. If the unit belongs to your side, cursor changes to "select" cursor when moved over this tile. Minimap is not affected by this attribute. 06 - 10: Occupied by Infantry: The tile behaves like there was infantry standing on the tile at one the 5 respective positions. I.e. if you use all 5 attributes, infantry is standing on all 5 positions. Again, use first three attributes to define which side the "infantry" belongs to. If the infantry belongs to your side, cursor changes to "select" cursor when moved over this tile. If you do not use all 5 attributes and the owner side is you, you can move your infantry on this tile, but they will be able to stand only on the "free" positions. If the owner side is not you, you cannot move your infantry on this tile even if there are free positions (like you cannot group your and enemy's infantry on same tile), but you can move heavy vehicles on this tile (i.e. tank, harvester etc.), like they were crushing enemy infantry, if the owner side is your enemy. And most importantly, your stealth units will get revealed when standing next to tile with this attribute whose owner is not you. 11: Wall: The tile behaves like a wall or turret. When you place a wall or turret next to a tile with this attribute, it will visually link to that tile, like when there was built a wall (but you can build and move units on this tile). 12: Concrete: The tile behaves like concrete. You cannot build concrete on this tile, but placing other buildings on it, they will not damage over time like they were built on a concrete. The tile is destructible, so when you shoot it, it will turn into rock tile and lose its effect (then you can build concrete on it). The side who owns the "concrete" is defined by these three attributes: 18: Concrete owner side (bit 1), 19: Concrete owner side (bit 2), 20: Concrete owner side (bit 3). Use same combination of values, like for buildings and units. If the concrete belongs to you, you can build on it even if no other your building is near, and you can place buildings near it too. 13: Non-buildable: You cannot place buildings on this tile, even if "Buildings can be placed" attribute is set. Apparently this attribute is internally used on tiles below buildings where you can move units but not place other buildings. 21 - 23: Spice amount: If all three are not set, the tile behaves normally. But if you set any combination of these attributes, the tile will graphically change to thin or thick spice, and will behave like spice, i.e. Harvester can harvest it and it will disappear once fully harvested. Possible combinations: 100 = Thin spice, can be harvested only once, then disappears 010 = Thin spice, can be harvested twice, then disappears 110 = Thick spice, can be harvested only once, then turns into thin spice (can be harvested 3 times total) 001 = Thick spice, can be harvested twice, then turns into thin spice (can be harvested 4 times total) Other combinations = Thick spice, cannot be harvested 26 - 28: Unknown: To be used with combination with "Occupied by Infantry" attribute. If you run over enemy infantry (meaning tile with "Occupied by Infantry" attribute) with a heavy vehicle, then owner of that infantry becomes the side defined by these three attributes. Meaning, if you are for example Fremen and set attributes 26-28 to combination of 001, and attributes 1-3 are some other value (enemy) and you move your heavy vehicle on this tile, the tile changes its behavior like it was your infantry - you can no longer move heavy units on it but can move infantry on free positions. Other function of these attributes was not discovered yet. So, here are a few examples what useful things you can do with these attributes: - Place real working concrete on map, and you can use any tile for it, not necessarily the concrete tiles in tileset. If you do not want you or enemy or other player to be able to build on it or next to it if no other building is near (i.e. the concrete is placed on separated rock area and you must only use MCV to reach it), make Sandworm as owner of the concrete. - Make some tiles appear on minimap in specific side's color, like it belonged to that side. Useful for some static structures and buildings, which are part of tileset graphics. (not confirmed if it affects AI behavior) - Make "narrow infantry passage", like a very narrow tunnel where only 1 infantry can walk through. Or make that infantry can stand only on specific positions on specific tile. The big disadvantage is that this works only for one side, who is defined as owner of the infantry attribute. - Make "heavy vehicle only" passage, exploiting the "Occupied by infantry" behavior - Place thin spice which can be harvested only once, or thick spice which can be harvested 3 times total - Make spice you can place buildings on, or after harvesting it (if you combine "Buildings can be placed" and "Spice amount" attributes) I'm currently working on improved version of "Tile Attributes editor" and integrating it into "Map and Mission editor", so it will no longer be a separate program. Here is a preview incomplete version I'm working on. For example editor attributes are not working yet. After it's fully finished I will release it as Map and Mission editor v1.4. You can use it and play around with the extra attributes, and possibly discover some new things! Download: https://www90.zippyshare.com/v/IruQNN0N/file.html
  10. Spice can be recolored on minimap. In ini there's Spice_Settings section or something like that, where is property something like ThinSpice_Color and ThickSpice_Color. Well, this is something different than you think, I did not mention that to keep things simple. The first value ($6000) means: "Look at vehicle can pass and infantry can pass atribute", the second value ($4000) means "Only infantry can pass attribute must be set". In other words, all the rule means "The tile must have infantry can pass AND must NOT have vehicle can pass attribute", in other words, this matches infantry-only tiles. But as I said, it is very confusing and not very well designed, I did not use it in the example not to confuse you even more.
  11. Well, I was thinking this way: The only buildable tiles are snow tiles. Therefore, I can write just simple rule "All what is buildable uses snow color". All buildable tiles always have "Vehicles can pass" and "Infantry can pass" attribute. So I could even make rule $E000 (which is buildable + vehicles + infantry), and it would work exactly the same way. I just wanted to make things as simple as possible. However, in fact, there are a few buildable tiles in tileset, that are not clear snow. These are some decorative tiles to not make snow look so plain, which you place here and there. Clear snow tiles have attribute "patint type 2", while those decorative tiles do not have it. So in case you would want to use different color for clear snow and decorative buildable tiles, you would use two rules in this order: $8002 (buildable + patint type 2) = clear snow $8000 (buildable) = decorative buildable tile Well, as I already mentioned, you specify rules from most specific to least specific. In this case, you can probably swap order of Dark Snow and Thin Ice without changing the behavior. Also, "Rough" rule would be probably enough for thin ice, granted that no other tiles in your tileset than thin ice use "Rough" attribute. Generally, there are more possible ways to specify rules for your tileset. You must just think logically a bit more. If that's a problem, you might just use trial and error and see what happens.
  12. In the other thread ([Release] - New Dune 2000 tileset. Warcraft 2 snowdy + bonus mission) I had some discussion with Cm_blast regarding configuring minimap colors in tileset .ini file. It seems it's still quite unclear (I tried to write some hints in template.ini file, but that's likely not enough) so I'll try to explain that here in more detail. I will split the tutorial into two main parts: 1. How to define the color 2. How the rule processing works Ad1) You most probably already heard of hexadecimal representation of a color (you can play around with it here: https://www.w3schools.com/colors/colors_hexadecimal.asp). Basically each color composes from its red part, green part and blue part, each part is represented as hexadecimal number from 00 (0) to FF (255). Hexadecimal representation of whole color looks like #RRGGBB. In D2kEditor's tileset ini file colors are reprsented a little differently, the blue and red parts are swapped, so it's like $BBGGRR. So when you for example want to use color #b370c4, in ini file you need to write it like $c470b3. If it's hard to find the exact value of color you want to use, I use this trick to get it easily. I use IrfanView for this. Here are the steps: - Open the tileset image (or map image) in IrfanView. - You can double or quadruple the size of image so that you can more easily pick the pixel from a tile, whose color you want to use. When resizing, use "Resize" option instead of "Resample", which would screw up the colors. - Click with mouse on the pixel you want. In the window title, hexadecimal value of color will show up. - In tileset .ini file, write the value as $733900 for the color from above example. Ad2) Let's use this example: [Minimap_Color_Rules] ;Snow $A59494=$8000 ;Pieces $5A4A31=$40006000 ;Dark snow $9C8484=$6000 ;Thin ice $8C4A10=$80004000 ;Thick ice $8C5218=$4000 ;Deep water $733100=$8 ;Water $733900=$0 Each rule is written on one line. Ignore the lines starting with ; as these lines are only comments, used for human's better readability and understandability. A rule consists of two parts: the color (on left side of = sign) and Tile attribute value (on right side of = sign). Rules are processed from top to bottom (from the first specified to the last specified) and in case a rule is matched, then its color is used, otherwise it continues with next rule. If no rule is matched on the way, then color of the very last rule is used. The attribute value contains attributes, which a tile must have in order to match the rule. Look at the first rule: $A59494=$8000 If you put the value 8000 into "Tile attribute value filed" in TileAtrEditor and click OK button, you will see that only "Buildings can be placed" attribute is selected. Which means: Tile must have "Buildings can be placed" attribute to match the rule. Other attributes do not matter at all. You must write "most specific" rules first, and "least specific" rules later. This can be seen on "Pieces" and "Dark snow" rule. Pieces rule have "Vehicles can pass", "Infantry can pass" and "Dunes" attribute, which is value 40006000. Dark snow rule have only "Vehicles can pass" and "Infantry can pass" atrribute, which is value 00006000. So "Pieces" rule is more specific than "Dark snow" rule, because "Dark snow" rule matches both dark snow and pieces, but "Pieces" rule matches only pieces. That's why you must specify "Pieces" rule first. The last rule ("Water") does not have any demands for attributes, so it simply matches every tile. This is why you must specify it very last. Fill area rules are very similar. The left side of rule is not a color, but it is group number. Each tile belongs to specific group according to the rule, and "Fill area" function will flood-fill area consisting only of tiles from same group.
  13. You are perfectly right there, it seems you understood correctly. Either deep water, trees or mountains have same attributes (no attributes, meaning you cannot walk or build on them at all), so you need to use some extra information to distinguish between them, and that is simply attributes that won't impact the game behavior. You have two options, either use editor attributes (area type 1, 2 etc), OR you may use some of the game attributes that have no impact on behavior ("sandworm can pass", "wheled", "dunes" and "rough rock") and combine them to have 16 possible colors. These editor attributes were made because in some situations the game attributes could not be used (they would impact the game), that was mostly needed for fill area rules, so you could simply erase whole rock area without impacting adjacent sand, dunes etc. Later I will try to better explain how those minimap color rules work.
  14. I just tried this out, and I really like having some different environment than sand and rocks from Dune. The tiliset is pretty colourful and nice to look at, and there are different types of tiles to move/build upon (snow, ice). The map was a bit hard due to enemy having more powerful units and limited amount of "spice", but I enjoyed that. I could have played it better to beat it faster, and unfortunately I missed that secret area (I knew I could explore that, but did not bother). From technical point of view, good work configuring new tileset and attributes. Making maps with this tileset would probably need some practice, but those presets can help a lot. However, I can see you did not utilize all tileset .ini file features. Most importantly custom minimap colors, and "SpiceRestrictionRule" setting, that controls which tiles you can place spice on. I can see you made that quirk using special "SPICE HERE" tile, which is definitely not necessary - you just change "SpiceRestrictionRule" and you can place spice on tile types you specify there. Even without that, in D2kEditor.ini you can change "RestrictSpiceToSand" setting to 0, and you can simply place spice on any tile. But still good work, I'm looking forward to see more maps made with this tileset, and you could try improving the tileset .ini file (I can help you). Edit: Here I quickly came up with some minimap color rules, you can try this out. Unfortunately there's no way to distinguish deep water, trees and mountains by attributes, that's exactly what Editor attributes like "Area type 1-4" were made for. If used properly, all could be displayed with different color on minimap. [Minimap_Color_Rules] ;Snow $A59494=$8000 ;Pieces $5A4A31=$40006000 ;Dark snow $9C8484=$6000 ;Thin ice $8C4A10=$80004000 ;Thick ice $8C5218=$4000 ;Deep water $733100=$8 ;Water $733900=$0 And spice restriction rule: SpiceRestrictionRule=$2000E002
  15. Yes, I think I'm getting your point. However, even if the upper area is connected to your base area, it won't give you that much extra room to build (even if there's place to build just one 3*3 building), so if you still want to expand more and have more space, you need MCV anyway and take over some other isolated island. I remember in original Dune 2 I played a mission where player's area was connected with enemy area so I could build a concrete path to them. In some missions the player's areas had very bizzare shapes, something similar to lower and upper narrow areas in your map, and I could build long concrete paths on them. It was something like an iconic thing to Dune 2 terrain. So I expected your map was made to mimic aspects of original Dune 2 as much as possible, including this terrain quirk, and your map was very exactly desigled like that, the only missing thing was buildable edge and narrow tiles. The only problem in this map I see is that the upper narrow rock area is too close to quite big isolated area above it, so that you could concrete-jump on it. You could fix it by moving the areas farther to each other to avoid that. Note that in Original Dune 2, I seldom built a MCV to expand my base on other island, so if I don't build it in your Dune 2000 map, just don't worry, that's the way how I'm used to play. When I earlier played your map, at the time edge tiles were not buildable, I didn't build a MCV anyway. And in my opinion, if there are other players who like building and using MCVs, they will do that anyway even if they can now expand a little bit more on those narrow tiles. It's more about "making both kinds of players happy".
  • Create New...