Staredit Network > Forums > Modding Discussion > Topic: Object limits plugin
Object limits plugin
Aug 10 2015, 11:14 pm
By: Neiv  

Sep 28 2015, 2:16 am Heinermann Post #21

SDE, BWAPI owner, hacker.

If you're actually changing the save format (which I assume you are), consider using this library. I've had some really good experiences with it after getting used to how it worked.




Sep 28 2015, 2:35 am Pr0nogo Post #22



Am I misreading this or are you discussing the possibility of simply adding new unit entries (theorised by Broodkiller when DatEdit was still being updated) instead of having to cannibalise old ones?




Sep 28 2015, 6:14 am Sand Wraith Post #23

she/her

Quote from Pr0nogo
Am I misreading this or are you discussing the possibility of simply adding new unit entries (theorised by Broodkiller when DatEdit was still being updated) instead of having to cannibalise old ones?

Actually, now that this has been mentioned, has anyone seen where/how SCBW loads *.dat files? I would be very much interested in extending how many entries there are in all of the *.dat files and forcing SCBW to load them.

EDIT: Thank you for all of your time and responses Neiv, they have been very enlightening and helpful.




Sep 28 2015, 11:09 am Neiv Post #24



Quote from Heinermann
If you're actually changing the save format (which I assume you are), consider using this library. I've had some really good experiences with it after getting used to how it worked.

Seems nice, being header-only and small =) Seems like the binary writer does not do any compression though, but it should not be too hard to create compressing streams? I need a custom stream anyways as parts of the saving code use bw's functions which write to a C stdlib FILE.

Also the quote "cereal was not designed to be a robust long term storage solution - it is your responsibility to ensure compatability between saved and loaded cereal archives. It is recommended that you use the same version of cereal for both loading and saving data." from the website sounds slightly bad, but there should be no need to update the library ever?

--

Additional .dat entries would require writing a new .dat loading code (easy), and rewriting all functions which access the .dat arrays (painful). Additional units.dat entries would be the worst, as there are a lot of arrays which aren't directly related to .dat files but assume 0xe4 unit types.
Also PyDAT would have to be modified so it can understand the extended .dat file formats.



None.

Oct 2 2015, 6:37 pm Polaris Post #25



Good God I wish this all had existed back when I was modding Starcraft. Granted, I had no knowledge of programming at the time so extending it and modifying it would be out of the question I suppose... But still. Neiv, you are a hero.



If anything cool is ever going on Skype me up under the name "blarghle"

Oct 12 2015, 4:43 am Sand Wraith Post #26

she/her

Quote from Neiv
Yeah.. Unit damage/death is handled bit weirdly there... (It allows some optimizations when units die during Bullet processing, even if the damage was not caused by bullet)

I assume the damage is dealt during some child function of Unit::ProgressFrames() ? There is function Unit::DamageSelf(), which is used for burning damage and such. It needs structure ProgressUnitResults which is used to collect any unit which may have been killed by the damage, so the unit death is handled when appropriate. You need to get that structure from Unit::ProgressFrames() or from any of its child function it gets passed to.

AddHit() and DamagedUnit are supposed to be used by bullet.cpp, and Unit::DamageSelf() should be used instead of DamageUnit(), as it handles death properly.

If you actually aren't doing your damage from child function of Unit::ProgressFrames(), DamageUnit() should work, but you need to pass a empty vector<Unit *> there, and then unit->Kill(nullptr) any units that are added to that vector.
Edit: Actually unit->DamageSelf(dmg, nullptr) is fine outside unit frame progressing.

--Yes, comments would be useful

For the record: I resolved this with a function that mirrors other damage-dealing functions and a ProgressUnitResults pointer "results" as parameter. results->weapon_damages.emplace_back(...) worked out just fine and I was able to retain kill counter function.

I'm pleased with this result.

---

Now, I have a question regarding Unit::GetWeaponRange(bool ground) in unit.cpp.

While very straight-forward, I have tried modifying the body of the function to no effect. It uses switch(unit_id) to apply some range upgrade modifications. I replaced Unit::Marine with Unit:Firebat (and the enum looks fine, I checked it with units.dat), so that I get this:

Code
case Unit::Firebat: // Pronogo
           return range + GetUpgradeLevel(Upgrade::U_238Shells, player) * 0x20;


However, when I upgrade U-238 Shells in-game, the Marine is still the one firing at longer ranges! I was expecting the Firebat to benefit from the range upgrade and certainly not the Marine.

Is the function somehow not hooked in or something? I am baffled by the behaviour.

I've tried unchecking "Use Exe Edit Links" in Firegraft's EXE Edits tab and re-adding the plugin, rebuilding the plugin... What's wrong?




Oct 12 2015, 4:51 am trgk Post #27



Bug report by some other user in sdraft.

1. Lift & Land terran building -> Building shadow casts weirdly.
2. Apply lockdown/eradiate to goliath/tank -> goliath/tank turret's elevation
is higher than that of lockdown/eradiate effects, so they just pop out from it.
3. Effect glitch by defensive matrix hit.
4. Hitpoint bar bug. (Happens rarely, maybe only to the buildings)
- Real hitpoint and hitpoint bar's color won't match.
- Hitpoint bar won't update
5. Mind control carrier -> interceptors won't be given to casting player.
6. Missile turret lags : It took about 1~2 sec for them to start attacking the target.



EUD

Oct 12 2015, 8:32 am Neiv Post #28



Quote from Sand Wraith

For the record: I resolved this with a function that mirrors other damage-dealing functions and a ProgressUnitResults pointer "results" as parameter. results->weapon_damages.emplace_back(...) worked out just fine and I was able to retain kill counter function.

I'm pleased with this result.
Cool, if adding stuff to the results arrays does what you need, it's great and there won't be any weird gotchas or anything, unlike with some bullet-related things.

Quote from Sand Wraith

Now, I have a question regarding Unit::GetWeaponRange(bool ground) in unit.cpp.

While very straight-forward, I have tried modifying the body of the function to no effect. It uses switch(unit_id) to apply some range upgrade modifications. I replaced Unit::Marine with Unit:Firebat (and the enum looks fine, I checked it with units.dat), so that I get this:

Code
case Unit::Firebat: // Pronogo
           return range + GetUpgradeLevel(Upgrade::U_238Shells, player) * 0x20;


However, when I upgrade U-238 Shells in-game, the Marine is still the one firing at longer ranges! I was expecting the Firebat to benefit from the range upgrade and certainly not the Marine.

Is the function somehow not hooked in or something? I am baffled by the behaviour.

I've tried unchecking "Use Exe Edit Links" in Firegraft's EXE Edits tab and re-adding the plugin, rebuilding the plugin... What's wrong?
Ehh.. That's case where the GetWeaponRange() function was
1) Short and simple
2) Added early during development when calling bw functions was not so simple as it is now

That function mirrors how bw works (kind of, as it allows stacking the upgrade), but is not actually hooked so even if you edit it, bw calls still its own version at some places.

You can hook it by looking at how hooks generally are done in limits.cpp/offsets_hooks.h and adding another one to the list. GetWeaponRange is at 00475870, takes int weapon_id in ebx and Unit *attacker in eax. So it is slightly different from the one implemented in the Unit class, you may have to reorganize the code somewhat.

Quote from trgk
Bug report by some other user in sdraft.

1. Lift & Land terran building -> Building shadow casts weirdly.
2. Apply lockdown/eradiate to goliath/tank -> goliath/tank turret's elevation
is higher than that of lockdown/eradiate effects, so they just pop out from it.
3. Effect glitch by defensive matrix hit.
4. Hitpoint bar bug. (Happens rarely, maybe only to the buildings)
- Real hitpoint and hitpoint bar's color won't match.
- Hitpoint bar won't update
5. Mind control carrier -> interceptors won't be given to casting player.
6. Missile turret lags : It took about 1~2 sec for them to start attacking the target.

Huh, thanks for reporting and to the person who found those =)

I don't get what is the issue in 3., does it always happen? Only for certain units? Is it visual or is damage wrong? If it is rare, can I see a replay?
I do know though that casting psi storm on matrixed protoss unit deals no damage (Even though it should bypass shields), maybe that is a related bug.

Also if I can get replay on 4. it would make finding the bug easier, even if it didn't happen when watching the replay. Fixed hp bar not updating. Normal bw has some inaccuracies as well between status screen and hp bar color around 33% and 66% health, and those issues are still here.

There also were some bugs with hotkey grouping units and one where parasiting human-owned units would randomly freeze/crash, once those all get fixed I'll release a new version.

Post has been edited 4 time(s), last time on Oct 12 2015, 10:04 am by Neiv.



None.

Oct 12 2015, 10:44 am trgk Post #29



Issue3 : If unit with defensive matrix got hit, defensive matrix's
- Idle graphic should stop temporarially, but it's not.
- Only 'Hit' graphic should be displayed instead, but instead it stacks with idle graphic (according to the person who found the bug)

Sorry for bad eng



EUD

Oct 12 2015, 10:23 pm Neiv Post #30



I don't think the idle graphic is supposed to stop when matrix gets hit. However, related to bug #2, tanks and goliaths got wrong (too small) matrix hit graphic, which maybe was the issue?
Also other spells like plague, feedback and optical flare had the same bug of appearing below turret and have been fixed.



None.

Oct 24 2015, 8:11 pm Neiv Post #31



Alright, I have a bugfix update.
Version 1.0.2, fixes the following issues:

-Bw bug where unit's command buttons would not update in rare cases.
-Bug where using weapon spells (like yamato gun) in fogged units always failed.
-Memory corruption when using shift-number to add units to hotkey groups.
-Crash when selecting hotkey groups.
-Crash when an unit owned by human players was parasited.
-Mind control not controlling interceptors/scarabs
-Health bars not always updating correctly
-Bug where bullets would have 0.3% too low chance to miss (lol)
-Several spell overlays displaying incorrectly with tanks/goliaths.
-Missile turrets not facing their targets near instantly (Iscript turn1cwise thing).
-Incorrect shadow position after landing a building.
-Protoss units fully absorbing psi storms while having defensive matrix.
-Very minor ai targeting issues.

Also, it allows using iscript condjmps with bullets. The plugin has also always allowed using iscript turning opcodes with bullets, but I never mentioned it :P
And it allows using iscript "end" from any animation with bullets, not just from Death animation. (Units can't do that though)

As the iscript extensions can be used for creating cool effects, I made a short demo video of a few prototype units that bring the bullet/sprite counts far past bw's limits ^^


(I attached the mod used in the video as well, if someone wishes to look at it)

Attachments:
teippi-1.0.2.qdp
Hits: 13 Size: 1312.01kb
teippi-demo.exe
Hits: 1 Size: 2515.48kb

Post has been edited 1 time(s), last time on Oct 27 2015, 11:07 am by Neiv.



None.

Jul 21 2017, 6:40 pm Pr0nogo Post #32



Is modifying the source code for this permitted? It seems like the best basis for a modern plugin. Thanks for all your hard work.




Jul 21 2017, 7:06 pm Neiv Post #33



Yeah, obviously. I don't care what is changed / what is it used for / about being credited.

But I do feel that the plugin ended up being unnecessarily invasive and complicated, a lot of the code is nearly unnecessary and could have been replaced with more elegant solutions. So the plugin works very poorly with anything else modifying the code, even though the other plugins / Firegraft exe edits wouldn't touch code even near object de/allocation :/



None.

Jul 21 2017, 7:14 pm Pr0nogo Post #34



Right. Even so, there's nothing else on the proverbial market that provides this kind of functionality. If you find the time/desire to re-write some of those functions so they're more compatible, modders would definitely use it in conjunction with GPTP/Firegraft, but even still it'll see some use.




Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[02:41 pm]
razorback9423 -- NudeRaider
NudeRaider shouted: MTiger156 power over:wob:ing?
No, POWER UNDER :wob: ing!
[12:53 pm]
NudeRaider -- MTiger156
MTiger156 shouted: Power over:wob:ing
power over:wob:ing?
[12:27 pm]
MTiger156 -- crap...
[12:27 pm]
MTiger156 -- Power over:wob:ing
[11:50 am]
UEDCommander -- WARNING: Unit Unplaceable! (u) (69, 69)
[09:26 am]
lil-Inferno -- :wob:
[08:25 am]
Black_Overseer -- razorback9423
razorback9423 shouted: WARNING: Unit Unplaceable! (Aldaris) (1656,2996)
You have no power here, Gandalf the Grey.
[05:43 am]
razorback9423 -- WARNING: Unit Unplaceable! (Aldaris) (1656,2996)
[05:27 am]
razorback9423 -- stop
[05:27 am]
NudeRaider -- :wob: you can't :wob: us
Please log in to shout.


Members Online: Roy, jjf28, NudeRaider, DarkenedFantasies, UEDCommander, RIVE