I made a thing: http://zk.kaen.us/ (requires JavaScript and a browser that isn't terrible) Ever wonder what the last Recon Commander buff was? Curious about the movement speed of the Flying Chicken Queen? Want to browse old/experimental/hidden/PW-only units? Try the Advanced ZK Unit & Balance Change Explorer! Read the About page for operational details. Sadly, this contraption can not detect general or indirect balance changes (such as game-wide physics or damage calculation changes). However, it will catch any changes to the raw stats. Obviously, this isn't really a nooby-friendly tool, and it isn't intended for adoption into the main ZK site. It should be considered more like fan art than a contribution to the ZK infrastructure. It is completely open source, but I plan to run it as an independent service. Ideas/bugs on the github tracker please. Inspired by Aquanim's heroic efforts and   [2up]knorke's excellent walkthrough.
+24 / -0
|
|
|
This is the second time we've built an angular-js thing that replaces unitguide, and we're getting exceedingly good at it. (wrt CovertMagic's project)
+2 / -0
|
Oh no! I didn't mean to step on anyone's toes, hopefully this is different enough in its purpose to not conflict. This is specifically not intended to replace unitguide though. Also, it has no way to be built into a static site (although such a thing is possible) which unitguide appears to have. Re: AngularJS. This is my third project using it (all personal), and I'm starting to see the downsides. I love the data binding and client-side routing of course, but the module/DI system feels so clunky, and I always run into silly gotchas (including this fun one: https://github.com/kaen/zk-balance/blob/master/assets/coffee/unit.coffee#L26 which required writing a memoized object masking algorithm to work around ...). For the next one I think I'll try react instead. Curious if you have any input,    mojjj.
+0 / -0
|
That was kind of a joke, but i forgot to denote it as such :P The tool seems pretty useful, a complaint would be that it does a bit too much JSON verbosity e.g. "object" <-- what?
+0 / -0
|
urrrg! coffescript! (i will take a look this weekend, maybe ask an expert colleague on monday about the circling. i myself work with angualar for quite some time now, but im far from being an expert)
+0 / -0
|
I just used a stock JSON formatter directive as a quick and dirty way to get it on screen. I agree though, I'm definitely not happy with the visualization. It's probably even worse than I thought, because I'm used to seeing JS Object trees all the time. I'd also like to translate the keys to human-friendly text, and improve the "significant" attribute detection so I could filter the deltas/current defs better. Maybe just an old school table would work?
+0 / -0
|
There is so much awesome in this tool! I'm actually sad it can't be stolen for S44 without heavy adaptation since we're using an inheritance model there.
+0 / -0
|
This is now the most convenient place to look up internal unit names in place of the unit guide.
+0 / -0
|
Is Venom called Anarchid on purpose? :)
+0 / -0
|
It is not a Venom Vermind. It is a starlight spider called Anarchid.
+0 / -0
|
I'm disappointed, there is not even all pw buildings.
+0 / -0
|
which ones are missing, killer?
+0 / -0
|
All unitdefs_post units (e.g. pw buildings which are autogenerated from DB config, commanders, etc) are missing - which is to be expected, as you're parsing source rather than running unitdefs.
+0 / -0
|
Can you elaborate? Where can I find info on how to "run unitdefs"? There's a lua evaluation component already, so it's actually not to crazy to try such a thing.
+0 / -0
|
The actual unitdefs_post file exists here. As for actual documentation, i'm not even sure if it's executed for each unit in a cycle, or just executed while UnitDefs table is still mutable. The feature has existed since at least 2010, is used to enable Spring 1944 and MCL OO-unitdefs, is uzed in ZK, BA, and BAR and yet ... it is largely undocumented on Spring wiki as much as i can tell. :|
+0 / -0
|
Unitdefs post is executed once while UnitDefs are still mutable. As far as I know it has no documentation because it's not an engine thing. Engine just asks defs.lua to impart the defs. Pretty much everybody uses the default defs.lua, which in turn relegates UnitDef loading to unitDefs.lua, and everybody uses the default unitDefs.lua which inflicts post-processing from unitdefs_post.lua onto defs after they're read from /units/*.lua files.
+3 / -0
|
Thanks for the info guys, it was really clear after reading your posts. That's actually not too bad. I'm not terribly interested in the calculated unitdef attributes yet (should I be?), but I could get a list of the missing PW units just by parsing this thing and invoking the functions in the table, right?
+0 / -0
|
On one hand, you do use unit mass, however, which is also calculated in _post. On the other, ZK's _post does some crazy things like remove unit innate energy generation and replace it with customparams. FWIW unit wreck costs should also be there in a perfect world >.>
+0 / -0
|
There isn't much the _post does that actually changes gameplay values other than representation for technical reasons. For example the customparams energy doesn't change the underlying meaning of "produces X energy". Note that Spring itself also changes representation between what it receives from defs.lua and what it provides to Lua in the form of UnitDefs [Spoiler]For example defs.lua has "maxvelocity" but UnitDefs provide "speed"; missile flight time goes in as seconds but comes out as frames; trajectory height comes as angle X in degrees but comes out as tan(X). The meaningful things _posts does are: * default decloak radius for units that don't have one, * defaults for Lua-based mechanics for units, * randomly buffs acceleration, * sets the reversing velocity, * overrides mass, * sets minimum build range,
+1 / -0
|
