Yeah it will most likely break the unit AI a little.
Running a normal AI script for p9-12 will crash the game, and they still won't have vision. You can order them to do stuff and run random scripts like Junk Yard Dog for them though.
Does it effectively mean P9-P12 won't attack enemies until provoked even when made computers? Can they even have allies at all (i.e. is there a place in an alliance flags for those players)?
They have alliance flags IIRC. I don't know if they are honoured. P9-12 won't attack enemies even when they are provoked. They will just run up to them and hug them.
@Neiv is it possible to get an updated list from 1.21.1? Is it easy to do or would it be possible to create a diffing tool?
For your unknown flags: 0x000000 - Simple Data 0x000002 - Readonly 0x000010 - Allowed as value for matching "backed by code" item (not actual read/write address) 0x000020 - Pointer 0x002000 - Unsupported
The high byte is the "backed by code" type. 01 - CHK String ptr 03 - Repulse ptr 04 - trigger pointers 06 - buttonset data 07 - Possibly dummy write space? 08 - player structures 09 - Unit stat conditions/actions 0A - unit selections 0B - Button page table 0D - Storm graphics palette (1505E670) 14 - Sprites.dat image type 15 - units 16 - unitFinder 17 - sprites 18 - images 19 - empty list unit pointers 1A - images.dat draw function 1B - twire grp pointer 1C - grpwire grp pointer 1D - tranwire grp pointer
Post has been edited 4 time(s), last time on Dec 15 2017, 1:44 pm by Heinermann.
Tried a few of those pointers (005993C4, 00628444, 00628458, 0068C148), they were initialized to 0 and writes got stored but not linked to rest of the game
The following offsets of the unit structure can be read/written:
Quote
0x0 Unit *prev 0x4 Unit *next 0x8 u32 hitpoints 0xc Sprite *sprite 0x10 u16 move_target[2] 0x14 Unit *move_target_unit 0x20 u8 flingy_flags 0x21 u8 facing_direction 0x22 u8 flingy_turn_speed 0x23 u8 movement_direction 0x24 u16 flingy_id 0x26 u8 0x27 u8 flingy_movement_type, 0x0 = flingy.dat, 0x1 = No deacceleration?, 0x2 = iscript 0x28 u16 position[2] 0x2c u32 exact_position_x (0x100 times more accurate than normal coords) 0x30 u32 exact_position_y 0x34 u32 flingy_top_speed 0x48 u16 flingy_acceleration 0x4a u8 new_direction? 0x4b u8 target_direction 0x4c u8 player_id 0x4d u8 order 0x4e u8 order_state 0x4f u8 iscript_sigorder_flags 0x54 u8 order_timer 0x55 u8 ground_cooldown 0x56 u8 air_cooldown 0x57 u8 spell_cooldown 0x58 u16 order_target_position[2] 0x5c Unit *target 0x60 u32 shields 0x64 u16 unit_id (unit type) 0x66 u16 0x7c Unit *recent_attacker 0x80 Unit *related 0x8c u16 0x8e u8 rank_increase 0x8f u8 kills 0x98 u16 build_queue_slot_0 (Note that the "active slot is not necessarily slot 0, it is determined by current_build_queue_slot) 0x9a u16 build_queue_slot_1 0x9c u16 build_queue_slot_2 0x9d u16 build_queue_slot_3 0xa0 u16 build_queue_slot_4 0xa2 u16 energy 0xa4 u8 current_build_queue_slot 0xa5 u8 minor_unique_index 0xa6 u8 secondary_order 0xa7 u8 building_overlay_state 0xdc u32 flags 0xf8 Unit *previous_pylon (*) 0xf8 u16 rally_point[2] (*) 0xfc Unit *next_pylon (*) 0xfc Unit *rally_unit (*) 0x110 u16 death_timer 0x112 u16 defensive_matrix_dmg 0x114 u8 matrix_timer 0x115 u8 stim_timer 0x116 u8 ensnare_timer 0x117 u8 lockdown_timer 0x118 u8 irradiate_timer 0x119 u8 stasis_timer 0x11a u8 plague_timer 0x11b u8 is_under_storm
Obviously the offsets are aligned by 4 and all accesses edit the 4 bytes. Also seems that Blizzard got lazy and didn't bother implement all spell timers? o.o
(*) Interestingly the union Unit + 0xf8/0xfc which contains pylon linked list/rally point info, is only accessible for units that aren't pylons nor have rally points. But it is possible to work around it by switching the unit type back and forth when accessing the fields.
So I made a probe provide pylon power:
(Though then I realized that I could've just overridden the order to make it add itself into the pylon list instead of the sketchy workaround I had to do in order to edit the pylon list. Oh well)
My understanding of this is that EUD mappers figured out that 1.16.1 has so predictable memory allocation that they can just access memory at address 19xxyyzz, and it'll always contain these dynamically allocated structures like wireframe grps, triggers and the map string table.
Maybe Koreans had a plugin that actually makes the memory allocation consistent, or maybe it was just ridiculously fragile, I don't know.
And now Blizzard is emulating the 1.16.1 memory allocation; It is possible to write to the dynamically allocated trigger structures that were read from the .chk, but the offset isn't just a simple 190bd120, it depends on how large those previous allocations were.
There is a high level of predictability in the old Storm library used in SC 1.16.1. The EUD map makers are not encouraged to hardcode dynamic addresses. They should rely on static pointers but then compute its value dynamically.
Additionally, EUD map makers, often times, never respected the original allocation sizes and hence they were doing heap overflows. Luckily SC 1.16.1 still worked. In the SCR emulation, the emulator gives extra few KBs for certain dynamic buffers so that the maps work "nicely".
I ran into weird hardcoded addresses as well in SC 1.16.1 and though that perhaps there are launchers facilitating such access to those addresses (not normally available). I don't really know for sure. Addresses that I cannot trace their original (and hence properly emulate them) will not be supported.
Interestingly the union Unit + 0xf8/0xfc which contains pylon linked list/rally point info, is only accessible for units that aren't pylons nor have rally points. But it is possible to work around it by switching the unit type back and forth when accessing the fields.
0xf8 Unit *previous_pylon (*) 0xf8 u16 rally_point[2] (*) 0xfc Unit *next_pylon (*) 0xfc Unit *rally_unit (*)
Prior to SC patch #3402, the emulator had a bug and it was not possible to change the pointer values. Now in #3402 and up, that bug is fixed.
Quote
Also seems that Blizzard got lazy and didn't bother implement all spell timers? o.o
The next patch will add more CUnit fields. We add them on demand. There are lots of them
Quote
So I made a probe provide pylon power
Not bad, very funny.
Unfortunately, this kind of type swapping is unpleasant. I am thinking to make uwType changes as emulator only changes. Do you know if there's a real need for changing the uwType from EUD maps? Can you give me a real life scenario?
Unfortunately, this kind of type swapping is unpleasant. I am thinking to make uwType changes as emulator only changes. Do you know if there's a real need for changing the uwType from EUD maps? Can you give me a real life scenario?
Thanks!
More flexibility with what we can do when it comes to dealing with a unit's Index ID. Otherwise we are required to make use of preset units and those units can never die, the latter is one of the bigger issues. Making VHP for everything is fine and all, but a pain (even with EUDs).
Changing units without worrying about terrain causing friction because of Create Unit or Move Unit's requirements for placement is another big one.
Changing unitType (0x64, 2 bytes) was a very easy way of merging the graphics and movement behavior of one unit with the weapons and abilities of another.
- Changing the unitType of an SCV to that of a wraith created and SCV that fired wraith rounds. - Changing the unitType of a tank to that of a dropship created a ground based unit you can load units into (like an armored troop transport). - Changing the unitType of a interceptor to that of an archon gives your interceptors a neat splash attack and the ability to command their movements, though they only attack targets chosen by the carrier and will return to the carrier if stop is pressed.