lovalmidas

> Extended limits to maximum of 1024 events and 256 conditions (needed to extend MIS file format) It is refreshing to see someone achieve what I could not. It looks like you have also handled the support for the old capacity and format. Great work! The theoretical limit to the number of different types of events and conditions should be 255 (0xFE) or 256 (0xFF), because that is storage of the type is one byte. The game has an internal check for the event and condition ID so as to produce an error if the read ID exceeds the old limit, but the patch can easily override that. The rest is a matter of developing the switch behavior. Some additional suggestions based on my rusty knowledge, and what I had wanted to do before: - In Event 12 / 0x0C - Switch My Side, there is the option of setting the enable AI. I suggest that we keep that option as it is, but also create an event to set only the AI for a house (similar to Event 06 / 0x06 - Set Build Rate and similar events). I guess it can be called Set AI, and the parameters can even be extended to include House and AI Enabled for a start, but also allow the future inclusion of EnablePractice, BuyUnits, UpgradeBuildings, RebuildBuildings, DontSell, GuardBase and GuardBuildings (more if you are willing to use the full set of 48 bytes in the event to its full potential). A possible favorite for mappers and scripts could be the SpecialWeaponDelay, but that may take up several bytes. - In Event 08 / 0x08 - Set Cash, a good expansion to the event is a switch (we can use the byte reserved for Deploy Action in Reinforcement / Unit Spawn) to determine different behaviors, such as: > 00 - Convert Spice to Cash and Set Cash (the default behavior, spice is set to zero / silos are emptied and the cash amount is set) > 01 - Preserve Spice and Set Cash (preserve the spice amount, and set Cash to the value - Spice, unless there is not enough Cash, then deduct from Spice) > 02 - Convert Spice to Cash and Add Cash (spice is set to zero / silos are emptied, the previous spice amount is added to cash, and the value is added to Cash) > 03 - Convert Spice to Cash and Subtract Cash (spice is set to zero / silos are emptied, the previous spice amount is added to cash, and the value is subtracted from Cash down to 0) > 04 - Convert Spice to Cash and Add Spice (spice is set to zero / silos are emptied, the previous spice amount is added to cash, and the value is added to Spice. Spice may be lost in case of insufficient spice storage) > 05 - Preserve Spice and Add Cash (preserve the spice amount, and the value is added to Cash) > 06 - Preserve Spice and Subtract Cash (preserve the spice amount,, and the value is subtracted from Cash down to 0) > 07 - Preserve Spice and Add Spice (preserve the spice amount, and the value is added to Spice. Spice may be lost in case of insufficient spice storage) > 08 - Preserve Spice and Subtract Spice (preserve the spice amount, and the value is subtracted from Spice down to 0) - Add Event "Add Unit to Starport Shop" (or a similar name), with two parameters: Amount and ID, to add the specified quantity to a unit availability on the Starport order tab. The IDs on the original game shall be: 00=Trike, 01=Quad, 02=Harvester, 03=Combat Tank, 04=MCV, 05=Missile Tank, 06=Siege Tank, 07=Carryall, but can change if Templates.bin is modded. This gives some control over the Starport shop to the mission creator. - In Conditions 00 - Building Exists and 01 - Unit Exists, I do not know how feasible it is, but we can see if conditions Building Count and Unit Count can be made. The search algorithm has to be retrieved from the XX Exists function and studied so it can be made to count instead. XX Exists will be a special case of XX Count where the required count is 1. This can be useful to enforce a defense of several bases (e.g. Protect all 5 Refineries) without consuming precious house allocations to implement via Building Exists. - For the following conditions, possible use of a special House value -1 (0xFF) as "Any House" to indicate a full map search inclusive of all 8 house players (implementation could simply be to run the function 8 times, one for each house and stop on success): > 00 - Building Exists, > 01 - Unit Exists, > 08 - Spice Harvested (if the specific side is shown) - Add Condition "Spice Storage", to compare the amount of Spice Storage similar to "Spice Harvested". This could be useful to enforce fail conditions where the player has lost the ability to acquire new silos to meet a certain "Spice Harvested" quota. - Several more conditions can be made if the in-game statistics can be read. Possibilities include: > "Buildings Destroyed" > "Buildings Lost" > "Units Killed" > "Units Lost" > "XX Building Owned" > "XX Unit Owned" - Outside of the events mechanism, I think it may be possible to allow larger reveal radii by extending CIRCLES.bin. But it also involves a patch into the EXE so that it reads more of CIRCLES.bin than the present 8 entries. As a refresher, CIRCLES.bin comprises of 8 sets of masks (00 - within circle, FF - outside circle), when read from the front, spells the values for 1x1, 3x3, 5x5, 7x7, 9x9, 11x11, 13x13, and 15x15 (radius 7). This could impact sight radius and map reveal events.

In TibEd, this is encoded in the flag "MoveInfantryZone" for each unit, which on a hex editor represents byte (0x100 * n + 0x11 in Templates.bin file, where n is the Unit ID). My experiments seem to tell me that setting determines if the unit is an Infantry or a Vehicle: MoveInfantryZone (in TibEd; this looks more like "IsInfantry". Values: 00 , 01) * If not an infantry: (1) The unit occupies a full square and not a sub-square. (2) The unit no longer moves into infantry-only zones. (3) The unit loses its firing and death animations (and perhaps the death voice too?) (4) The unit emits smoke at half-health (5) The unit is no longer eligible to be ejected from a sold building. In this case the next available infantry, e.g. the Trooper is used instead (6) The unit is eligible for worm attack The last point is the item you are looking for. Unfortunately, this control comes as a single switch that controls several things at once. It is not yet certain if finer controls exist for each individual items. If not, you might need some heavier editing (either through other files, e.g. hide the smoke by figuring out invisible smoke, or editing the game executable itself which is not trivial) if you need just the worm attack.

I have not had time to read that yet, but the only thing that is really important in UnitTemplate / BuildingTemplate, in relation to data.R16 and rendering, is the UnitArt / BuildingArt / TurretArt entries (as seen in TibEd). If you want to render stealth, perhaps also the Special Logic entry. The idea is that art entries are divided into UnitArt (each entry with X frames * D directions), including turrets BuildingArt (1 BuildingBase + D directions (healthy frames) + D directions (damaged frames)), including turrets ProjectileArt (X frames * D directions) Animations (used by explosions, building buildup animations, building active animations, smokes or some special animations (harvester docking) The sections after those main sections (Unit, Building, Weapon, Explosion) are what is important for the game to inform itself how many of each frames each entry takes. template_bin_sections.txt Data.R16 image order, as known thus far. This includes the context of other images (some to be confirmed). Generally, unit image data starts from the 206th entry, and then the game uses the information obtained from Templates.bin in order to determine how many entries are loaded for one art. sym_addenum.txt I think an editor can afford some leeway to not require exact rendering since an editor is not the game, although you can go ahead with an exact rendering if you want. Carryall and Frigates can be resized to 32x32 without much confusion since a single tile is the atomic unit in the map format (you can't preload 5 infantry in the same tile, unfortunately). For stealth, the stealth 'static' animation seems to be entries 178 - 193. And then the stealth alpha mask seems to be entries 194 - 205. Knowing whether a unit is stealthed is also a bit tricky, since: It involves reading the unit's definition for Special Logic. There is a hardcode in the game that applies stealth for a unit named "STEALTH RAIDER" (probably a coding afterthought since the unit is added in a patch, and the special logic infrastructure is not as modular as I thought it would be)

Yep. This is only a piece of the puzzle. I have not yet investigated how allocation indices drive the selection of the player house, but at some point I hope to make an edit to the executable so that the player house is effectively "alloc. index mod 8" instead of "Max( 7, alloc. index )", or a more flexible method, if possible. Loading custom colours.bin is probably the easier (and probably the preferred way in modded content), when you are willing to work with third-party launchers. The benefit of extended Colours.bin file with > 8 colors is mostly research points into finding out how the game handles allocation indices (Funkyfr3sh modded the game so that indices > 2 use Ordos unit voices & Announcer / EVA.) If this can be customized into a mapping (or extended to support more Announcers), that would be sweet (though this may require modifications to templates bin as well). With the templates bin format known, loading from Data.R18 may be possible. But I am still working on a template bin editor (that integrates with an Data.R18 editor) and it is definitely not a trivial endeavour. xD An easier alternative would be to extract only the images as a 8bpp image (I'm trying to get my Data.R18 editor to do that instead of exporting as true color RGB). Recoloring a 8bpp image is much easier as the palette is already embedded in the image. The current editors only export as a true color RGB so you may have to wait for me to finish my version, or try a hand in parsing the data.R18 file yourself.

The game happily reads whatever values that are in there so no crashes. It also happily reads beyond the size of the colours.bin file as padded 0x00 values. The memory space also initializes with 0x00 values. So extra colors were seen as black. I have a customized colours.bin with 3 house color sets (3 x 16 colors) and another with 16 house color sets (16 x 16 colors) to experiment with an exe modification that moves the memory where game stores and subsequently reads colours.bin, to allow proper rendering of 16 colors. Basically, the limitation of 8 house color sets is caused by the fact that the game allocates only enough space for them, and fills the space right after with other data, and it does not protect against invalid house index and happily reads from data meant to be for something else.

I only tried hex value 0x11. And it only reveals the tile if there is an unrevealed tile in some of its 8 directions (which ones is not yet certain). In effect, a unit moving towards a blob of shroud to its west will not reveal them. It doesn't depend on the direction the unit is moving (although that does the impact the visuals as the map is only updated in a limited NxN square region around the unit), it seems to check the surrounding tiles to determine if it should uncover this tile. At some time I could generate some screenshot or video to illustrate this.

For the reveal map 0 not updating the minimap, I found that the game updates the battlefield map and the shroud / minimap separately. For performance saving measures, the shroud and minimap is updated only within an NxN square centered around the reveal point (either a unit or a map location). For range 0, the square size is effectively 0x0 (or 1x1), meaning that effectively nothing is updated on the minimap. A quick fix would be to replace this logic with another that supplies the whole map dimensions. This fix may reduce performance, so I'll try to think of something to help branch this logic conditionally on range = 0. The results is sampled here, check the minimap: As for the minimap itself, this is interesting, but I have no in-depth knowledge of how saves recreate the minimap. Here is what I observed: Before save. (I am Ordos. Ordos structures to the north, Ordos units to the south. Map reveal triggers reveal Harkonnen base.) After loading Change map (dark grey is revealed before save, and shrouded after load) The battlefield itself follows the one after load. So the minimap is actually being revealed one tile beyond sight range into the shroud. Hmm... Edit: Added image for proof of concept

Great work! Probably a no-need-to-fix, I got a EInOutError when I loaded it with my working folder, which has some modified bin files. The cause appears to be the use of a modded Colours.bin which contained only colors for 3 houses (96 bytes) for my experimentation, instead of the expected 8 houses. The application closes after acknowledging this error message. A possible improvement could be to indicate to the user which file has an issue, but it is more of a nice to have. Enjoy your vacation nonetheless!

I apologize for spamming 'research topics'. I wanted to hijack an existing research thread for this file, but I didn't find a dedicated thread for it. The format of circles.bin is straight forward: A visual of the data There is a check that the game makes at address 0x0044e3ba to determine if the map reveal range is more than 7. If so, the game crashes with the message "Shroud circles only defined up to size 7." This much is probably already known. When loading a map, the game loads this file in these exact segments, storing them in these memory locations: Reference pointers to starting from 0x00547ff0 Location of data: 0 = 0x00548044 (1 byte data) (referenced by 0x00547ff0) 1 = 0x00548038 (9 byte data) (referenced by 0x00547ff4) 2 = 0x00548018 (25 byte data) (referenced by 0x00547ff8) 3 = 0x00517b60 (46 byte data) (referenced by 0x00547ffc) 4 = 0x00517b08 (81 byte data) (referenced by 0x00548000) 5 = 0x00517a88 (121 byte data) (referenced by 0x00548004) 6 = 0x005179d8 (169 byte data) (referenced by 0x00548008) 7 = 0x00517d00 (225 byte data) (referenced by 0x0054800c) With these locations, it may be possible to perform some modifications on the game executable to extend the maximum range of a reveal (either by Unit Sight or by Reveal Tile event). We will need: Modify the address of the reference pointers to support the same number of pointers as the desired range. Prepare memory locations for additional data. Have the game assign the reference pointers to the memory locations of additional data. Modify the function loading the file so it loads the required number of bytes to support the desired range. Supply the game with a large enough Circles.bin file to support the desired range. For a range up to 32 cells, 7690 bytes of data is needed. For the full range of 255, that would be 516130 bytes, too costly and impractical for a simple function. This is probably a case of trading space for processor efficiency by loading what is essentially a lookup table for each tile reveal instead of doing time-expensive math. This is a hypothesis, which has to be attempted and tested.

As part of an ongoing effort to collate research into an open-source code, I have created an editor that allows you to edit and preview the campaign map. The link to the project is here: https://github.com/nguoiyoujie/Spice2k (pre-built executables in /build/debug and /build/release) Preview: Discovered descriptions of the campaign.uib file format is here (may be moved in the future ) (Edit:) https://github.com/nguoiyoujie/Spice2k/blob/master/doc/spec/uibCampaign.md

Yeah, I'll try to contact him. There is some stuff I found with regards to where Colours.bin is stored, and which code references them. By changing the location of the data, I was able to preserve more house colors than the original 8 (currently tested until 16 colours, but it may be possible to test up to the practical limit of 256). I'll make another post about it once I know more information about the house alloc. index. In the meantime I'll update my findings for the campaign.uib, and templates.bin. I didn't know about the old wiki. Time for some reading I guess :D

Nice. I have not yet tried the missions yet due to me messing around with other files. I'll definitely try them out someday! :D

On the unit sounds, if you are using TibEd to edit them, there is a bug: The true sounds are: AtreidesReporting1 = Reporting1 AtreidesReporting2 = Reporting2 AtreidesReporting3 = Reporting3 HarkonnenReporting1 = Reporting4 HarkonnenReporting2, (absent in TibEd) HarkonnenReporting3, (absent in TibEd) OrdosReporting1, (absent in TibEd) OrdosReporting2, (absent in TibEd) OrdosReporting3 = Reporting5 Each values takes an integer represent the sound ID. The highlighted region to the right (hex 0x6C to 0x7B) are not seen in TibEd. That could be the reason why you were unable to edit some reporting sounds. At this time, while there is no template editor yet, you can use a hex editor to fix those values: HarkonnenReporting2 location = N * 0x100 + 0x6C, HarkonnenReporting3 location = N * 0x100 + 0x70, OrdosReporting1 location = N * 0x100 + 0x74, OrdosReporting2 location = N * 0x100 + 0x78, where N is the UnitID

I have not yet tried to contact anyone yet, I was spending my time learning how to fiddle with an IDA, and changing the executable currently takes a lower priority than figuring out how to change the various data files (in particular, templates.bin since it looks like the brain of the data). As for modifying how the game loads the .MIS file, I will keep my expectations in reserve until the structure of the .MIS file (in the eyes of the current game) is fully discovered. The bytes for condition and event count are known to us, so that can be used as a trigger point for the game to load extensions if we need them.

Alright, I managed to look into how the game loads the Data.r8 / Data.r16 file, since previous tests determine that playing with unit counts messes with animations, and animations are images, and images come from the data resource files. Here are the results, thus far: * I suspect UnitTypes and BuildingTypes are simply indices, since they don't appear to carry more data than a name reference. I suspect those two to be relevant to how the sidebar icons are arranged. (e.g. why Wall appears before Refinery) I am not very good at reading assembly, so having Ghidra IDA (it's open source) to decompile to a C-like flow helps a lot. This research has also been made much faster by MVI's old repository where the functions for processing images / BMP / TAR had been discovered, making it much easier to analyze the function loading the data resource file. Some major findings: In analyzing the Data.R16 file, I discovered an issue with the existing Resource Editor. The editor consumes null bytes so the user does not see them. On the contrary, the game does read the null byte as an empty entry (i.e. nothing is rendered). This is critical, as the game performs precise counting of the number of image frames an object has and read the same number of images in the data resource file to assign to that object. The empty entries act as 'padding', and are very important if we want not to replace entries, but to add to them and modify their ordering. For example, Templates.bin specifics 34 image frames for each of the 8 directions for Light Infantry, making a total of 272 images. There are 20 empty entries (situated around the death animations), so the existing editor sees only 252 entries. Unit art is different from Unit. TibEd seems to be already aware of this. The sections in the middle are all numbers instructing the game how many images are to be loaded for each unit art, building art, projectile art, animation (including explosions) etc. All these are used when the game loads the data resource file. I attach a set of my findings below, in three files (within one zip): - A dataR16 folder, which contains the extracted images from the Data.R16 resource file. Each entry is named "test_xxxx_yyyyyy", where xxxx is the image entry ID, and yyyyy is the hexadecimal address of its starting location. Empty entries are represented by 1x1 transparent pixel (actually 0x0 to the game). - sym_addenum.txt, which carries my findings for the game loading Data.R16 file, including memory addresses of where each image is sent to. I consider the Data.R16 loading mechanism to be almost fully discovered. - Template_bin_sections.txt, which carriers my findings for the templates.bin file (seen in above image). dataR16.rar I have also added some code that is able to parse the resource file and include the empty entries: https://github.com/nguoiyoujie/Spice2k/commit/1f3f8ace4f88eaa60ff42473b642da2f0ac9c63d . Credits to mvi, funkyfr3sh and co. for the original resource editor which allowed me to speed up other discoveries. This code was used to generate of the dataR16 folder as attached. (I should make some kind of test suite with the v1.06 files so I don't test on Program.Main())

Each mission map file (.MAP) contains two values for each cell on the map. One value is for terrain data. This determines the which terrain cell is loaded on that cell. The other value is for what I call object data (what the editor calls 'Special Index'). This determines what this cell contains (spice, infantry, building, worm). The game actually refers to Tiledata.bin to translate that value into the actual object to load. Example: Map Object Value: 14 Look for the 14th 4-byte value in Tiledata.bin (a.k.a. starting from byte (14 x 4 = 56 (0x38)) The values are: 07 00 00 80 80 = This is a building... 00 = ...belonging to House at slot 0 (the first house)... 00 = ... 07 = ...whose building type is Refinery Game: Ok. I place a Refinery belonging to the first player at this cell. All these are done invisibly by the game, and emulated in the editor. Being capable of working on the modified bin would mean that if a mod changes how each special index maps to an object, the editor remains capable of handling this change. If we manage to figure out Templates.bin enough to modify the number of supported units and structures, this would be very useful as Tiledata would have to be modified to support any addition to the unit roster.

I am looking at one of the big .bin files. This is currently a very preliminary research, as at this stage all I can do is to recreate the past discoveries by TibEd and other people, before I can break new ground. As such, this is a very preliminary research. I hope to share this here so in the future, other people can read and save on the discovery (I can also put my research on GitHub or something, but I have not put my mind into that) Here is what I guess the game executable reads the Templates.bin file and splits it into different areas. These structural divisions is fundamental to how the game interprets the bin file. For instance, the game will reserve a block of memory for Unit data, and a different memory block for Building data. With the help of TibEd and running the game, these are my guesses on what each section belongs to. ------------------------------------------------------ Text copy of above image ------------------------------------------------------ At a glance, the game appears to support up to 60 unit types, 100 building types, 64 weapon types and 64 explosion types. I attempted to change what I suspect to be the Unit and Building Count, and I have some varied responses: Decreasing the values and loading a mission where such a value is needed leads to crash on mission load. Setting Unit Count to 0x00 up to 0x19, and loading A1V1 leads to crash at mission load with error "MyVersionOfUnit didn't find a unit". Setting Unit Count to 0x1A just below the Sandworm ID (25), leads to crash to desktop (no error message) Setting Unit Count to 0x1B just equal to the Sandworm ID (25), and loading A1V1 leads to working game, with graphically maimed animations and offset build icons Haha, Construction Wind Trap Setting Building Count to 0x3B (59), and loading O9V1 leads to crash with error related to the Imperial Palace (ID 59, or the 50thbuilding in the list). Setting Building Count to 0x3C (60), and loading H5V1 leads to crash with error related to the Harkonnen Special Outpost (ID 60, or the 61st building in the list). Setting Building Count to 0x3D (61), and loading O4V1 doesn't lead to crash, but the player loses instantly (since the Ordos Special Outpost (ID 61, or the 62nd building in the list)... does not exist??). This happens on both the -spawn and normal launches of the game. I am not sure why this behavior is different from the Harkonnen version. Changing other values in the surrounding region may lead to lead to very damaging graphical glitches. Clicking on the building queue (to construct a building) may lead to crash due to 'BlitErrors' Hypothesis: Unit Count and Building Count works like what I think they do, but their DATA.r8/.r16 folders may be arranged specifically to the exact number of items. Either this could be controlled by the .bin file, or it is hardcoded and any modder working on adjusting the counts need to also pad their DATA files so that the image sequences are aligned correctly. This is the extent of my current research. More to come.

Hello fellow commanders / modders, I had spent the past few nights looking through some of the past research on the executable and data files, with the intention of uncovering past limits and removing some limitations of the game. My main inspirations are: Data modding (without modifying the executable) Uncovering what each data bit in each of the major .bin file means Uncovering what each data bit in each of the major table file (.uib) means Uncovering how the game registers a unit / building and links resources to it (bin, data.r8/r16, sounds.rs), allowing the possibility of adding new units / buildings. Executable modding (modifying the executable) Removing size restrictions (example: the number of entries in Colours.bin), where possible Merging the changes by other patches (if I ever figure out how the individual patches work, like the build queue patch) Expanding the mission triggers system (Conditions / Events system) My main investigative tool is Ghidra IDA. I use it mainly to read and interpret the Dune2000 executable and find where the data gets put in, and leave a trail of annotations / comments. It is like playing Minesweeper on a grid with almost 1.8 million cells (the size of the Gruntlords Dune2000 executable is about 1.795 million bytes). One of the obstacles I face is that I am late to the party. Thus, I am re-discovering what others have found before e.g. Intelligent Games had two mission event action codes 12 and 13 defined and named (BLOXFILE, ATTRIBFILE), but an internal parser converts them to invalid code 20, and there is no handling of those codes, suggestive of a scrapped mechanic. I discovered this yesterday. Kloflac, FunkyFr3sh and co. discovered this in 2015. So, I have changed my endeavor to collate what other people have researched, so that I can work on most updated information on the game's internals. I found one of the resources to be very valuable in my initial research, as it collated and documented the list of changes made to the game since the last official patch (1.06): https://github.com/mvi/dune2k Unfortunately, it is no longer maintained (https://forum.dune2k.com/topic/26661-dune-2000-106p-game-patching-bug-fixes-new-features/page/19/?tab=comments#comment-391397) and a lot of changes have since been made to the current Gruntlord / CnCNet version that were not present in this record: For example, the patches to fix several mission events (Trigger Actions as known in the RA/C&C world), described from here onwards: https://forum.dune2k.com/topic/26661-dune-2000-106p-game-patching-bug-fixes-new-features/?do=findComment&comment=390766 , are absent in this source. The addition of the PlayMusic (action code 21) is very valuable patch, and it would be much easier to tweak a C-source file that implements the additional function branch that calls the PlayMusic function and re-patch than re-hack the post-patch executable. While I could run through both versions and make comparisons to append to my findings, I feel like a lot of time could be saved if the sources for those changes are available somewhere. In addition, I am quite confident I would trip over many of the same bugs from 2015 till now as I try to rebuild my interpretation of other people's changes to match the current game version. I am thinking of rebuilding the list of changes, and then use the research thus far to suggest new ones. This task is not an urgent task, as I would be spending my time reading all those BIN files first. But if I want to go about making changes to the EXE, without these prior information, it would be quite an inconvenience spending months to re-research what has been researched. Basically, I am hoping that instead of playing a new game of 1.8 million cell Minesweeper, I get to continue some other person's game where some cells have already been uncovered and navigated. I get it that it has been a long time since those research were taken, and the game of research may have been stopped at some parts. I am willing to continue this game. So, here, I ask if there are resources available that lists the source of changes that converted the original Westwood 1.06 patch to the current Gruntlords executable version, and any annotation that came with that research. Hopefully these are public; I am not sure how to go about getting permission to use knowledge that aren't public and put them in my fork of MVI's project.

More information on the fade (value 0, 1). It appears that the Fade to Black and Fade from Black works. The only issue is that the game uses a black rectangle to simulate the fading process. And the size of this rectangle follows the original resolution. This is what is seen on a game with the original dimensions (640 x 400) Looks like hi-res patch has some more work to do. :D

MVI (and some others who I don't know) made a lot of progress deciphering the format of various UIB files, culminating in the release of an editor that works on many uib formats. For the menus.uib, the each menu entry had: a key name (that UIL searches for when attempting to open a new menu), a value (the file that represents the menu to open) and two unknown integer values, named Unknown1 and Unknown2. I'll let Ghidra explain the unknown values for me. (Apparently the game has functions converting other files into UIB files. Probably used for debugging or their development, but very useful for reverse engineering their formats) ---------------------------------------- Unknown 1 (int): Determines how the menu fades in 0 = Fade From Black? (From videos of the game, this appears to be Fade From Black. However, my game does something weird when this is used, drawing a black rectangle at point 0,0 during the 'animation' phase). It could be due to the patched game, a graphics setting or that some legacy Windows broke on newer Windows. See below for a more visual result) 1 = Unused (the game flickers when you use this. I suspect this is for fading out but it doesn't play well as a fade in sequence) 2 = Tween (looks like the proper fade blending the menu and the background behind it) 3 = Skip (no transition. The new menu pops in) Other values (I only tested '4') = The new menu is not drawn, but is functional. See below for a more visual result) ---------------------------------------- Unknown 2 (int): Determines how the menu fades out 0 = Unused (the game flickers when you use this. I suspect this is for fading in but it doesn't play well as a fade out sequence) 1 = Fade To Black? (From videos of the game, this appears to be Fade To Black. However, my game does something weird when this is used, drawing a black rectangle at point 0,0 during the 'animation' phase). It could be due to the patched game, a graphics setting or that some legacy Windows broke on newer Windows. See below for a more graphical result) 2 = Tween (looks like the proper fade blending the menu and the background behind it) 3 = Skip (no transition. The new menu pops out) Other values (I only tested '4') = The background behind the closing menu is not drawn, but is functional. See below for a more visual result) ---------------------------------------- The tests are perform by modifying the entry for DIFFICULTY / skill.uid. This menu is called when you click Start New Game on the main menu. Visual - When using value 0 or 1 (Fade) as fade in / fade out For an example of a working Fade To Black, see 3:20 of https://www.youtube.com/watch?v=-x9MahcVn7k where a Fade To Black was demonstrated from the campaign map. Visual - Value 4 for Fade In Menu did not appear, but is active. Buttons will paint over the screen when you interact with them. Visual - Value 4 for Fade Out Menu did not disappear, but the previous menu (main menu) is active. Buttons from the currently active menu will paint over the screen when you interact with them. With this I think the description of the Menus.uib is complete. I hope this gives modders more control over the UI behavior of their experiments. :) EDIT: Corrected errors - it was Fade (value 0,1) that was giving display glitches, not Tween. Also added more information on the fade behaviour.

Do you have information on how TibEd overwrites the Dune2000 BIN files? Or any documentation about the format of the various BIN files. Technically, I could open up TibEd and play with it myself, but if prior research on the BIN files had been done, this process could be much quicker, and I can use the time to look at the executable and see where the data could be loaded and read.

The campaign map (also known in the game as 'Globe') had always fascinated me. Today I try to decipher what makes it work. When you first start a new campaign, you see the campaign map evolve from a globe of Arrakis (or if you did not have a working cutscene file, just the map). Then the following occur: The game announcer (SFX voice) opens the campaign with three statements. One for Atreides, one for Harkonnen, one for Ordos. The order depends on which house you chose to play as. Let's say you picked Atreides. In fact, we may use this video as reference: https://www.youtube.com/watch?v=-x9MahcVn7k The game announcer opens with the first statement about Atreides. Concurrently, the map animates, and some regions are colored blue, left to right. The game announcer delivers a second statement about the Ordos. Concurrently, the map animates, and some regions are colored green, left to right. The game announcer delivers a second statement about the Harkonnen. Concurrently, the map animates, and some regions are colored red, left to right. Two Atreides icons appear on the map. The game releases control to the player. The player may select the regions where the icons are, or perform other actions (Save, Load, Quit). If the player selects a playable region, the game takes the player to the briefing for that mission. For the most part, these actions are controlled by the campaign.uib file, I have found out roughly how it works, and other interesting tidbits related to the single-player campaign. My findings are summarized in the image below: ------------------------------ Text copy of the image description: ------------------------------ More detailed explanation: The campaign.uib file is divided into 3 Houses, each House with 10 104-byte sections. Each section represents a mission 0 to 9. Mission 0 appears to be a setup performed before animating Mission 1. The campaign.uib file is loaded into the game memory (0x00795708) at startup, like other uib files. If changes are made to the file while the game is in progress, the game has to be restarted for the changes to apply. The executable has hardcoded the following limits: 3 supported Houses, 9 supported missions, each mission having 2 supported versions (V1 and V2), and 27 map regions. Changing those require modifying the executable. The campaign map is split into 27 map regions. The background piece is DUNEMAP2. The graphics for each map piece lies in /data/UI_GFX/regions. The position and polygon hitbox are hardcoded in the game. The polygon points appear to be a POINT (int x, int y) array in executable addresses 0x004be3fc to 0x004beb84. Reference Flow: Atreides Mission 4 - https://www.youtube.com/watch?v=_3hZzNg9TrA When the player enters the campaign map, the game first notes which mission the player is going to play. (If the player just completed Mission 3, then the next mission is Mission 4) The game notes which House the player is playing as. (E.g. this is an Atreides campaign) The game will then load up the regions for all previous missions for the player's house. Specifically, it begins from a blank map, and starts awarding regions to each houses for each mission up to the previous mission map (right before the previous mission): Atreides Setup (or 'Mission 0'): Atreides is awarded regions 2, 3, 4. Harkonnen is awarded regions 12, 18, 22. Ordos is awarded regions 21, 25, 27. Atreides after Mission 1: Mission reward: regions 7, 8 to player House (Atreides). Atreides is awarded region 1. Harkonnen is awarded regions 13, 16, 19. Ordos is awarded regions 15, 17, 20. Subtotal: A = 1,2,3,4,7,8. H = 12,13,16,18,19,22. O = 15,17,20,21,25,27. Atreides after Mission 2: Mission reward: regions 5, 6 to player House (Atreides). Atreides is awarded nothing. Harkonnen is awarded regions 9, 26. Ordos is awarded regions 24, 11. Subtotal: A = 1,2,3,4,5,6,7,8. H = 9,12,13,16,18,19,22,26. O = 11,15,17,20,21,24,25,27. Player's previous mission was mission 3. Stop here. The game renders this map. The game begins the first SFX / Animation cycle: The first SFX for Atreides Mission 4 is C_A4a. Announcer plays the corresponding speech (AI_MAP4A.AUD) Concurrently, the first house to be animated is House ID 0 - Atreides. Since House Atreidies is also the player's house, the Mission 3 reward (regions 10, 11) and Atreides' own advancement (nothing) shall be given to House Atreides. The map animates the colors of regions 10 (unoccupied) and 11 (Ordos) changing to the Atreides blue. (while the speech is ongoing) First SFX / animation cycle end. The game begins the second SFX / Animation cycle: The second SFX for Atreides Mission 4 is NONE. Nothing is played The second house to be animated is House ID 1 - Harkonnen. Region 14 shall be given to House Harkonnen. The map animates the colors of region 14 (unoccupied) changing to the Harkonnen red. Second SFX / animation cycle end. The game begins the third SFX / Animation cycle: The third SFX for Atreides Mission 4 is NONE. Nothing is played The third house to be animated is House ID 2 - Ordos. Region 23 shall be given to House Ordos. The map animates the colors of region 23 (unoccupied) changing to the Ordos green. Third SFX / animation cycle end. The game looks at the mission versions for Atreides Mission 4: Version 1: Region 9, Mission: A4V1, Atreides Icon (AT_POINT) rendered at point 193, 75 Version 2: Region 0... Skip. The game renders the animated Atreides icon, and activates the hardcoded polygon for Region 9 and links it to mission A4V1. The game releases control to the player. If the player hovers over Region 9, he'll get an attack cursor. If the player clicks Region 9, he will be taken to the briefing for A4V1. The player starts playing the mission The initial music is indicated to be FREMEN. This will be first music that is played on starting the mission. The mission score multiplier is 2.5 (byteform 00 00 20 40). If he wins the mission, the score screen will divide 2.5 x 200 = 500 points between the player and the enemy AI. If the player wins the mission, the next campaign map will see Region 9 animated to turn to Atreides control. The values covered in green are values taken from campaign.uib. How moddable is this file? Alas, not very... Although you can change the values in campaign,uib as you like, the game logic imposes some rather arbitrary restrictions: Hardcodes: 3 Houses, 9 Missions, 2 Versions of one mission, 27 map regions Hardcodes: The region polygons for mouse selection. You can draw new regions however you want, the clickable region is still the same. The house icon is only for show. Region changes are cumulative. Campaign maps further down the campaign depend on the maps before it. You cannot return a region to a neutral color. Between any two missions, a non-player house can be awarded a maximum of 3 regions. The player house has the same limit, except that it is also awarded the player's targets from the prior mission, potentially bringing up the number to 5 (3 + v1 and v2 of previous mission). You cannot chose not to award the player's targets to the player's house. For example, A1V1 is Region 7, A1V2 is Region 10. Both regions will be Atreides after mission 1; you cannot make the house take only one region. However, I believe another house could take Region 7 from House Atreides during their animation phase. 1 Mission, 1 Campaign map. Doesn't look like it supports diverging paths and story branches. Only a linear march to victory. However, you can... Enable missions and define them on the campaign map, which were disabled by the original devs (A4V2, A5V2, A7V2...), provided you have made the missions for them. Change how the regions move around. With creativity you could make very interesting map progress with the 27 regions given to you. If you have new icons, this file can help you adjust their placement on the map. If you have new regions, you might have to look at the executable instead. This is quite the lengthy explanation, but I hope this is a start to understanding one of the more elusive UIBs we have in Dune 2000. EDIT: Fix typos. EDIT2: It appears I was wrong. Byte 56 / 0x38 (int) is indeed used during the second animation cycle, not the third. Updated the image and text to match.

To SCX: It is good! Terrain wise, flawless so far (haven't explored all the map yet). Dirt clump size, good to build and maintain. Your terrain allows the enemies to attack from two ways, and the attack frequency is incredible (though that's thanks to the original .mis file). The pre-built bases look aesthetically good and compact, while still allowing free movement of troops. Spice is abundant, and I will see if spice blooms are too, if I can last long enough. The difficulty is good; it is indeed challenging since you will share a large part of your spice field with the Atredies, and any Merc offences will be repelled by the Harkonnen outpost. This means this mission will require heavy defending. And the heavy losses on the Mercs sides would mean immediate action from you to balance the score (and prevent the Mercs to turn neutral). Well, at least I could go, "I didn't know the original AI can send 6 atredies sonic tanks at once." Well, that's your map. Here's mine in return, hot from complete testing. A9V2 will be hard, but at least the originator here had completed it in, say, 5 hours? Play to enjoy! Play his mission. This is the mission. Loval Horae Midas A9V2.zip

To answer our fellow DUNErs: change 31 to 35 (that is four events) - 35 (dec:53) will now enable declaration of all events from 00 (the first) to 34 (the 52nd), hence a total of 53 (decimal). You may change the number of conditions by the same way, but to the 25 value. I am not sure about that; this is the scope of AI. As far as I know, events do not support this event or ultilize 'attack' as an action. I hope those currently working on it may also shed some light on it. What you said is true; the AI only builds enough to satisfy their needs, and checks the current stock against their needs by sheer counting on the map. The AI behaviour in my edited O9V1 suggests this. In Tiberian Dawn and Red Alert, unlike later games, they do not use 'pools' of units (reserves in the base - an effective base defense). My guess from my observation, is that Dune 2000 acts likewise (their base defense just employs every unit currently not on a mission - attacking or harvesting or guarding when pre-placed) - no 'pool' of units, hence the vulnerability of AI bases, unless there are tons of AI teams executed. This will have to be verified. I am currently enlisted in the Army (not the Sardukar or Fremen or whatever :P), so my activity will be at low (but above zero, thankfully). I am compling my 'research' on the Mission File and post a version sometime... maybe next month? In the meantime, Why the Fremen player always acts, looks, and builds like Emperor house in O9V1? The bytes 0x50 to 0x58 are declarations on the TYPE of house the relevant player is in (player 0 to player 7, zero-based). The values 00 to 07 for the parameters are identical to convention we are using. Only that putting a value of 02 for player 6 will give the ordinarily merc's (06) house all the properties of the Ordos (02) house, including colour, and the Ordos heavy factory, but abandon its unique factory. Setting them as 00 01 02 03 04 05 06 07 will give you your standard campagain houses, But you may use 00 01 01 01 01 01 03 07, if you want the impression of a Harkonnen super-base with an Emperor camp (you, of course, will be the Atredies). That's all I have for now. Loval Midas Play Dune 2000. That is the order.

To gruntlord: Thanks for that information. I haven't searched far enough to consider this. This, I believe, is coded either in AI or events. An earlier experiment involved me copying H4V1 fremen AI, to O9V1 fremen AI - Fremen units still belongs to the Emperor. So I think I could be stored in the events. I am now a working serviceman, so I can't test anything. Too little time. To sandworm: Search for the conditions that the event refers to. One of them should contain the strings: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 2f 00 03 represents the Emperor's house, 2f represents a Harkonnen-based starport. Now, change the last four bytes to 02 00 30 00 (30=Ordos-based starport) This should answer your query. Note however, a condition can linked to many events. So, do check that other events do not use that particular trigger. If so, employ a new condition (increase declaration of events by 1, change relevant condition called in the event section to the number of events minus one, put your desired code) Loval Midas