Nyerguds Posted August 21, 2009 Author Share Posted August 21, 2009 (edited) Right, I've implemented the Houses in the editor. Got some bizarre bugs though... mostly because I never designed the main types menu to be larger than 2 items, and because so far I never had items and options lists that didn't completely fill the list. All I need to do now is add data types for missing stuff like house letters, music, the palace specials, etc. As always though, I'm doing this in my breaks in between my studying for my 2nd try exams, so I have no clue when I'll actually get it done. Oh, MrFlibble, I've used this list, but there's still some things quite unclear... do you have any idea how the color selection works? [edit] nevermind. It's the palette index of the radar colour, I see. [/edit] http://nyerguds.arsaneus-design.com/dune/dune2edit/d2editor_v1.12.0.zip Edited August 9, 2023 by Nyerguds Quote Link to comment Share on other sites More sharing options...
MrFlibble Posted August 22, 2009 Share Posted August 22, 2009 Nice :) The color does not affect actual unit/building colors on the field though, only the colors on the radar minimap.Would be nice to find the code defining remaps and fix that annoying IX remap bug after all.EDIT: Unkown 006 (bit 5) is the unit's ability to target air units (Troopers and Launchers have this option enabled, but only in v1.07). Note that human-controlled Troopers and Launchers (in Guard mode) seem to ignore enemy aircraft however, but CPU-controlled ones (at least when in Area Guard mode) will actively attack hostile aircraft.Also, as I expected, setting Decay to -1 disables building decay for that House. Damaged buildings don't get regenerate their health, and structures placed on incomplete concrete foundations or on bare rock still get damaged. Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 22, 2009 Author Share Posted August 22, 2009 Nice :) The color does not affect actual unit/building colors on the field though, only the colors on the radar minimap.Yeah, I already adapted the colour thing in my code. It now says "Radar Color Index". This version was just a rough implementation of the list you had in that other thread.Would be nice to find the code defining remaps and fix that annoying IX remap bug after all.yeah...EDIT: Unknown 006 (bit 5) is the unit's ability to target air units (Troopers and Launchers have this option enabled, but only in v1.07). Note that human-controlled Troopers and Launchers (in Guard mode) seem to ignore enemy aircraft however, but CPU-controlled ones (at least when in Area Guard mode) will actively attack hostile aircraft.Added to my source code as well now. Will be in the next version ;)Also, as I expected, setting Decay to -1 disables building decay for that House. Damaged buildings don't get regenerate their health, and structures placed on incomplete concrete foundations or on bare rock still get damaged.Hmm... any idea what difference the other values make? The houses use values 0, 1 and 2. Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 22, 2009 Author Share Posted August 22, 2009 Now I have the houses as list in the editor, I removed the hardcoded houses strings from the program (those used for the ownership value). It now reads those strings straight from the exe, just like it does with units for the "Weapon type" and "Construction option" :) Quote Link to comment Share on other sites More sharing options...
segra Posted August 22, 2009 Share Posted August 22, 2009 Nice Nyer :)heres another bit for you,Unknown 006 Bit2 is something to do with a sound thats played when a unit is attacked but still alive,Ive labelled it as "No Attacked Sound" because it skips this soundplay section but the truth is i havnt actually tested it :)Reasoning is this,seg031:0C6D         notSaboteur:                        ; CODE XREF: objectTakeDamage+E7jseg031:0C6D C4 5E FC             les  bx, [bp+unitDataPtr]seg031:0C70 26 F7 47 0C 00 02        test  es:[bx+_unitData.optsWocaTuro], _UnitOptsWocaTuro_NoAttackedSoundseg031:0C76 75 3C              jnz  short action0Aseg031:0C78 83 7E FA 00           cmp  [bp+Alive], 0seg031:0C7C 74 36              jz   short action0A...seg031:0CAD 50                push  axseg031:0CAE 9A 2A 00 86 42          call  j_soundTableLoadit plays using a different sound table after mission 3... table 0xE + HouseID.. before and in 3 it only uses table 0xD Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 22, 2009 Author Share Posted August 22, 2009 um, unless you use different numbers than my editor, this option seems to be activated on all WEAPONS.[edit]Yeah, UnitOptsWocaTuro is what is currently unknown 005 in my editor. The Unknown numbers don't start from 0 since they're supposed to be for the users :P[edit]Maybe this option was meant to suppress "unit under attack" messages for a certain unit? Though Dune II doesn't have such a message...Are there more checks that make it jump to that action0A? (which I presume is after that sound function call?) Quote Link to comment Share on other sites More sharing options...
segra Posted August 22, 2009 Share Posted August 22, 2009 Yeah thats ok Nyerguds, the Unknown 5 field (WOCATURO) is actually a word, thus the enum appears as (we already spoke about this before)00000001 ; enum _UnitOptsWocaTuro (bitfield)00000001 _UnitOptsWocaTuro_AirUnitShadow  = 100000002 _UnitOptsWocaTuro_2  = 200000004 _UnitOptsWocaTuro_4  = 400000008 _UnitOptsWocaTuro_8  = 800000010 _UnitOptsWocaTuro_10  = 10h00000020 _UnitOptsWocaTuro_WormCamo  = 20h00000040 _UnitOptsWocaTuro_2ndAnim?  = 40h00000080 _UnitOptsWocaTuro_80  = 80h00000100 _UnitOptsWocaTuro_CarryAllPickupRepairs  = 100h00000200 _UnitOptsWocaTuro_NoAttackedSound  = 200h00000800 _UnitOptsWocaTuro_800  = 800h00001000 _UnitOptsWocaTuro_1000  = 1000h00002000 _UnitOptsWocaTuro_TargetAirUnit  = 2000h00004000 _UnitOptsWocaTuro_4000  = 4000h00008000 _UnitOptsWocaTuro_  = 8000hwith the struct as,00000000 _unitData    struc ; (sizeof=0x5A)00000000 stringID     dw ?00000002 Name       dd ?                     ; offset (00043420)00000006 stringLongID   dw ?00000008 Picture     dd ?                     ; offset (00043420)0000000C optsWocaTuro   dw ?0000000E field_E     dw ?00000010 HitPoints    dw ?00000012 Sight      dw ?yeah action0A is after the sound call, and the only other place to jump there is right before the previous pasted code,seg031:0C57          checkSaboteur:                        ; CODE XREF: objectTakeDamage+B6jseg031:0C57 C4 5E 06              les   bx, [bp+unitGamePtr]seg031:0C5A 26 80 7F 02 06           cmp   es:[bx+_unitGame.typeIndex], 6    ; Saboteurseg031:0C5F 75 0C               jnz   short notSaboteurseg031:0C61 B8 14 00              mov   ax, 14h               ; Saboteur Destroyedseg031:0C64 50                 push   axseg031:0C65 9A 2A 00 86 42           call   j_soundTableLoadseg031:0C6A 59                 pop   cxseg031:0C6B EB 47               jmp   short action0Aseg031:0C6D          ; ---------------------------------------------------------------------------seg031:0C6Dseg031:0C6D          notSaboteur:                         ; CODE XREF: objectTakeDamage+E7jEDIT: According to the Unit Action Table at seg156:006E, Index 0A is 'DIE' Quote Link to comment Share on other sites More sharing options...
MrFlibble Posted August 23, 2009 Share Posted August 23, 2009 Just a thought occurred to me right after I posted, what if the auto-targeting of aerial units is separate for human and computer-owned units? There are some bits always set to No, even among Unknown 006, and from what I have observed, human-controlled units seem to ignore enemy aircraft, or are very lazy about attacking it.Do you think this could have some merit? That there's a separate bit which, when activated, would make player-controlled units automatically attack air units within their range? Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 23, 2009 Author Share Posted August 23, 2009 There's stuff like that in C&C1 too... logics that differ if the player is human. For example, the helicopter Guard command is blatantly replaced by Area Guard for CPU-owned units. Quote Link to comment Share on other sites More sharing options...
segra Posted August 24, 2009 Share Posted August 24, 2009 not sure if this will help, but this is the only location (that ive found) which checks the target air unit bit... right afterwards it checks for the BIT before it (bit4 of unknown6) but only if its a flying unitseg031:1242 26 F7 47 0C 00 20        test  es:[bx+_unitData.optsWocaTuro], _UnitOptsWocaTuro_TargetAirUnitseg031:1248 75 03              jnz  short loc_295ADseg031:124A E9 50 FF             jmp  NoRangeseg031:124D         ; ---------------------------------------------------------------------------seg031:124Dseg031:124D         loc_295AD:                         ; CODE XREF: unitDamageUnitGet?+C3jseg031:124D C4 5E FC             les  bx, [bp+unitDataPtr2]seg031:1250 26 83 7F 3C 04          cmp  es:[bx+_unitData.MovementType], 4 ; Flyingseg031:1255 75 3C              jnz  short notFlyingseg031:1257 C4 5E F8             les  bx, [bp+unitDataPtr]seg031:125A 26 F7 47 0C 00 10        test  es:[bx+_unitData.optsWocaTuro], _UnitOptsWocaTuro_1000seg031:1260 75 03              jnz  short loc_295C5seg031:1262 E9 38 FF             jmp  NoRangeseg031:1265         ; ---------------------------------------------------------------------------seg031:1265seg031:1265         loc_295C5:                         ; CODE XREF: unitDamageUnitGet?+DBjAlso later in this function, the unit data field 'Aggressivity' is added with the word just before it, at +0x2Dseg031:12FC C4 5E FC             les  bx, [bp+unitDataPtr2]seg031:12FF 26 8B 47 2F           mov  ax, es:[bx+_unitData.Aggressivity]seg031:1303 C4 5E FC             les  bx, [bp+unitDataPtr2]seg031:1306 26 03 47 2D           add  ax, es:[bx+_unitData.field_2D] Quote Link to comment Share on other sites More sharing options...
segra Posted August 24, 2009 Share Posted August 24, 2009 Unknown6 bit3 seems to be 'ForceScriptCycles', it controls the number of script executions that occur during the units processing turnIf its set to 0, the unit is checked to see if its inside the 'user screen area', if so it uses the standard amount, otherwise it only executes 1 cycle.when the bit is set to 1, it always uses the standard amountstandard amount calc:  word_46D58 == 0x0A (seems to never be modified)seg030:06F7 A1 38 39              mov   ax, word_46D58  seg030:06FA BA 05 00              mov   dx, 5seg030:06FD F7 EA               imul   dxseg030:06FF A3 3C 39              mov   scriptCyclesLeft, ax Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 24, 2009 Author Share Posted August 24, 2009 So this means units will act differently off-screen? Bizarre.Or is this 'user screen area' the revealed terrain? That might explain how worms only become active after they are discovered.[edit]eh, are we talking about a different option again? The unknown 6 bit 3 is only activated on weapons and flying units... or do you count your bits from 0 too? I got bits 1-8.If you mean the 4th option then it would make sense... this is disabled on all units except the harvester and saboteur. Strangely enough this is also enabled on the sandworm though. Quote Link to comment Share on other sites More sharing options...
segra Posted August 24, 2009 Share Posted August 24, 2009 ive been posting all references in relation to your editor (im using v1.12.0), was converting from the dis-assembly so we don't have any confusion about the sizes or naming of them.. guess that backfired :)Unknown 006 (bit 3) is not activated on flying units or weaponsthat means all units, except the flying ones and the weapons will always run there script normally... flying units/weapons only run normally once they enter the users screen Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 24, 2009 Author Share Posted August 24, 2009 weird. Especially projectiles should not be affected by whether they're in the user's screen... not to mention that projectiles shouldn't do much more than fly to a target and explode anyway.And I can't imagine any behaviour difference between a carryall I'm looking at and one I'm not looking at.Are you sure it's the user's screen it checks, and not the shroud?#4 seems like a likely candidate for an option like "active even in shroud". Quote Link to comment Share on other sites More sharing options...
segra Posted August 25, 2009 Share Posted August 25, 2009 yeah its definatly not shroud related, the function which is called doesn't access the map data.. but this may explain it the variable is actually the TACTICAL Position, not the cursor position.. apparently i labelled the variable wrong at some point in the past.. doh :)so when these units are within a certain range of tactical, they execute more cycles than normal Quote Link to comment Share on other sites More sharing options...
stefanhendriks Posted August 25, 2009 Share Posted August 25, 2009 I have seen units move way quicker on screen, than off screen. Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 25, 2009 Author Share Posted August 25, 2009 Ehh, that has no relation to AI behaviour, Stefan. It's probably just a bug of the same kind as how the game speed affects the sonic range :PSegra:So the variable is actually "unit is more active/intelligent outside TacticalPos range" then? Still seems kinda odd if all units have it enabled anyway.Then again, this code might be for 'thopters... Quote Link to comment Share on other sites More sharing options...
stefanhendriks Posted August 25, 2009 Share Posted August 25, 2009 Lol, I should stop posting using my IPhone. Somehow I have posted in the wrong topic. EDIT:Meh, I did post in the correct topic.I meant to reply to:So this means units will act differently off-screen? Bizarre.Basically, this is correct. Somehow I always thought that this was intentional to save CPU cycles for all that happens off-screen. Especially in the days of the 80286 / 80386 processorss. Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 25, 2009 Author Share Posted August 25, 2009 Actually, Segra just said that this didn't relate to that; it's about the TacticalPos set in each map. Which, I guess, is an indication for the AI player as to where to find the player's base... or at leaast, where to move its units to before attacking. I guess that way they can control from which side the AI attacks.[edit]Oh, Segra, is CursorPos actually changed with the screen location when scrolling? I know it's set in the ini file, but there it just acts as the point on which to center for the start location. Quote Link to comment Share on other sites More sharing options...
stefanhendriks Posted August 25, 2009 Share Posted August 25, 2009 What i meant, is that without looking into the EXE, i can see it happening while playing. Try this:Be any house, build the fastest unit available (ie ordos trike is a good example).Now, put both trikes in the same X axis. Keep them a bit apart. Then, move them both UP/DOWN to the other side of the map. Of course, you will have a delay to move the units. Keep ONE unit in your screen, the other not.It is tough to test, because there are possible slow downs by terrain; so you have to watch for this. I've seen a trike arriving first, while i sent him later. Also, i was playing with setting "FASTEST". If i'm correct, the FASTEST option is somehow FPS based and not timer based? Quote Link to comment Share on other sites More sharing options...
XTF Posted August 25, 2009 Share Posted August 25, 2009 Actually, Segra just said that this didn't relate to that; it's about the TacticalPos set in each map. Which, I guess, is an indication for the AI player as to where to find the player's base... or at leaast, where to move its units to before attacking. I guess that way they can control from which side the AI attacks.[edit]Oh, Segra, is CursorPos actually changed with the screen location when scrolling? I know it's set in the ini file, but there it just acts as the point on which to center for the start location.Isn't TacticalPos the position of the screen and CursorPos that of the cursor/pointer?I've heard this before, units off-screen don't get as much CPU cycles.BTW, bits should really be counted from 0. ;) Quote Link to comment Share on other sites More sharing options...
MrFlibble Posted August 25, 2009 Share Posted August 25, 2009 So this means units will act differently off-screen? Bizarre.It is said that units that are off-screen actually move slower than those on screen:In order to render the game playable on 8-16 MHz systems, it was necessary for the designers to have off-screen units update at about half the rate of those on-screen. This only affected movement, but it resulted in a player being able to move an army much faster if he scrolled the map to keep them in view.(source) Quote Link to comment Share on other sites More sharing options...
segra Posted August 25, 2009 Share Posted August 25, 2009 Olaf is correct about the tactical/cursor options/variables.from the affected scripts tho, most of them just do a delay and destroy (weapons)carryall/thopter/sandworm all have more to do, however alot of the functions are still unknowns.not sure how much realtime change we could see, but enabling the bit for thopters should make them select targets faster (the script seems to check unit house, compare distance, then attack).. instead of it taking maybe 5 loops of the game engine for 'one script loop', it may only take 1... ( these numbers are all made up )[sonicBlast]PushWord       1800Execute       Delay AddSP        1Execute       Destroy Pop          (Return)[bullet]PushWord       6000Execute       Delay AddSP        1Execute       Destroy Pop          (Return)EDIT: Btw, for the interested... In the unit scripts:Register 0 is current action, set after a call to the "unitAction" functionRegister 3 is the Human House ID Quote Link to comment Share on other sites More sharing options...
Nyerguds Posted August 25, 2009 Author Share Posted August 25, 2009 I don't see how a mission would benefit from changing the position of the mouse cursor...It is said that units that are off-screen actually move slower than those on screen:(source)Right, but as I already said to Stefan, that's not what this is about... this is about it actually behaving differently -_- Quote Link to comment Share on other sites More sharing options...
segra Posted August 25, 2009 Share Posted August 25, 2009 without changing the mouse cursor position it might be hard to click on things :P (the variable is used for building placement, unit selection, etc) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.