Jump to content

Vanshilar

Fremen
  • Posts

    6
  • Joined

  • Last visited

Reputation

0 Neutral
  1. Here's some oddities about taking over enemy bases. Maybe they were known already and I simply hadn't done it enough (in the past I usually destroyed them instead of taking them over): 1. Turrets don't fire on enemy turrets or buildings, only units (including air units). Their bullets go through your own structures, but not the enemy's (and the same thing with theirs). 2. I unwittingly placed a turret on the same square where a computer turret used to be. The turret ended up firing on my own units, even though I could repair it and stuff. 3. I placed a heavy factory directly on where the computer used to have a repair center. While the computer still had his construction yard, it briefly became his repair center, but reverted to my heavy factory. I subsequently took over his construction yard, then later on my heavy factory was destroyed. His repair center reappeared on the same spot shortly thereafter and stayed around until I took it over, even though he didn't have a construction yard at this point. 4. When I took over the computer's construction yard, it was in the process of building a heavy factory. I repaired it and let the heavy factory finish, and then placed it (on what used to be walls and an outpost). The heavy factory I placed ended up being the computer's, and in fact the computer made a combat tank with it. I subsequently took it over and was able to make launchers with it (which I'm not naturally able to do, since I was Ordos), so the heavy factory was the computer's race (Harkonnen) and not mine. So other than #1, it seems like the code for taking over enemy buildings and building in the enemy's base isn't exactly perfect, and has some idiosyncracies.
  2. Hmm so if I understand it correctly, "& FF" really doesn't do anything (it'll just depend on whatever the other argument is -- although having that code there might be useful if the coder wants to change that value), but "& 1" means that it'll bitwise compare with 0000 0001b? In this case then, since it's paired with a random between 0 and 255, it means that 50% of the time fireDelay will have an extra 1 added to it? Although in testing the variation seems to be larger than this (i.e. a single game frame), but I'll have to go back through the data. Neato. Good to know.
  3. Okay so digging around the OpenDune code quickly, in script\unit.c, function uint16 Script_Unit_Fire(ScriptEngine *script), it seems like the relevant part is this line: u->fireDelay = Tools_AdjustToGameSpeed(ui->fireDelay * 2, 1, 255, true) & 0xFF;"fireDelay" is apparently (I'm assuming) the rate of fire variable in Nyerguds' editor. Additionally, if it's the 2nd projectile: u->fireDelay = Tools_AdjustToGameSpeed(5, 1, 10, true) & 0xFF;So yeah it gets adjusted by the game speed. Additionally, at the end: u->fireDelay += Tools_Random_256() & 1;This appears to be what randomizes the actual cooldown. Anyway I guess I'll digest this for a bit, since I'm not that familiar with coding. From uint16 Tools_AdjustToGameSpeed(uint16 normal, uint16 minimum, uint16 maximum, bool inverseSpeed) in tools.c, it seems like the modification based on game speed is: slowest: twice of normal slow: 1.5x of normal normal: normal fast: 3/4 of normal fastest: half of normal The Tools_Random_256() returns a random value between 0 and 255 -- but to me it seems like this would be too big, seeing as how troopers and trikes/quads have a cooldown of 100, so this randomization would overwhelm it. Also, this is after when the cooldown for the 2nd projectile is set, which would make it really long. So there may be something else going on here (for example, I don't understand the "& 0xFF" and "& 1" parts).
  4. Hmm I haven't bothered looking into the code of the various open source versions. Are they based on the game executable itself (for example, through people essentially transcribing what the original game executable did) or are they based on independent code that's made to resemble the original game? If it's former then looking into the code would be useful, but if it's the latter then it just depends on how faithfully people tried to understand and emulate the original game's mechanics so it may not be as reliable. Hmm the delay between two shots always being 5 -- is this regardless of game speed, and/or regardless of the subsequent RoF*2 thing? Is it subject to a randomization amount? It seems like the regular cooldowns are randomized somewhat; two units firing in unison won't be firing in unison for very long, although it may have other causes (such as the game frame thing where lots of units tends to slow things down). I think testing on each difficulty is relevant because people will play at different speeds, and it may be useful to consider DPS outputs based on the speed that the game is played at. For example, with the cap at 255, it means that the launcher at slower speeds is relatively stronger compared with other units than at faster speeds. It's basically to see how the game really works -- although, yeah, if I were to try to match up with the values in the game files, then maybe testing should be done on normal. If the game works with RoF*2, what are the cooldowns for the speeds other than slowest (*2)? It seems like fastest is roughly *.67 or so.
  5. Just an update on this. I did some testing on fastest and the unit rate of fire seems to line up with the game's stats a lot better. The data is basically: Unit RoF fastest slowestSoldier 45 8.59 24.53Trooper (can) 50 9.02 26.59Trooper (roc) 50 9.03 26.14Troopers (can) 50 8.84 26.61Troopers (roc) 50 8.8 -----Trike 50 8.83 26.63Quad 50 8.78 25.97Tank 80 13.54 33.5Launcher 120 20.38 34.57Siege Tank 90 15.45 33.31Sonic Tank 80 14.84 33.31Devastator 100 17.04 33.43"RoF" is rate of fire from the code (given by Nyerguds' editor). "fastest" is how many seconds between shots on the fastest game speed. "slowest" is the same for slowest game speed. "(can)" refers to the bullet projectile, i.e. close range, while "roc" refers to the rocket projectile i.e. long range. The testing conditions were that all were in the red in HP, except for the troopers, which were at half. This is so that all were firing only 1 projectile, not 2, which slightly increases these numbers. Basically it's as if there were about 5.66 game frames per second on fastest, but on slowest, it doesn't really follow the given numbers as much. I only measured two shots for each so there's quite a bit of measurement error (the cooldown timer is somewhat randomized), but as I measure more shots (I recorded about 10 minutes' worth of them firing) the numbers will hopefully be more in line with the stated numbers. However, the rate of fire on slowest doesn't really match up well to the stated numbers. By the way, troopers do 4 damage using their rocket (2 if halved), while they do 5 damage with their cannon/bullet (2 if halved), so you should move them if you want them to do more damage.
  6. Have people looked into how Dune 2 decides how long to delay before a unit fires a projectile? I'm aware that the game editor (specifically, Nyerguds' editor) has a game field "Weapon rate of fire". However, there are two problems with this: 1. The times given by this data field doesn't seem to line up with in-game testing. For example, it says that tanks and sonic tanks have a rate of fire of 80, siege tank has 90, devastator has 100, and launcher has 120, but testing shows that their cooldowns are all within 10% of each other. For troopers, trikes, and quads, it states 50, but their cooldown is roughly 80% of the heavy vehicles. 2. Some units fire a second projectile if they're above 50% health. That slightly increases the total cooldown per cycle of 2 shots, by roughly 5% or so. Additionally, troopers fire different projectiles based on range; I'm not sure if there's info on the two different projectiles. Admittedly I tested this on the "slowest" speed setting, so I don't know if I'll see a bigger effect at a faster speed. However, the difference seems a bit much; there's a difference of 30 (50 vs 80) between the troopers/trikes/quads and the tank, but 40 (80 vs 120) between the tank and the launcher, yet the tank's firing rate is much closer to the launcher than the former group. Anyway, I sort of figured somebody else has probably looked into this before, especially if the game has been modified for player vs player so knowing each unit's damage-per-second (DPS) is important. But I haven't found data on this. I was going to do some field tests (in fact, already have a saved game set up for this), but I don't want to duplicate effort that's already been done. As a side note, I also don't know if anyone looked further into how projectiles will sometimes do half damage based on the location of the shooter and the target, and the game speed. I previously posted about it here (I'm Javichal, just I've long since lost the password and email) but didn't really follow up with further testing: http://forum.dune2k.com/topic/19996-info-dune-2-half-damage-bugtip-plus-question-on-fremensarduakar/ I still think it has something to do with the projectile exploding not directly on the unit's location, thus the unit taking half damage -- but it can be important from a micromanaging standpoint, seeing as how you can reduce the damage taken by 50% or more. I tested using Dune 2 though so this may no longer be an issue in the Dune 2 mods.
×
×
  • Create New...