Dmitri Fatkin

Re-uploaded yet-again repaired KMCSDUNE.ZIP file. Thanks for the explanation on how it was done, Blue. KMCSDUNE.ZIP

Hello, it can be downloaded from here: https://github.com/OpenRakis/OpenRakis/releases.

Hello. When you're making extended save file modifications, you'll actually have to maintain the consistency between controlling value containing the amount of bytes by which it's got expanded due to game progress/data uncompression and its actual size affected by manual edits. The problem is due to the above editors not updating that value, unfortunately. It's specified in the 5th & 6th bytes of saved game file, preceded by either 0xF702 or 0xF701 bytes sequence. The default value of fifth byte is 0x1B in version 3.7 and 0x59 in version 2.1, with saved game file sizes being 9,563 bytes for DUNE21S0.SAV and 9,757 bytes for DUNE37S0.SAV (with rare exceptions). The easy solution is to not be adding weapon items the initial amount of which equals 0, as every time you do that the file size will be affected by the utilized RLE decompression. That information is stored after the ending of Troops data, at offset 0x2377 in version 2.1 and offset 0x243B in version 3.7. The detailed description is as follows: The first byte is sprite identificator of the character. The third byte is location of the room within the place. The fourth byte is type of the place the character stays in (that byte is specified in field C of sietch data). The 6th byte is used to determine whether a character is active (it's hidden when it's set to FF). Also serves as a pointer to the exact place the character is at. The 7th byte refers to the NPC the player will have a dialogue with upon clicking the sprite, it's also linked with the last byte (either 92 or 93). Duke Leto Atreides: (00)(00)0A208001F292 Jessica Atreides: (00)0204208001F701F792 Thufir Hawat: 0102082080FFFC92 Duncan Idaho: 0202042080FF0193 Gurney Halleck: 03020200800D0693 Gurney Halleck in version 2.1: 03020200800DF09D Stilgar: 04000204802E0B93 Stilgar in version 2.1: 04000204802EF59D Liet Kynes: 05000210803F1093 Chani: 06000305801B1593 Harah: 0702030780111A93 Baron Harkonnen: 0800023080021F93 Feyd-Rautha Harkonnen: 0980023080022493 Emperor Shaddam IV: 0A80023080022993 Harkonnen Captains: 0B80023080002E93 Smugglers: 0C00023080006F93 The Fremen: 0D00023080007393 The Fremen: 0E00020280007E93 As for the error, it most-likely occurred because you've changed the look certain location is decorated without updating the associated data for particular NPC. Their residence place types (the 4th byte in the above description) are actually required to be updated in order to see the NPC in new interior. You'll actually be always recruiting a group the ID of which stood first in the list of location's housed troops, with Population, Spice Mining and Military skills proficiency randomized. Ecology parameter, however, will be inherited from the original Harkonnen troop. Another interesting fact: the Harkonnen troops always travel in about 8 seconds time span from one location to another, regardless of whether they have an Orni. hugslab: Thanks, your notes were interesting to get acquainted with, along with looking at comprehensive reverse-engineering job done.

In memory dump of CD version of the game, all of the following options are still being referred to, right after character names displayed upon completion of the game (preceded by "In order of appearance"): SUPER FREMEN HERE, PHASE LOC KNOWN, ALL SIETCHS KNOWN, RALLY ALL FREMEN/SIETCH, ALL LOC PROSPECTED, MUAD'DIB + 10, SHOW COORDS/SMALL MAP, TIME VERY FAST, TIME NORMAL, VEGET EVERYWHERE, SHOW TRAVEL ANGLES, SHOW VARIABLE, BACK TO SCR, ALL TEXTS, SHOW TIME AND SPEED, BUF TO SCR, ALL LOC KNOWN, NO "TOO FAR...", GOTO PHASE 80, INCPHASE, PHASE 123, GO->GAME END, HARKO ATTACK, NOT KILLED, 9 PERSOS HERE, ALL PERSOS. Thus, I assume that development & testing menu remains accessible as earlier and most-likely activated by pressing certain combination of keys while staying on Game credits page, which happens to be the last one in player's plot development handbook. However, in order to discover that combination, an additional inquiry into the program's debugging output will have to be carried out.

Good day, everyone. At the closing week concluding the last year, I began working on design of a project which is currently inwardly known as Dune: A Harder Path, and represents itself about 3 times harder version of the original Cryo Interactive's campaign, with redesigned armies, appearances of their leaders, resources, locations and many other things which resulted in about 24 kilobytes changelog and 2 starting saved game files compatible with both 2.1 and 3.7 versions. However, along that 4 weeks road, I've started experiencing certain difficulties in terms of what I felt could have been improved by a change, and yet, discovering how exactly such modification should be done would have easily resulted in multiple days of searching for the exact data offsets, thus drawing me away from the outlined development plan, the main philosophy of which consists of having a stable, playable and well-balanced Alpha version which contains thoroughly-maintained changelog and lacks merely sufficiently-summarized readme files. Below I'm submitting the inquiries in regards to particular areas of advanced editing of saved game files, hoping that some of you possess more information on the topics than I am, thus being able to offer own help in order to slightly speed-up the extensive campaign-making process. I'll be expanding that list of questions on occasion when further-ones arise. 1) How specifically and to what extent the F7 repeat byte compacts game data? Is it possible to extend/alter its utilization to the degree where putting additional data within certain offset frames will not cause collision of data retrieval from the loaded save file by the game, thus allowing to station more data such as identities of troops past 67? 2) Based off the first question, do you think it's technically-possible to extend the number of IDs past what the game expects it to be & loads at day 1, apart troops reallocation? (That's what I've done as of now). Are troop IDs past 67 inherently limited by how the program recognizes them and are there any workarounds for making such a troop be movable from sietch to a sietch & respond to clicking queries properly? 3) Since there are 4 principal ways of launching the conquest against Harkonnen fortresses in the game (through Bledan, Tsympo, Haga, or directly Arrakeen area), and one of them consists of assembling and training the forces below Arrakeen region, slightly down from Tuono-Tabr, I'm interested in how exactly the swapping of Smuggler NPCs between Arrakeen-Pyons and Tuono-Pyons can be achieved, resulting the one at the latter location to never haggle over the price, or perhaps, there's a way to set that up separately for the existing Tuono-Pyons NPC, without the necessity to switch the traders between locations? The data associated with the Smugglers in the place from where character allocation & dialogues display information is taken doesn't seem to have anything related to every Smuggler in particular, providing a generic specification of "0C00023080006F93". 4) Is there a chance someone could elaborate on the detailed description of character data which follows the definition of Troops, the one Hugslab has already briefly touched upon in his reply there? Would be nice to know which bytes control a character's willingness to follow the player and at which offsets are the ones responsible for designation of accompanying NPCs. So far, my own brief description of corresponding data consists of this: The first byte is sprite identificator of the character. The third byte is location of the room within the place. The fourth byte is type of the place the character stays in (that byte is specified in field C of sietch data). The 6th byte is used to determine whether a character is active (it's hidden when it's set to FF). Also serves as a pointer to the exact place the character is at. The 7th byte refers to the NPC the player will have a dialogue with upon clicking the sprite, it's also linked with the last byte (either 92 or 93). 5) As we know, somewhere there's a byte which determines Game Stage (or, how Rémi Herbulot called it - Phase) variable, directly influencing player's discovering capabilities or the course of events that are about to happen after it has reached certain value. Where exactly is that byte defined? And, no-less interestingly, is Harkonnens' intent to attack is directly linked with it, or it's treated as a separate variable which gets turned on upon reaching of military Game Stage? I'm asking since internal development console seems to allow to activate the option named "HARKO ATTACK". 6) Finally, of a much lower priority, and yet, no-less interest of being aware about for an extra occasion lies the question regarding specification of offsets and the description of bytes responsible for depiction of Controlled Areas on the strategical planetary map, provided through "See Results". I'll be surprised if someone extensively researched that, however, nothing prevents us from thinking & investigating the subject a bit further, right? Thanks for answering any of this, and, if some of you will be willing to assist or exchange ideas further, I can be reached either as cyber_smoke in Skype or Smoke Nightvogue#1044 on Discord. Alternatively, you can simply dispatch a private message here to discuss anything related to the topic or the world of Dune novels in general.

Do we have someone here who's aware of what bytes & at which offsets are responsible for a character's willingness to follow the player? Is there a chance you could provide the exact version 3.7 offset which is responsible for the definition of Game Stage variable, along with initial associated data contents by the time when the game starts? Thank you.