Riding Unit Terrain and Feature Combat Modifiers Project

[Thunderbrd]

Some general guidelines were suggested recently regarding differing types of riding units and combat modifiers they should be receiving in various terrains and features.

When looking at this a little more deeply, thinking I'd be able to easily implement these suggestions, it occurred to me that without a thorough review on the subject we will be revisiting it repeatedly. We should also be keeping a record of the current modifiers assigned so they can be kept aligned on any new units as well.

So I've started a Spreadsheet to help track these. I will probably need to add Attack and Defense columns for each feature and terrain as well - at the moment I've only laid down a structure for overall combat modifiers. Movement modifiers may be noteworthy on this document as well.

Now... the first thing I suspect we should do here is fill in what modifiers are already established. Then note what should be adjusted and to what values they should be adjusted to.

Then of course it can be rapidly inserted into the xml.

However...

Before proceeding with this I would like to point out a few things.
1) These are the kind of tag implementations that are very difficult to keep from overloading help hovers.
2) These kind of implementations, while cool when very well thought out, are often overlooked by players who see little more than mindblowing complexity in these factors.
3) There's a lot of terrains and features (particularly) that are very similar in nature and make it pretty much an automatic thing - if one type of feature is selected for a modifier, it by default means all the other types in the similar vein must also be given those modifiers - example: Forest Attack modifiers should also apply to Ancient Forest and New Forest.

So perhaps I should start working on the Generic Category class project and use it here to group some features and terrain types (flatlands as a category for example) and give our units modifiers by more sweeping categories of features and terrains (plots would pick up whatever categories its features and terrains would have so categories can be more generically referred to for establishing modifiers.)

With this in mind, should we go beyond simply using this document to record what we currently have on these units until the categories are established?

Note: Generic Categories will allow us to define any category we wish and include any type of game object into those categories which then allows us to establish tags that act on categories as a whole. I know this may at first not sound very valuable but we've run up against many matters where it would be - this being one of them.

I've been long planning to generate a Generic Category mechanism so perhaps the time has come. It shouldn't be too great a project to setup the basics - and then would gradually grow in use from there.

Anyhow, the first step here for this project is to record what modifiers are already ON these units. Is anyone who appreciates data management and wishing to help with the development of the mod up to the task of assisting in this regard?

The second step the team can jump on now... discuss suggested plot based combat modifiers for these units here.

 

[Rwn]

Anyhow, the first step here for this project is to record what modifiers are already ON these units. Is anyone who appreciates data management and wishing to help with the development of the mod up to the task of assisting in this regard?

That looks like something I can do I'll have to look and understand where and how the modifiers are applied from the xml right now, I'll let you know if I have any trouble.

I also saw you had two empty "Full list" tabs for the units; I'll try to fill those too - after toying a lot with the building files, I'm much more comfortable now with extracting data from the xml than during my first attempts (where I had to work one column at a time).

 

[Thunderbrd]

That looks like something I can do I'll have to look and understand where and how the modifiers are applied from the xml right now, I'll let you know if I have any trouble.

I also saw you had two empty "Full list" tabs for the units; I'll try to fill those too - after toying a lot with the building files, I'm much more comfortable now with extracting data from the xml than during my first attempts (where I had to work one column at a time).

Yeah, that was initially planned to be the 'master doc' but even the list itself has become a bit outdated. If filled out and kept up on it would be an amazingly awesome tool to use from here on!

Thanks for the offer of assistance!

 

[Rwn]

So, I tried to copy the data directly into the Google documents spreadsheet, but with a limitation at 50000 char, it would have been too long; not possible to directly upload the file either, so here it attached the current full unit database.

Again there was the issue of duplicates I wasn't sure how to handle properly; what I did when I found duplicates was to keep the most "filled in" entry and fill potentially empty tags (0/NONE are not considered empty) with what was in the duplicates (with priority to the highest duplicate). The duplicates, which were also filled the same way by their smaller duplicates, are at the end of the file for reference - the first column in the file gives the rank each duplicate has in term of length (0 if there's no duplicate, 1 if it's the largest entry for units with the same <Type>, 2 for the 2nd largest entry, etc.).

I also filled the text name, in the rare occurences I couldn't find it, I replaced it with <Type>

As with buildings, I've noticed several oddities in the syntax for certain units, I'll post that later on.

I really hope that it will be useful, it was quite a pain to actually get that between memory issues from such a large amount of data and syntax oddities such as several units with no <Class> that messed up the extraction...

 

[Thunderbrd]

It looks like it will be extremely useful, yes. THANK YOU!

Keeping it updated might be difficult but I'll try.

I wondered if there would be a problem with porting onto the web docs but I think there's a way it can be done - many pages of units rather than trying to get so many on only one. Would take a long time - you can only copy in so much at a time and it enforces some more patience at times. Might even need more than one document (not just page) to include them all online, which is fine too, particularly if divided up somehow. I'll give this some thought but for now what you've provided is immensely helpful!

Unitcombats can refer to the Unitcombat document but having something to show what's actually ON units as opposed to what SHOULD be (or what might be outdated) will be helpful for comparison's sake. But the way that field works out I think I'll have to let it go un-updated by hand when adjustments are made and let those go onto the unitcombat document.

About those duplicates - almost all are modular edits to the core definitions and where they have values those values would supercede or add to (depending on the type of tag) the core definition. Again, yes this makes this kind of data compilation a royal pain in the butt.

From here it would take a little hand effort to smooth out the details I think but we're pretty much where we'd need to be with it. Maybe better not to share online on a google doc due to limitations there (and processing speed sucks) but keeping this doc in a downloadable status and updated is going to be interesting. (I immediately ported this into Excel btw - I'm impressed at how easily this works from text to excel... is it a 'type' of text format that makes this possible?)

I do believe I can think up a way to make the file more shareable... lemme give it some consideration.

 

[Thunderbrd]

After some further consideration, it would be good if all duplicates had their own lines in this document - not a bad thing to see exactly how the modular versions adjust things.

Is there any way to get the file path from Assets on as a field on these easily or would that be a really huge added 'thing'. From what you explained about your methods elsewhere I'm thinking it'd be too difficult to expect it to be done so I assume that'll be your answer but if you have some neat trick to make that easy, let me know.

 

[Rwn]

From here it would take a little hand effort to smooth out the details I think but we're pretty much where we'd need to be with it. Maybe better not to share online on a google doc due to limitations there (and processing speed sucks) but keeping this doc in a downloadable status and updated is going to be interesting. (I immediately ported this into Excel btw - I'm impressed at how easily this works from text to excel... is it a 'type' of text format that makes this possible?)

Just txt format with cells delimited by tabs; tabs aren't used in the cells here.
By the way, a small detail that might be good to know: when there are different value for a given <tag>, they all appear in one cell and are separated by exactly this pattern " ; " (space - semi-colon - space). This pattern does not appear in the original file, so when you see it, it always means that there are different tag values.

After some further consideration, it would be good if all duplicates had their own lines in this document - not a bad thing to see exactly how the modular versions adjust things.

Is there any way to get the file path from Assets on as a field on these easily or would that be a really huge added 'thing'. From what you explained about your methods elsewhere I'm thinking it'd be too difficult to expect it to be done so I assume that'll be your answer but if you have some neat trick to make that easy, let me know.

You already have all the duplicates with their own line (all those with 2 or more in the first column), though admittedly they are already a bit processed as described above; I'll just put back the "unmodified" duplicates.

To add the file path from Assets... I'll look for a way, but honestly I don't see an easy way to do it right now. I'll look how many files there are, if there aren't too many I'll try to do it semi-automatically - manually copy the filepath then try to sort things out from there, though I had to sort the items at some point in the process so I don't know how it'll turn out.

 

[Rwn]

Keeping it updated might be difficult but I'll try.

Actually, what I *think* I can do is to find a way to generate the xml file based on the Excel table, so that you could modify values directly in the spreadsheet. This would mean that the actual up-to-date version would be the Excel file, from which anyone could regenerate the xml.
Of course, this means that all future changes (as well as the recent changes done since the xml version I've used to build this file, SVN 7262 I think) would have to be done through this spreadsheet since reversedly the spreadsheet cannot automatically be updated based on the xml file - though it should be possible to only generate the xml code for the units you're interested in.
As a side benefit, auto-generating the xml would skip all the empty tags, which I understood from Dancing Hoskuld could slow down the the loading time.

But, in order to avoid building a tool that wouldn't ultimately be used, I'd like to know first if that would be useful given the above limitation.

 

[Faustmouse]

Actually, what I *think* I can do is to find a way to generate the xml file based on the Excel table, so that you could modify values directly in the spreadsheet. This would mean that the actual up-to-date version would be the Excel file, from which anyone could regenerate the xml.
Of course, this means that all future changes (as well as the recent changes done since the xml version I've used to build this file, SVN 7262 I think) would have to be done through this spreadsheet since reversedly the spreadsheet cannot automatically be updated based on the xml file - though it should be possible to only generate the xml code for the units you're interested in.
As a side benefit, auto-generating the xml would skip all the empty tags, which I understood from Dancing Hoskuld could slow down the the loading time.

But, in order to avoid building a tool that wouldn't ultimately be used, I'd like to know first if that would be useful given the above limitation.

I tried that for buildings a while ago and failed, but I have no idea about programming. Actually, it wasn't a fail, if the input was within it's very limited boarders then the outcome was bugfree and aceptable for most tags.

But having this directly from spreadsheet would be very usefull for units and buildings (and probably other routine things like resources) that mostly take time but aren't hart to do.

 

[Rwn]

To add the file path from Assets... I'll look for a way, but honestly I don't see an easy way to do it right now. I'll look how many files there are, if there aren't too many I'll try to do it semi-automatically - manually copy the filepath then try to sort things out from there, though I had to sort the items at some point in the process so I don't know how it'll turn out.

Well, I looked into it, but couldn't find a way to do it reliably and with at least some degree of automation, so I've given up. If one day I have the courage to rebuild the whole unit database I'll try to include it.

Still, I've put in the other topic the unit list with (unprocessed) duplicates, as well as buildings based on the database I built several days ago.

 

[Thunderbrd]

Yeah, no worries. I figured it would be less than easy enough to make worthwhile.

Given the downsides you were mentioning about the process to make it possible to update from the excell sheet to the xml I would be wary of going down that road. It seems cool but I can see some possible problems on a really epic scale coming of it and I don't know that we'd want such a setback from an effort to move forward y'know? Nimek was developing an input tool and was right around the corner from having it really firmly well developed - I'm wondering if he totally gave up or if he just got the idea that it was no longer to be helpful or got frustrated that myself and others didn't give his tool much testing at the current state of development its at(I feel a bit guilty about that...)

But I'd be interested to see his take on your efforts here and maybe you guys can bang your heads together and come up with something that would be REALLY helpful for streamlining xml input.