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.

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.

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.

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.

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:



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?

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.

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.

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.


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.

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

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.

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
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:

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

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

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

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.