|
It is a nice thing. The tool you made before, that dumps an entire class into a file. How hard would it be to change that to write a format that is compatible with this?
|
#
?
May 18, 2014 20:57
|
|
|
|
| # ? Jun 2, 2024 06:51 |
|
|
Hob_Gadling posted:The tool you made before, that dumps an entire class into a file. How hard would it be to change that to write a format that is compatible with this? That depends on what you want to do with it. The hardest part as stated is deciding on the match conditions - I could easily write out all the data as the "change" values (well, excepting the things it can't do as stated before) but I have no idea how to automatically line up that data with the entry they came from. What are you hoping to use that ability for?
|
|
#
?
May 18, 2014 21:33
|
|
|
power crystals posted:That depends on what you want to do with it. Create an easy way to move modded changes from one version to another. That's easily the most needed application for this tool. I would suggest dumping each instance into a file of its own. That makes comparison easier. Name the files automatically as classID.instanceID.xml to make finding the instance you want to work with easier. The idea is to make applying changes easier. Once you've edited a XML file you save it to your "modded" folder and can re-apply it against latest RD patch. It's easier to troubleshoot several smaller files (just run them one at a time to see where it breaks down), it's easier to work with reasonably sized dumps (dumping TUnites into one file is pretty unwieldy) and it's easier to understand for people who don't code. There are certain fringe benefits for people who like to code things, things like automatic database updates on a website (dump units, calculate checksums, update units/weapons/whatever with non-matching checksums). Hob_Gadling fucked around with this message at 22:05 on May 18, 2014 |
|
#
?
May 18, 2014 22:01
|
|
|
Serious question, wouldn't using instance ID as a key break it on patches anyway? The original idea was that your mod would start in this thing's format, rather than be divined out of an existing set of data. I have no moral issue supporting that workflow, but getting the technical details right will take longer. I should also really throw this crap up on Github or something but I need to decide what to do about the dependency on enohka's library since I did have to modify slightly for my older version of visual studio. Maybe I should just fork it and rip out the UI while I'm at it so I can package it as a dll. Doing one file per entry is something I can do as well, to be sure. I personally have no issue with the single massive file but I'm aware I'm an edge case so I welcome any feedback in that area. I'll think about this stuff at any rate.
|
|
#
?
May 18, 2014 22:11
|
|
|
power crystals posted:Serious question, wouldn't using instance ID as a key break it on patches anyway? Yes, but it's not used automatically as key for anything. The dumped files are just named in a fashion that makes it easier for the user to go into mod tools, modify M1A2 Abrams, check what's the instance ID for M1A2 Abrams, dump TUnites, find the correct XML file, decide and edit in a suitable matching criteria (which for units is probably an ID of some sort) and save it for later use. When RD updates, the user can simply take these saved XML files and apply them against the latest patch. Then he can continue working with the mod tools. It's still some amount of work to make sure the XML files match up correctly but a lot less than rewriting all changes by hand every time the game updates. quote:The original idea was that your mod would start in this thing's format, rather than be divined out of an existing set of data. I know. You can still do it, but I think most people will prefer to use a GUI to do the actual modding part. If I'm wrong, nothing lost, people can write XML by hand or scripts. I guess you could alternatively make a tool that dumps data from an Excel table into XML and applies that. Then people could have the genuine MadMat experience. 
|
|
#
?
May 18, 2014 22:23
|
|
|
Using Instance ID's would sort of nullify the point of the tool I thought?
Dandywalken fucked around with this message at 23:23 on May 18, 2014 |
|
#
?
May 18, 2014 23:04
|
|
|
Power crystals, you are a true Stakhanovite  you are doing amazing stuff.
|
|
#
?
May 18, 2014 23:51
|
|
|
drat now i want all infantry to explode like that. Can you modify the explosion to be bigger, so that tanks explode like 1 ton bombs or into cluster bombs? I'm also really curious as to what happens if you put the [CLUS] tag on anything not a bomb/artillery.
|
|
#
?
May 19, 2014 00:01
|
|
|
Xerxes, did you get a chance to give the babby pricemod a go? I'll be on in ten or so if you want a test partner.
|
|
#
?
May 19, 2014 00:03
|
|
|
xthetenth posted:Xerxes, did you get a chance to give the babby pricemod a go? I'll be on in ten or so if you want a test partner. Nah mate, was busy yesterday and I'm at work all day today. Perhaps tomorrow? E: Apparently putting cluster on other weapons makes them just always hit roof armor as found out by mikeboy the pubbie. So you can easily get top attack missiles in this way.
|
|
#
?
May 19, 2014 00:19
|
|
|
Hob_Gadling posted:Yes, but it's not used automatically as key for anything. The dumped files are just named in a fashion that makes it easier for the user to go into mod tools, modify M1A2 Abrams, check what's the instance ID for M1A2 Abrams, dump TUnites, find the correct XML file, decide and edit in a suitable matching criteria (which for units is probably an ID of some sort) and save it for later use. When RD updates, the user can simply take these saved XML files and apply them against the latest patch. Then he can continue working with the mod tools. Ok so basically what you want is a thing that will compare two .DATs (original and modded) and produce a diff file in that XML format. That I can probably do. I'll give it a shot sometime this week. Xerxes17 posted:Power crystals, you are a true Stakhanovite  Tulip posted:drat now i want all infantry to explode like that. Can you modify the explosion to be bigger, so that tanks explode like 1 ton bombs or into cluster bombs? I was going to make it the destroyer death blast but then I realized I'd have to find a destroyer first to figure out which weapon that was and  happened when I found a supply truck first.
|
|
#
?
May 19, 2014 00:43
|
|
|
Tomorrow I'll be out till semi-late, but if after 8 or so EST works I'm in. Tried it in deck building and against AI and it held up well to my eye for making most every tank at least worth consideration, and call-ins being interesting. Seeing how it does when one side isn't throwing way more points at the other will be interesting though.
|
|
#
?
May 19, 2014 00:46
|
|
|
power crystals posted:Ok so basically what you want is a thing that will compare two .DATs (original and modded) and produce a diff file in that XML format. No, not quite. I want XML files that contain one instance each and can be applied onto NDF files. It's the users problem to write some sensible matchcondition to the XML file. Once he does, he can forevermore use the same XML file to apply changes to NDF since the matching criteria change rarely (unit IDs changed once during ALBs lifetime). It's essentially a way to save up all the changes you want into a format that can be used forever once it's set up. The workflow: Building the XML base: 1) Mod M1A2 2) take note of its instance ID (let's say its 8072) 3) dump TUnites into XML files 4) find 8072.xml 5) add <matchcondition property="ClassNameForDebug" value="Unit_M1A2_Abrams" /> (or whatever other criteria you prefer) into 8072.xml 6) save the file somewhere safe 7) discard all other XML files RD updates! Applying your modded changes onto new patch: 1) WGPatcher.exe NDF_Win.dat 8072.xml RD updates again! 1) WGPatcher.exe NDF_Win.dat 8072.xml And that's it. There's never a need to touch the XML files once you've made them work correctly in the first place. Modders can use the GUI to hack in their changes, dump everything out, choose suitable matching criteria and save the necessary XML. It's a bit of manual work to get it done in the first place, but afterwards you can just apply the changes automatically with no effort required. Hope this makes sense.
|
|
#
?
May 19, 2014 00:55
|
|
|
Ok I see what you mean. I think I can do that too (I can tell it to supply a default match condition for tables where I know what a unique ID actually is), I'm just used to not wanting the stuff I didn't change to even be in the file which is why I expected a diff would be more useful. And I'm pretty sure I've seen the unit IDs change a number of times while working with the random deck generator, though it seems calmer now than it did during the beta at least. It currently doesn't support using the ID as a match condition anyway since that's not actually a property of the TUniteAuSolDescriptor class. I could add it in as another special condition like the '__order' one. While I'm here, what field controls the autonomy value? I'm tired of everything running out of gas halfway to the front on larger maps and now that I have this tool...
|
|
#
?
May 19, 2014 01:03
|
|
|
power crystals posted:And I'm pretty sure I've seen the unit IDs change a number of times They probably change every time Eugen adds, removes or changes something and recompiles since it's a feature of NDFBIN file format, not something that anyone was ever meant to see. The only use for it in my suggestion would be to give player a convenient way to find the XML file since some classes can have thousands of instances. Instance ID is unique and easy to search for as its just numbers. After the XML file has been located player can rename it for convenience. As for stuff that wasn't changed by player, it's still a good idea to dump it into the XML. Eugen may change unmodded values between patches, it's better if modder knows he will get exactly the same setup as it was before. If there was a good idea worth preserving modders can do the occasional unit by hand, or just not apply the XML files of those units. quote:While I'm here, what field controls the autonomy value? I'm tired of everything running out of gas halfway to the front on larger maps and now that I have this tool... Dandywalken probably remembers this one. I think there was a modifier for global fuel consumption, but if not it's somewhere in the Mouvementsomethingorother modules.
|
|
#
?
May 19, 2014 01:20
|
|
|
Xerxes17 posted:E: Apparently putting cluster on other weapons makes them just always hit roof armor as found out by mikeboy the pubbie. So you can easily get top attack missiles in this way. Which makes the RBS 56 "workaround" pretty stupid, and the "no we can't have top-attack ATGMs without simulating it by jacking up the AP values to retard mode, it would be too much work to code it properly" argument for excluding the Javelin and other top attack ATGMs moot.
|
|
#
?
May 19, 2014 01:57
|
|
|
I used to joke that Eugen only made these games fun by accident. I see they are determined to prove it isn't just a joke 
|
|
#
?
May 19, 2014 02:07
|
|
|
power crystals posted:
So truck death blast is a weapon effect that you just tied to motostrelki death event, so you could use any weapon? (actually that seems like how the UniteSolwhatevers described unit deaths, so this is unsurprising) Also i was seriously like 100% sure that you could make "cluster atgms" that would effectively be top attack, and the fact that they're being big whiny goon babies about making the RBS56/Hellfire/Javelin is just kind of embarassing.
|
|
#
?
May 19, 2014 03:07
|
|
|
Xerxes17 posted:
lol
|
|
#
?
May 19, 2014 03:18
|
|
|
this all seems rather silly when they could just put everything in xml and have the game compile it.
|
|
#
?
May 19, 2014 03:29
|
|
|
Mikeboy's actually one of the better modders in my experience. He's a step above me, but below the big leagues like Soundwolf IMO. He's done some drat fine work with plane loadouts etc.
|
|
#
?
May 19, 2014 04:20
|
|
|
I've been trying to get a good look at the derived stats of various tanks and I have learned far too much about excel for my liking. I really want to make a decent set of rules for balancing tanks by good metrics that reflect their performance so that if I mess something up it's systemic, but I'm having a "fun" time trying to quantify ability to eat shells. AP+AV is pretty easy, but weighting for accuracy and RoF is a bit interesting. Thankfully hits/sec is a pretty good number for raw firepower against infantry and light vehicles. That way any massive outliers are going to be visible pretty easily. It's just acutally taking everything into account well.
xthetenth fucked around with this message at 07:07 on May 19, 2014 |
|
#
?
May 19, 2014 07:05
|
|
|
Creating a tank performance index is a royal pain in the butt. Especially when you consider you're essentially creating a pricing scheme anyway. edit. Also you can't really value AP and AV the same even though their performance is persymmetric, their distribution and thus value is most definitely not. The whole thing ends up becoming quite subjective, but at least it's subjectivity that's universally applied. Then there are other things like optics, can't really justify a 5pt increase to medium optics, but going to good optics is actually kind of a big deal. So it's non linear. ATGMs kind of have an inverse relationship in value to the performance of the rest of a tank - ie an svir adds marginal capability to a T72BU, but a kobra adds lots to a T64BM and an S.11 adds a whole lot of extra capability to an AMX-13 even if it's a rather mediocre missile. edit: This was my attempt at it. It's basically all functional - mostly it needs tweaking (the top end is expanded too much, the middle/low end compressed too much), but that's mostly a matter of adjusting the AP/AV value columns. No provisions for autocannons, or differnce between KE and HEATm, and the aforementioned ATGM/value scaling. On Sheet 2 you can see a bunch of examples it generated. Feel free to pick it apart for inspiration or whatever. If you're interested or have any questions feel free to message me or whatever. Shanakin fucked around with this message at 07:53 on May 19, 2014 |
|
#
?
May 19, 2014 07:38
|
|
|
Yeah. Getting it good enough to do the pricing fully is really nasty, but it'd probably be worth it to get decent metrics just as a sanity check for the pricing I do, so I can see that a given tank is way killier against other tanks for its price than expected or something like that that'd be an outlier that warrants another check even if it's by rough metrics. Also, for good optics combat recon, they're also paying a rather steep toll in availability and left out in the cold by min-maxing. I'm kind of halfway toying with the idea of seeing what happens if I price them like specops recon infantry by making them roughly similar price but at way less availability. If you're buying them for their combat ability, it's taking enough availability hit that it's an expensive way of getting what you want or a unit that can operate on its own at a really small scale. If you're buying them as a backup spotter they're so often a victim of minmaxing in order to get good recon and often better combat units rather than paying for a mix. It's the sort of trait for a unit that has ramifications for the force more than the individual unit, so it feels like it could work if the price is paid by the deck. This may have something to do with me very rarely seeing good optics units. xthetenth fucked around with this message at 08:30 on May 19, 2014 |
|
#
?
May 19, 2014 08:10
|
|
|
Nothing wrong with just going with what we currently have suggested and then adjusting it by gut feeling onwards in an iterative process. You will never get it 100% right first try anyway, no point in tearing your hair out about the last 5% or so.
|
|
#
?
May 19, 2014 08:24
|
|
|
Yeah, fair enough. Think I'll just get a grand unified spreadsheet of tanks going because I'm not sure now whether I'll even be using the same tools by the time I'm done, probably go for the Brits first because between the Cents and Leos that's basically four more countries with only minor tweaks. Hopefully I'll get it close enough that personal preference and deck strategy starts to override optimal spreadsheet choices. That's really the key bit.
|
|
#
?
May 19, 2014 08:36
|
|
|
Sorry for interrupting the modchat, but I have some more mundane stats questions: Which is more accurate - a hardened milan 1 team (35% acc, 16% hardened bonus) or a trained milan 2 team (40% acc, 8% trained bonus) Is it as simple as acc+training bonus = chance to hit? (If this thread is anything to judge by, I think not...) Is there any reason to take a veteran challenger 2 over two trained ones? I would think that ubertanks must pick up xp pretty fast, but I've never really played them much.
|
|
#
?
May 19, 2014 10:37
|
|
|
Jaguars! posted:Sorry for interrupting the modchat, but I have some more mundane stats questions: 1. It's a multiplier. Although the files indicate they might actually still be using the ALB multipliers which were bigger. For now though: .35*1.16=40.6% .4*1.08=43.2% 2. Units gain XP proportional to their own value vs what they kill. So expensive things have to kill a lot to level up generally. Reservists level up really easily on the other hand. edit: the main reason you would take 1@vet is if you never call in more than 1.
|
|
#
?
May 19, 2014 10:43
|
|
|
Generally top tier tanks should be taken at minvet because of the quantum effect wherein you lose half your availability instead of 25% or whatever.
|
|
#
?
May 19, 2014 10:46
|
|
|
Cheers guys. advice taken on board. Anyway, I might as well share the deck i'm working on:  WvAgwLPCx4JVlk8EHgwTEOssrdZg3NBB+CofZcowWZmduOrTXCcUvoX0SVpBiQiCNEOhWQRKeUfiHFi8JFUbKP5HakJS+hnM3A== It's a commonwealth revision of an older ANZAC deck that used a sort of anti-helirush strategy starting by bringing large numbers of rapiers and light tanks. This is really only a draft version, I haven't fully looked over the extra units available to the commonwealth.  RvCh5OEsesG5oWPBKgXDB49UaB4MCC1RoGQlQPwUYLUvmuJhBj5BGUGL6I+y+icUCyiHR+IIkOJcp1aYLSVmOlIrtxOuSJMrE5A= And here's the old deck, which was a NZ army gimmick deck that battletested pretty well during the beta but has been knocked with the nerfbat a few too many times. Feel like a challenge? Try these, which I believe are the oldest all-around decks possible in the game.  tuAYkke6HJU0Oqpsun3RriehsVMnwh5L6lli+yfNRQYdkXpFyf5RZNchYMBoTUqRoZJMjWIFpbU3wbwt7HDMLISEVCK9JaoXUMg=  XugdM49zKfVznc2piCBjRROyUIFtkdCFAmqacKlmdkQ6TkuEVXQrKoBYqrs1gLmJ/pd0bhUQiyVZQuGWUviVMSKJBMfKO5GxAQA=
|
|
#
?
May 19, 2014 12:21
|
|
|
Soooo, all this talk of modding. Would an actual Warhammer 40k mod be possible with these tools? Nb Not an offer, i have neither the time or the skills. Just wondering if someone could
|
|
#
?
May 19, 2014 13:08
|
|
|
you can already play 40k, just use nothing but FSJ. but seriously there would be so much talk of Metal Boxes and their various negative attributes, you have no idea
|
|
#
?
May 19, 2014 13:15
|
|
|
THE COWARDS THE FEWLS
|
|
#
?
May 19, 2014 13:17
|
|
|
Look! Gavins! GAAAVIIIIINS!
|
|
#
?
May 19, 2014 14:01
|
|
|
Just thinking as far as towed artillery is concerned, you might be able to ghetto implement it with making them functionally infantry that move at a speed of 1 outside their transports.
|
|
#
?
May 19, 2014 17:06
|
|
|
Leif. posted:Just thinking as far as towed artillery is concerned, you might be able to ghetto implement it with making them functionally infantry that move at a speed of 1 outside their transports. Infantry are already vehicles anyway as I understand it, so there's even less impediment than that.
|
|
#
?
May 19, 2014 17:16
|
|
|
Leif. posted:Just thinking as far as towed artillery is concerned, you might be able to ghetto implement it with making them functionally infantry that move at a speed of 1 outside their transports. While we're at it, can we add the USSR's towed anti-tank guns too, because they were still using a bunch of those in 1990.
|
|
#
?
May 19, 2014 17:18
|
|
|
Chantilly Say posted:Infantry are already vehicles anyway as I understand it, so there's even less impediment than that. What's the aspect/tag/whatever that makes infantry immune to AP-only weapons?
|
|
#
?
May 19, 2014 17:19
|
|
|
The fact that they have no armor I think. ninja edit: wait that obviously can't be it
|
|
#
?
May 19, 2014 17:40
|
|
|
|
| # ? Jun 2, 2024 06:51 |
|
|
While we on the subject, what's the maths for HE only weapons damaging things with armour, is it even possible? Can machineguns attack armoured helos?
|
|
#
?
May 19, 2014 18:11
|
|
