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.
SDE, BWAPI owner, hacker.
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.
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.
Quote from 
Heinermann
Heinermannthey still won't have vision
Some.
SDE, BWAPI owner, hacker.
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.
@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.
New/changed offsets for 1.21.1:
I could imagine Blizz also whitelisting more structure fields, but that isn't visible here.
Full dump: https://pastebin.com/C3B54GXf
I'll try to make this tool work automatically on new patches someday so that anyone could dump these then.
I could imagine Blizz also whitelisting more structure fields, but that isn't visible here.
Collapsable Box
Full dump: https://pastebin.com/C3B54GXf
I'll try to make this tool work automatically on new patches someday so that anyone could dump these then.
None.
SDE, BWAPI owner, hacker.
Quote
+005993C4 | 00000004 | 00000000
Same with a bunch of other pointers.
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:
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)
Attachments:
Post has been edited 2 time(s), last time on Dec 15 2017, 10:25 pm by Neiv.
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
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
(*)
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)
Attachments:
Post has been edited 2 time(s), last time on Dec 15 2017, 10:25 pm by Neiv.
None.
ᴄʜᴇᴇsᴇ ɪᴛ!
Can we only read/write in 4 byte increments, or can we also read bits or single bytes?
"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"
Yeah, you'll have to work with 4 byte chunked reads/writes.
None.
Quote
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.
Quote
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 (*)
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?
Thanks!
Let me show you how to hump without making love.
Quote from 0xeb
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!
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.
None.
Cartography Artisan
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.
- 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.
TheNitesWhoSay - Clan Aura - github
Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.
Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.
[11:49 pm]
O)FaRTy1billion[MM] -- o, due to a donation i now have enough minerals to send you minerals[2024-4-17. : 3:26 am]
O)FaRTy1billion[MM] -- i have to ask for minerals first tho cuz i don't have enough to send[2024-4-17. : 1:53 am]
Vrael -- bet u'll ask for my minerals first and then just send me some lousy vespene gas instead[2024-4-16. : 5:05 pm]
Vrael -- Its simple, just send all minerals to Vrael until you have 0 minerals then your account is gone
Members Online: Roy
Roy