dynasty

Thanks for adding the page on Dune Dynasty! Much appreciated.

You can already play your own missions in Dune Dynasty. Just make a campaign folder with your scenarios in it, they don't needto be PAK-ed. It needs a META.INI for the campaign name, but I thinkit'll just take resources from the base campaign if it's missing anything.

The delay between two shots is always 5. Testing should be done on normal because on any other game speed thegame will adjust the numbers, which is prone to integer arithmetic,overflows, etc. There's even an overflow for deviators on normalspeed. The game works with RoF*2, and on the slowest game speed it furtherincreases the delay by *2. However, the final value is capped at 255,so all RoFs above 64 look the same on slowest. No.

Hi fire_qc, Did you install the development packages for FluidSynth and MAD?

Thanks! The 0x3C is the ringing bell synth sound which Dune II used to play insome cases (e.g. no sound blaster or something of higher priority playing). I assume that's the "weird" sound you're referring to. I seem to have both synth and digitised samples enabled by default. I think I meant to change it play one or the other at random. Anyway, just change the (rather clumsy looking) "sounds are both"option to "digital".

I seriously doubt anything changed in the Android port from OpenDUNE. Just going by OpenDUNE in the following. It looks like allied unit losses added to your score, rather than subtracted. Oops! Not sure if OpenDUNE bug or Dune II bug at this stage. That's right. Carryalls and ornithopters lost/killed don't count towards score either. Yes, there is. The bonus is: g_campaignID * 45 - minutes played.

Might as well complete the collection. Turbulence from his youtube page.

No, that's not right. To skip launcher tech it should be si->upgradeCampaign[2] > g_camaignID + 1g_campaignID is the mission number/tech level, i.e. 0..8.g_scenarioID is the file name number to load, i.e. 1..22. Because Atreides can upgrade any heavy factory they own twice in level 5, andan heavy factory created by Ordos can build siege tanks after 2 upgrades. In Structure_GetBuildable: if (unitType == UNIT_SIEGE_TANK && s->creatorHouseID == HOUSE_ORDOS) upgradeLevelRequired--; When you capture the factory, the Ordos heavy factory has onlybeen upgraded once (tested in OpenDUNE). Otherwise the AI would be able to build siege tanks throughout the level. There's a difference between a structure's creatorHouseID and houseID,houseID is the current owner. This line bumps up the structure's upgrade level when it is currently owned by Ordos so that (1) the Ordos player doesn't get useless a third upgrade, and (2) when someone captures a twice upgraded Ordos factory, they too can build siege tanks.

The code is mainly written to skip the launcher tech, rather than to delay Ordos siege tank tech. You could argue that they intended on both effects in one step though. In Structure_IsUpgradable: if (s->o.houseID == HOUSE_ORDOS && s->o.type == STRUCTURE_HEAVY_VEHICLE && s->upgradeLevel == 1 && si->upgradeCampaign[2] > g_campaignID) return false;The g_campaignID test here is a bit weird compared to code just below: if (si->upgradeCampaign[s->upgradeLevel] != 0 && si->upgradeCampaign[s->upgradeLevel] <= g_campaignID + 1) { ... return true; // if structure can be upgraded. }

Thanks! I didn't intentionally change it. I must have made a mistake when I generalised the tech tree for Dune 2 eXtended. No idea. Although I thought v1.07 was meant to have fixed this. What MrFlibble said about ornithopters in the scenarios is right. Dune Dynasty allows for some minor typos in the original campaign's scenario files, because people just want to jump into the game after unpacking the data files, rather than hunting for MrFlibble's fixed scenario pack. Other examples are that some devastator reinforcements were missing in v1.07 ("devistator"), and that the wheeled and tracked attack teams didn't get used.

Yes, the server can cheat, but I don't think it's really a big deal. I'd be happy to just have something really solid. For someone really worried about such things, you could set up adedicated server using a trusted binary and all the players would bededicated clients.

I don't think you can actually divide by the hitpoints, which is why they go through the whole * 256 / hitpoints, * cost / 256 thing. If you don't care about keeping the repair cost of the other structures the same, then inverting the order of emu_Math_ValueToPercent and emu_Math_PercentToValue seems like the easiest thing to do.

Cool, thanks! I don't like this formula much. In v1.07, the repair costs per tick for each structure work out to be: 0, if palace5, if heavy factory or repair facility1, if barracks or turret2, everything elseUsing the OpenDUNE formula, the repair costs change like this: +1, for palace+2, for repair factory+1, for heavy factory, windtrap, and barracks-1, for refinery and outpostThe heavy factory and repair facility changes seem quite significant since the AI likes to target them.You might as well just do: if (heavy factory || repair facility) cost = 5;else if (turret || barracks) cost = 1else cost = 2;Hopefully that fits.

The v1.07 repair cost formula (cost per tick, which is up to 5hp) is: repairCost = ((2 * 256 / si->o.hitpoints) * si->o.buildCredits + 128) / 256; Whereas the v1.0 repair formula appears to be: repairCost = ((10 * 256 / si->o.hitpoints) * si->o.buildCredits + 128) / 256; "Appears to be" because I didn't locate it in the binary(I haven't tried, but I'd love to have this verified). The divisions here round down, so the repair cost for structures withgreater than 512 hitpoints becomes free. The "+ 128" bit is just forrounding up. The OpenDUNE code is in the commit linked below (search for 0x2000,emu_Math_ValueToPercent, emu_Math_PercentToValue). You probably couldjust invert the order of emu_Math_ValueToPercent andemu_Math_PercentToValue to get something decent, but the repair costfor the other structures might change do to rounding. https://github.com/OpenDUNE/OpenDUNE/commit/eaeea887a50c4567dfdc413263b185d88a685350

One of the players will be both client and server. That machine will handle basically all of the game logic. The other clients are pretty dumb, mostly just handling UI stuff. It's more robust this way, and easier too.