Author Topic: MWLLgroupConfig v1.5.4 (MWLL 0.7.1) - edit weapon groups  (Read 16026 times)

0 Members and 1 Guest are viewing this topic.

Offline Az

  • MechWarrior
  • **
  • Posts: 274
  • l33tp0intz: +49/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0
« Reply #30 on: October 12, 2011, 02:31:39 AM »
I've made some progress.

Issue #1: weapon order => solved. I double-checked my output against MWLLgroupConfig 1.0, I found only one mistake and it's not on my side ;). The TAG is missing from the Puma A (did not check in-game but the wiki agrees with me).
Issue #2: weapon names => partially solved. I managed to get the HUD names from each weapon's XML, but it doesn't save a lot of space to replace Clan_ER_Medium_Beam_Laser with Clan ER Medium Beam Laser. So if screen space is an issue it would still need to be hard-coded.
Issue #3: weapon location => that's my program for tomorrow.

I'll use the MkII as a sample again to show the current state of the script:
Code: [Select]
[CL_MKII_Mech]
name=Madcat MKII
type=Mech
category=AssaultMechs
armor=Mech/Normal
Prime=Clan LRM10,Clan LRM10,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan Gauss Rifle,Clan Gauss Rifle
A=Clan LBX10,Clan LBX10,Clan LBX20,Clan LBX20
B=Clan Dual SSRM6,Clan Dual SSRM6,Clan UAC20,Clan UAC20
C=ArrowIV,ArrowIV,Clan ER Large Beam Laser,Clan ER Large Beam Laser
D=ATM12,ATM12,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan ER Large Beam Laser,Clan ER Large Beam Laser
E=ATM9,ATM9,Clan UAC5,Clan UAC5,Clan UAC5,Clan UAC5

Some explanations about that type/category/armor thing. That's three slightly different ways of categorizing assets, if you wish to implement that suggestion. What I called type is the name of an internal node for movement parameters. I read the category from MechLists.lua but you can find the same values from prices.txt (dumpMwllPrices command). It follow exactly the categories of the buy menu. Armour types... well, I don't know what it's used for, but it could be used for categorization too.

The different options are:
type = Mech / Tank / Hovercraft / LightVTOL / Aerospace
category = LightMechs / MediumMechs / HeavyMechs / AssaultMechs / Tracked / Hovercraft / APC / VTOL / Aerospace
armor = Mech / Tracked / VTOL / Aerospace

You pick one (if any).

By the way I'm not sure a IS/Clan split would be relevant. The buy menus seems to be very roughly sorted alphabetically by the "technical" name, CL_* assets first then IS_* ones. If you can sort the tree entries by a different value than the display string, it's probably a good solution. I don't know GUI programming though, it may not be trivial (if it's doable, fix that Prime variant listed last too :p).


Reading the weapon XMLs for the names reminded me of a nifty little fact: they also store the default group configuration for each weapon. So if you want to code a way to reset the weapon groups of an asset, it's possible!

The data is given like this:
Code: (Clan_DualStreakSRM6.xml) [Select]
  <weaponGroupData>
    <param name="group1Inactive" value="1"/>
    <param name="group2Inactive" value="1"/>
    <param name="group3Inactive" value="0"/>
    <param name="group4Inactive" value="1"/>
    <param name="group5Inactive" value="1"/>
    <param name="group6Inactive" value="1"/>

    <param name="delayBeforeRipple" value="200"/>
    <param name="weaponName" value="Clan Dual SSRM6"/>
  </weaponGroupData>

I have no idea however how to report that in a convenient way. If you want to use that data, you tell me in what format.


Now, a little bug I noticed in your application: when you select an asset with the keyboard, the right-hand panel is not updated until Enter is pressed. Not a big deal you'll say, but it has a strange consequence.
For example, select the Atlas A with the mouse, then use the arrow keys to select the Awesome B. Do not press Enter. The Atlas A's groups are displayed and you can edit them. Now select the Atlas A with the mouse again: the changes will revert. Select the Awesome B with the mouse: that's the groups you were actually modifying!
This might lead to interesting results on assets with different counts of weapons.

Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0
« Reply #31 on: October 12, 2011, 08:19:25 AM »
The TAG is missing from the Puma A (did not check in-game but the wiki agrees with me).
There is no TAG on the Puma A, despite the Wiki saying so. If you found one, then maybe you found a bug (some developer might have forgotten to update the asset in whatever file you are looking at).

Issue #2: weapon names => partially solved. I managed to get the HUD names from each weapon's XML, but it doesn't save a lot of space to replace Clan_ER_Medium_Beam_Laser with Clan ER Medium Beam Laser. So if screen space is an issue it would still need to be hard-coded.
Technically space is of no concern. But in my opinion it looks a little bit strange with these extremely long names. Just leave it as it is (Clan_ER_Medium_Beam_Laser or Clan ER Medium Beam Laser), the rest can be done while interpreting the .ini.

I'll use the MkII as a sample again to show the current state of the script
If you find any additional information for the assets, just include it. Maybe there comes a point where it would be useful to find it inside the .ini.

By the way I'm not sure a IS/Clan split would be relevant.
As I said: For somebody not knowing which asset belongs where this only causes additional trouble. From the opposite point of view it is only a slight visual inconvenience - so I will not split the data.

If you can sort the tree entries by a different value than the display string, it's probably a good solution.
I would have done that by now if I knew how to do it. There is probably an easy way, but it would take some time for me to find it.

Code: (Clan_DualStreakSRM6.xml) [Select]
  <weaponGroupData>
    <param name="group1Inactive" value="1"/>
    <param name="group2Inactive" value="1"/>
    <param name="group3Inactive" value="0"/>
    <param name="group4Inactive" value="1"/>
    <param name="group5Inactive" value="1"/>
    <param name="group6Inactive" value="1"/>

    <param name="delayBeforeRipple" value="200"/>
    <param name="weaponName" value="Clan Dual SSRM6"/>
  </weaponGroupData>

I have no idea however how to report that in a convenient way. If you want to use that data, you tell me in what format.
The format in my program right now is very simple: An array of integers/bits for each weapon. "Weapon_0=1,1,0,1,1,1" (a "1" refers to a weapon being active in a group here) would do the job, I guess. Using the names of the weapons might be problematic since some assets use the same weapon-type more than once.
If, however, these standards are weapon-specific instead of asset-specific, they would not really fit into the existing .ini (unless you add a substructure like [assets/CL_MKII_Mech], [defaults], etc.). In that case just use the weapons name (would be nice if it was the same as before in the Clan_ER_Medium_Beam_Laser example, so the names can be easily matched) and, if possible, the list of bits.
This information would come in very handy. At the moment every asset that can not be found in the attributes.xml will just get a weapon-setup with all the weapons deactivated in every group.

Now, a little bug I noticed in your application: when you select an asset with the keyboard, the right-hand panel is not updated until Enter is pressed. Not a big deal you'll say, but it has a strange consequence.
For example, select the Atlas A with the mouse, then use the arrow keys to select the Awesome B. Do not press Enter. The Atlas A's groups are displayed and you can edit them. Now select the Atlas A with the mouse again: the changes will revert. Select the Awesome B with the mouse: that's the groups you were actually modifying!
I should have anticipated that bug. Had a similar problem once with a different program, it is fixed now (I will upload a new version soon).

One more thing: Maybe you could add some handy subgroups to the .ini-file. Like this:
Code: [Select]
[CL_MKII_Mech]
name=Madcat MKII
type=Mech
category=AssaultMechs
armor=Mech/Normal
[CL_MKII_Mech/variants]
Prime=Clan LRM10,Clan LRM10,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan Gauss Rifle,Clan Gauss Rifle
A=Clan LBX10,Clan LBX10,Clan LBX20,Clan LBX20
B=Clan Dual SSRM6,Clan Dual SSRM6,Clan UAC20,Clan UAC20
C=ArrowIV,ArrowIV,Clan ER Large Beam Laser,Clan ER Large Beam Laser
D=ATM12,ATM12,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan ER Large Beam Laser,Clan ER Large Beam Laser
E=ATM9,ATM9,Clan UAC5,Clan UAC5,Clan UAC5,Clan UAC5
[CL_MKII_Mech/Prime/defaults]
Weapon_0=1,1,0,1,1,1
...

I am not sure how to include the default-settings in the .ini - if you have any idea, just make up some consistent name for a subgroup and do it however you like.

Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0
« Reply #32 on: October 12, 2011, 10:35:08 AM »
I forgot something before:
If you can add the subgroups I mentioned and get to a point where you think "That's it!", then please let me know of your current .ini format by posting some dummy file with one or two assets here. I already wrote a new function to read the XML and am awaiting a somewhat definite format for the .ini so I can add the ini-function, too. From there on I could at least go on with my part of the work whenever I want to.

Offline Az

  • MechWarrior
  • **
  • Posts: 274
  • l33tp0intz: +49/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0
« Reply #33 on: October 12, 2011, 02:20:09 PM »
I caught a cold and my brain hurts, especially if I try to use it. So don't expect much progress for today :-\.

I just wanted to say you define the definite .ini format! Use whatever format is convenient for you, I'll just go along. Parsing & reporting is what Perl is built for.

The samples I posted give you all the data I can currently gather. Tonnage and Class are for mechs only, so is torso rotation obviously. Speed is experimental, I can only read it for ASF and Mechs, and even then it's not always accurate (but I think I know why). No hope of ever deciphering it for tanks however. In the latest script version I also read the "base armor" before each variant's value.

But all that stuff doesn't really fit the scope of your program. If you don't want to split thing into categories, the only thing you need besides the loadouts is the asset's display name. But I'm not the one who defines your application's scope, so you decide the format and I'll fill it. And if you think of something fancy it doesn't hurt to ask.

I'll answer your other post when my nose stops dripping on the keyboard (... figuratively speaking, it's not that bad).

Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0
« Reply #34 on: October 12, 2011, 02:51:52 PM »
Sorry to hear about that.

Without knowing what kind of data you can come up with or how exactly the default-configurations work (per weapon, per 'Mech or even something crazy), I can't really tell you how to put your information into a file. The examples you posted earlier look pretty good, but sub-groups would be very handy for me (see the long post). Putting associated data into convenient chunks would decrease the work I have to put into parsing the file.

Until I see a complete example (or at least a close to reality draft) I really can't do too much.

The fancy stuff I thought of would be to dedicate a small part of the window to asset-specific information. If that gets added, I also would build in an option to show a small picture of each asset - probably unnecessary for most people, but it might be handy for starters.

By the way: Separating the entries by type would be perfectly possible, if your file includes the info ;). Maybe I add an alternate view where you can separate them by Clan/IS, but that would have to wait for everything else to be finished.

Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #35 on: October 13, 2011, 09:22:39 AM »
I uploaded a new version that fixes the bug you mentioned, Az. Hopefully I did not introduce new bugs, I started adding some new (and unused) functions to prepare for the new .ini format.

Offline Az

  • MechWarrior
  • **
  • Posts: 274
  • l33tp0intz: +49/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #36 on: October 14, 2011, 01:52:59 AM »
Without knowing what kind of data you can come up with or how exactly the default-configurations work (per weapon, per 'Mech or even something crazy), I can't really tell you how to put your information into a file. The examples you posted earlier look pretty good, but sub-groups would be very handy for me (see the long post). Putting associated data into convenient chunks would decrease the work I have to put into parsing the file.

I'm sorry I wasn't able to express myself clearly enough, I though I answered that in my previous post. I'll rephrase in the hope the meaning will get across this time. My English isn't perfect but it will have to do as my German is absolutely terrible. Actually there's nothing left of my german lessons — not even the swear words and pick up lines. That's how bad it is.

The data I can come up with can be found in the first Code blocks of both this post and this one. That's actual output from my scripts. You also have to take into account the limitations I stated in my previous post.

The way I present that data in the .ini, however, is pretty much entirely up to you. Unlike C++, Perl is built for parsing so let's play its strength! Parsing the data can be tricky, and choosing the right structure to store it can be too. When that's done, modifying the output and tailoring it for you needs is very easy.


About the default configuration, I though the XML excerpt was self-explanatory. It's a per-weapon property. I just have to tie it with the weapon list and we've got the whole default configuration of a variant. Your proposal with the subgroups can be done easily. But I (probably) can do something crazy too, something binary even if that's convenient for you!
No, actually, let's avoid binary data; ini files should be user-editable. And I'm thinking: in this case it's not even "should", but "must". If your program repairs corrupted configurations (when the weapon count is wrong) by restoring the default settings, then modifying those settings becomes an interesting feature.

Let's hope this cleared any misunderstanding.


In other news: I've got bad news :-\
I had pretty high hopes of being able to find a weapon's location using the XMLs, since I was able to tell on which arm were the weapons by reading the Loki's file. It turns out the data is incomplete, and there's nothing about the torso weapons. I can locate each weapon on a Cougar, a few slots have no location data but they're not used. On the Shiva however, only the missile slots can be located. I don't understand, either the data is needed for the asset or it's not. So far it looks quite random, it's strange. My best guess is that the XML's data is redundant because it's already in the model file or something. Anyway, there's nothing I can do if the data is unreliable...
It's entirely possible the data is there and I just missed it. But in this case, it's not just non-obvious, it's heavily obscured. So I'll look at it again, hopefully in a cleverer way, but don't hold your breath.
I'm pretty gutted to find this out only now, but at least the default config thing should make the whole effort worthwhile.


Now, the long post.

There is no TAG on the Puma A, despite the Wiki saying so. If you found one, then maybe you found a bug (some developer might have forgotten to update the asset in whatever file you are looking at).

Thanks for checking that for me. I won't lie, I'm a bit upset I got it wrong :).
I know what caused the mistake. I'm reading the same file the game reads when it builds assets, it's not an outdated file. But I might interpret the data differently, it's "reverse engineering" after all, I don't know what to expect.
What is happening here is that a weapon slot is defined twice. The game only keeps the last value, my script and the one used for the wiki (Cygma's, I believe) just list all the weapons they find. I'll find a way to fix this.
It's a similar issue for the Cougar C. When an asset has C3 its idRadar value is "C3Radar". On the Cougar C it is "". Our scripts interpret that as "no C3" and see nothing wrong, the game just says "OK, no radar then".
The funny thing is that I also compute the cost of variants and check it against the values given by prices.txt, to catch that kind of errors. But the TAG happens to be buggy and has no cost... See here.
Hmm, I re-read my topic as I linked it, and the TAG has been fixed... It could mean the Puma A pays for it when it shouldn't. I'll check this thoroughly and report it if needed.


Technically space is of no concern. But in my opinion it looks a little bit strange with these extremely long names. Just leave it as it is (Clan_ER_Medium_Beam_Laser or Clan ER Medium Beam Laser), the rest can be done while interpreting the .ini.

If you want shorter names then we'll have to hardcode it. I should be the one doing it, not that I really want to type all that stuff ;) but it would be easier to add and modify weapon names in the script than in C++ code. Especially in its compiled form.


If you find any additional information for the assets, just include it. Maybe there comes a point where it would be useful to find it inside the .ini.
You never looked at the XMLs, did you ? I assure you, there is such thing as "too much information" ;). You don't want me to report every little thing in there, and I certainly don't want to try.
I showed you everything I can read. There is probably some more useful data that can be read, but I don't necessarily know it yet (like the default groups). If you think of some information you'd like to have, I can try to find it. But I warn you right now: I can't generate pictures for every asset :P.

The format in my program right now is very simple: An array of integers/bits for each weapon. "Weapon_0=1,1,0,1,1,1" (a "1" refers to a weapon being active in a group here) would do the job, I guess. Using the names of the weapons might be problematic since some assets use the same weapon-type more than once.
If, however, these standards are weapon-specific instead of asset-specific, they would not really fit into the existing .ini (unless you add a substructure like [assets/CL_MKII_Mech], [defaults], etc.). In that case just use the weapons name (would be nice if it was the same as before in the Clan_ER_Medium_Beam_Laser example, so the names can be easily matched) and, if possible, the list of bits.
This information would come in very handy. At the moment every asset that can not be found in the attributes.xml will just get a weapon-setup with all the weapons deactivated in every group.

I guess I pretty much covered this already. I could report the default groups for each weapon, and let you reconstruct the variant configuration, but this leads to all kind of problems and the only benefit is a shorter ini file.


One more thing: Maybe you could add some handy subgroups to the .ini-file. Like this:
Code: [Select]
[CL_MKII_Mech]
name=Madcat MKII
type=Mech
category=AssaultMechs
armor=Mech/Normal
[CL_MKII_Mech/variants]
Prime=Clan LRM10,Clan LRM10,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan Gauss Rifle,Clan Gauss Rifle
A=Clan LBX10,Clan LBX10,Clan LBX20,Clan LBX20
B=Clan Dual SSRM6,Clan Dual SSRM6,Clan UAC20,Clan UAC20
C=ArrowIV,ArrowIV,Clan ER Large Beam Laser,Clan ER Large Beam Laser
D=ATM12,ATM12,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan Heavy Small Laser,Clan ER Large Beam Laser,Clan ER Large Beam Laser
E=ATM9,ATM9,Clan UAC5,Clan UAC5,Clan UAC5,Clan UAC5
[CL_MKII_Mech/Prime/defaults]
Weapon_0=1,1,0,1,1,1
...

I am not sure how to include the default-settings in the .ini - if you have any idea, just make up some consistent name for a subgroup and do it however you like.

I don't have any idea, so I'll just use your suggestion. I still can't afford a headache, so I won't try to tackle the big issues just yet, but since you seem to need something to work with I could generate a full ini. That shouldn't take too long, if that weaponGroupData stuff is willing to cooperate.

Edit:
There, it's done. It struggled a bit but I got the upper hand.
The code is ugly though, I cut a lot of corners, and in a nasty way. The Puma A isn't fixed and I removed the APC because the script choked on it and I couldn't be bothered to fix it. It has no variant and while null scalars and arrays are OK, null references aren't so well received...
I didn't double-check anything but the output seemed correct.
I also added the output of my original script's latest version , in case you're curious.

By the way, one of my test assets was the Shiva, and I just noticed now that the IS Shiva A has four Clan UAC10. WTF!? (Yes, I know — where have I been?)

[attachment deleted by admin]
« Last Edit: October 14, 2011, 04:22:45 AM by Az »

Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #37 on: October 14, 2011, 07:35:29 AM »
The way I present that data in the .ini, however, is pretty much entirely up to you. Unlike C++, Perl is built for parsing so let's play its strength! Parsing the data can be tricky, and choosing the right structure to store it can be too. When that's done, modifying the output and tailoring it for you needs is very easy.
My own function to read out the .ini is not yet written, therefore I am still flexible ;).

About the default configuration, I though the XML excerpt was self-explanatory. It's a per-weapon property. I just have to tie it with the weapon list and we've got the whole default configuration of a variant. Your proposal with the subgroups can be done easily. But I (probably) can do something crazy too, something binary even if that's convenient for you!
Nothing binary needed, C should be powerful enough to convert your data into anything I need.

<no information about position of weapons>
Since these information would be included in the the weapons names (as it is now), this is not at all necessary to create an .ini or write my program. Just go on, the positions will have to be added by hand for now.

If you want shorter names then we'll have to hardcode it. I should be the one doing it, not that I really want to type all that stuff ;) but it would be easier to add and modify weapon names in the script than in C++ code. Especially in its compiled form.
Well, I would like to have as much work as possible on my side, so I do not have to come back to you every time I want to change something. I can use the long names, it is more understandable for newer players anyway - it took me quite some time to learn all the abbreviations. The window ill be 50 pixels wider then.

You don't want me to report every little thing in there, and I certainly don't want to try.
I showed you everything I can read. There is probably some more useful data that can be read, but I don't necessarily know it yet (like the default groups). If you think of some information you'd like to have, I can try to find it. But I warn you right now: I can't generate pictures for every asset :P.
Ok. You decide what additional information will be shown/useful/easy to get. Something like price, maybe weight, whatever you consider interesting. The pictures of course will have to be taken by somebody else, I will just do it like I did it with the .ini: Whoever wants pictures of a specific asset, can add them himself. I will deliver a good portion on my own, however.

I could report the default groups for each weapon, and let you reconstruct the variant configuration, but this leads to all kind of problems and the only benefit is a shorter ini file.
You are right. But with all the information there, maybe it should be as short and understandable as possible? I do not want this .ini to look like any of the MWLL-xmls :P.
I would prefer an own section for the default settings, although it would mean more work on my part. "Name=0,0,1,0,0,0" (1 = active) would be ok. It would be a little bit redundant to create this for every asset. Ah, screw it. It looks nice like it is now.

The code is ugly though, I cut a lot of corners, and in a nasty way. The Puma A isn't fixed and I removed the APC because the script choked on it and I couldn't be bothered to fix it. It has no variant and while null scalars and arrays are OK, null references aren't so well received...
The file looks very good so far. The default configurations take up a lot of space, however. Maybe a per weapon-approach would be the better choice? :-\
I will have some time to work on the program later today, hopefully it will go as planned and I will be able to finish the program in only a couple of hours.
But that stuff never goes as planned, does it?

By the way, one of my test assets was the Shiva, and I just noticed now that the IS Shiva A has four Clan UAC10. WTF!? (Yes, I know — where have I been?)
Stolen goodies, I guess.
I learned a lot by adding many of the weapons to the MWLLassets.ini, too. There are quite some strange assets out there!

Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #38 on: October 15, 2011, 12:28:59 AM »
I did not have the time to do what I intended to do. But I did a little part of coding and now have a request: Could you change "[CL_MKII_Mech/Prime/defaults]" to "[CL_MKII_Mech/defaults/Prime]" for all the assets? That would be a lot easier to deal with for me.

Offline Az

  • MechWarrior
  • **
  • Posts: 274
  • l33tp0intz: +49/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #39 on: October 15, 2011, 03:17:50 AM »
Since these information would be included in the the weapons names (as it is now), this is not at all necessary to create an .ini or write my program. Just go on, the positions will have to be added by hand for now.

I'll be frank, I have no idea what you meant in that italicized part. But yes, I'll postpone the search for the weapons' locations until the rest of the script is working as intended.


Well, I would like to have as much work as possible on my side, so I do not have to come back to you every time I want to change something. I can use the long names, it is more understandable for newer players anyway - it took me quite some time to learn all the abbreviations. The window ill be 50 pixels wider then.

It's not really "long names", it's the names as they appear on the HUD. Some are shortened, some are not... The example I gave you (Clan_ER_Medium_Beam_Laser) is I believe the longest name, and it happens to not be shortened at all. That's an extreme. So OK, we'll keep these names.


Ok. You decide what additional information will be shown/useful/easy to get. Something like price, maybe weight, whatever you consider interesting.

No no no! You decide what information you want!
I'll give you my opinion: this program is about weapon configuration, no need to reprint the wiki page for each asset.
The only necessary information for me is the asset name, and maybe one of the three possible category variables. That's if you want a way to split them (maybe as an option?), if you don't then just the name. Then the weapon load-outs and default groups of course.

If you want more info, then you decide which data I should include — something that's in the files I gave you (if you want something else I can look but...). Class and tonnage are only available for mechs unfortunately, but I can add it just for them.


The default configurations take up a lot of space, however. Maybe a per weapon-approach would be the better choice? :-\

Yeah it's quite long, but it won't fill anyone's disk :). I think it would be nice to have editable defaults for each variant, so I'm not too keen on a global per-weapon approach.

One solution is to write the defaults in a different file. Or we could use a more compact format. I'm thinking of something like this (Hephaestus Prime used as an example):

Code: [Select]
Weapon_0=1,0,0,0,0,0
Weapon_1=1,0,0,0,0,0
Weapon_2=0,0,0,1,0,0

= becomes =>

Prime=100000,100000,000100

That shouldn't be too hard for you to parse, and it's still user-editable, though a bit cumbersome for assets with a large number of weapons.


But that stuff never goes as planned, does it?

Tell me about it  ::). Why do you think I did such an ugly job yesterday and ended up hiding a file under the rug instead of fixing the crash it caused? ^^


I did not have the time to do what I intended to do. But I did a little part of coding and now have a request: Could you change "[CL_MKII_Mech/Prime/defaults]" to "[CL_MKII_Mech/defaults/Prime]" for all the assets? That would be a lot easier to deal with for me.

Done! I also added a [$asset/defconf] subgroup with the shorter scheme I mentioned, so you can try it.
I'm including a different, shorter version of the ini with both load-outs and defaults groups in the same subgroup. The code is much simpler and tidier on my side (I print as I read), but the legibility trade-off isn't so good after all. And I wrote both versions anyway... It also kinda assumes you have an easy way of reading the $variant and defaults/$variant values in two different passes (hm, sorry, I'm using a perl notation here, $var is a variable).

I've been lazy and fixed nothing else, I'm somewhat waiting for the ini format to settle down and I'll have a big rewrite to do. The sooner the better though because this is quickly turning into spaghetti code :D (may His noodly appendage touch you).

[attachment deleted by admin]

Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #40 on: October 15, 2011, 07:54:39 AM »
I'll be frank, I have no idea what you meant in that italicized part. But yes, I'll postpone the search for the weapons' locations until the rest of the script is working as intended.
I just meant: Positions are completely optional for the functionality of my program. They would be very handy, but the program itself would not even recognize their existence.
Another idea: Since the ELH guys already gathered all these information, would it be an option for you to just get them from the old MWLLassets.ini for now? I do not want to waste their hard work (and as I said: this kind of information comes in very handy).

No no no! You decide what information you want!
And you decide how much work you are willing to put into this. If you gave me a file containing all the information possible, I would use all of it. It is always good to have more information, and I would hate to make your effort worthless ;). As it is now, it fulfills its purpose - perfectly. So don't bother gathering any more information (except for the weapons positions, if that is at all possible) until my program is ready and we can think about extending it.
Maybe I come up with some structural changes, I am still trying to find the best way of displaying the information in the .ini. For example, it could look like this, maybe the file would be easier to understand and to extend in the future:

Code: [Select]
[CL_MKII_Mech]
name=Madcat MKII
type=Mech
category=AssaultMechs
armor=Mech/Normal
[CL_MKII_Mech/Prime]
list=Clan LRM10,Clan LRM10,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan ER Medium Beam Laser,Clan Gauss Rifle,Clan Gauss Rifle
Weapon_0=1,1,0,1,1,1
Weapon_1=...
...
[CL_MKII_Mech/A]
list=Clan LBX10,Clan LBX10,Clan LBX20,Clan LBX20
Weapon_0=...
Note: I have no idea how to include the APC in this. But since I like the concept, we have to find a way for that.
I am using C++ for this. And I have quite a lot of experience traversing any kind of files (text, images of any kind, audio, binary files, ...) with nothing but good old C. So whatever file you give me, I will be able to use it to its maximum extent. This means that I would prefer a "pretty and clean" .ini file - a random user should be able to open it up and understand it.
The sub-sections are a big help right now, they save me a lot of work. If you think you find the perfect format for the file, please let me know and I will find out whether I can work with it or not.

Yeah it's quite long, but it won't fill anyone's disk :). I think it would be nice to have editable defaults for each variant, so I'm not too keen on a global per-weapon approach.
I did not look at it from that point of view. You are perfectly right.

Code: [Select]
Weapon_0=1,0,0,0,0,0
Weapon_1=1,0,0,0,0,0
Weapon_2=0,0,0,1,0,0

= becomes =>

Prime=100000,100000,000100

That shouldn't be too hard for you to parse, and it's still user-editable, though a bit cumbersome for assets with a large number of weapons.
I prefer the two-dimensional approach (the old version, that is), it just looks better and easier to change. Let's stick to it, I think that megabyte of harddisk space should be available on a PC that can run MWLL.

I've been lazy and fixed nothing else, I'm somewhat waiting for the ini format to settle down and I'll have a big rewrite to do. The sooner the better though because this is quickly turning into spaghetti code :D (may His noodly appendage touch you).
You got a point there. Sorry to bother you again (and to potentially have wasted your time with my last request), but if you have nothing to object, use the format I wrote down in this post from now on. With the long standard-configurations and one subgroup per asset.

Thanks for your help and effort, Az. I really appreciate it - I don't like inflexible software or hardcoding stuff due to lazyness or whatever reason. So your skills come in realllllly handy.

Offline Az

  • MechWarrior
  • **
  • Posts: 274
  • l33tp0intz: +49/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #41 on: October 15, 2011, 04:37:03 PM »
No time for a full post so I'll just post my latest results (in case you feel like working on this) and edit later.

I removed a lot of code, it's much cleaner now, partly due to your suggested format (which seems obvious, retroactively). The APC doesn't crash the script any more, but I didn't solve any parsing issue (like the Puma A).

[attachment deleted by admin]

Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #42 on: October 15, 2011, 05:31:44 PM »
Thanks a lot for changing the file, looks pretty well-arranged now. The additional information is missing from the new version (category, armor and such), but I can now test the new function I wrote earlier this day.

PS: For the APC, it should look something like this:
Code: [Select]
[ALL_Apc]
name=APC
type=...
category=...
armor=...
[ALL_Apc/]
list=MGun,MGun
Weapon_0=1,0,0,0,0,0
Weapon_1=1,0,0,0,0,0
Even without any variants this should be parsable on my part.

Offline Az

  • MechWarrior
  • **
  • Posts: 274
  • l33tp0intz: +49/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #43 on: October 16, 2011, 08:12:25 PM »
I cleaned up the code a little more, it's now less than half the size of the first working version. I added some blank lines to the output for readability, sure it's even longer now but 1300 or 1500 lines... does it matter any more? I also fixed the Puma A issue (and reported the bug, it's indeed too expensive).

Another idea: Since the ELH guys already gathered all these information, would it be an option for you to just get them from the old MWLLassets.ini for now? I do not want to waste their hard work (and as I said: this kind of information comes in very handy).

Heh, that's should be possible, but rather difficult and pointless. It might be worth the effort if I was a Perl guru, which I'm not ^^. The point of a script is to gather data automatically with no or minimal intervention between versions. In this case it would be a one-shot.

The work from ELH can still be used to complete the generated ini, if I can't manage to read the locations reliably. Which I fear is likely :-\.

I looked at it again while writing this post and I'm pretty much convinced there's no way for me to determine complete and accurate locations for the weapons from the XMLs. But if automatic gathering of the locations is out of question, I might be able to pull off something semi-automatic. We'll see.


Note: I have no idea how to include the APC in this. But since I like the concept, we have to find a way for that.

Unfortunately, there's no good way of including it from my side. The weapons are stored in a totally different way. I could hard-code something like If (asset==APC) then { use completely different code written for a single asset }, but I frankly don't feel like doing so. And the APC could get variants and fall in line with the other assets, and invalidate the hard-coded exception. We know the APC parsing is broken, let's just fix the .ini manually for it and be done with it. It's no big deal.

So the issue rests entirely on your side. If you can parse that null-string variant you suggested ([ALL_Apc/]) it would be great, that probably means no special case for the APC. If it doesn't work out... then do whatever else works for you :).


I am using C++ for this. And I have quite a lot of experience traversing any kind of files (text, images of any kind, audio, binary files, ...) with nothing but good old C. So whatever file you give me, I will be able to use it to its maximum extent.

You should have told me sooner that you could parse all the XML and Lua files by yourself! And here I am, wrestling with Perl and LibXML2, when you could have done the same with a single pointer...

I kid, I kid ;)


Thanks for your help and effort, Az. I really appreciate it - I don't like inflexible software or hardcoding stuff due to lazyness or whatever reason. So your skills come in realllllly handy.

Don't mention it. I offered my help because I had both some familiarity with the mod's files and a working script. And I knew what I was signing for :).
I share your dislike of inflexible software and hardcoded stuff. The reason I never released my wiki script is mainly my reluctance to hard-code anything. But laziness... laziness is one of the three great virtues of a programmer. Unfortunately, I do not possess the other two.

Don't mention my skills either — it's really not worth mentioning. All I'm doing is script kiddie stuff, trials and lots of errors. It's partly why I chose an interpreted language over a compiled one ^^. My C/C++ is or rather was at a "Hello World" level. Maybe should I say printf("Goodbye World\n");, since Dennis Ritchie recently passed away. But no-one cares, as he sold books not phones.


Offline thEClaw

  • Star Captain
  • ***
  • Posts: 976
  • l33tp0intz: +75/-0
Re: Editing weapon-groups outside of MWLL: MWLLgroupConfig v1.0.1
« Reply #44 on: October 16, 2011, 09:48:54 PM »
I finally was able to invest some hours into the program. The Prime-variants are still shown at the lower end of the list (I can't figure out how to change that) and I have not started working on the new GUI part where additional information shall be shown (should not take more than half an hour). But other than that everything is done.

The work from ELH can still be used to complete the generated ini, if I can't manage to read the locations reliably. Which I fear is likely :-\.
That is what I mean. But I have no solid idea yet how to tackle this.

I looked at it again while writing this post and I'm pretty much convinced there's no way for me to determine complete and accurate locations for the weapons from the XMLs. But if automatic gathering of the locations is out of question, I might be able to pull off something semi-automatic. We'll see.
Ok.

We know the APC parsing is broken, let's just fix the .ini manually for it and be done with it. It's no big deal.
I have some problems with the APC at the moment, too. I can't read out its information because in the end I am unable to read the "APC/"-thing.
It is definitely not worth putting too much effort into it, after all it is only an APC.

You should have told me sooner that you could parse all the XML and Lua files by yourself! And here I am, wrestling with Perl and LibXML2, when you could have done the same with a single pointer...
I can't. I would not have done it because it would have been quite some work for me and I did not see the point in it ;).

I hate to repeat myself, but the latest file you gave me does not contain additional information. It seems you shortened your script a little bit too much.