export module as XML

I’ve got an issue where I need to find all the places that are listening for a particular keystroke. There’s no way that I can see to do that in the current interface.

Has anyone build a module → XML exporter that exports the entire module as XML? This would allow me to search the XML to find all the places that trigger on the keystroke so I can find them all.

Thanks!
Ken

On Jul 18, 2010, at 10:40 PM, fil512 wrote:

I’ve got an issue where I need to find all the places that are
listening
for a particular keystroke. There’s no way that I can see to do
that in
the current interface.

Has anyone build a module → XML exporter that exports the entire
module
as XML? This would allow me to search the XML to find all the places
that trigger on the keystroke so I can find them all.

I think you could try unzipping the module file and looking at the
build file in the resulting directory. That should get you what you
want. The build file is, however, not intended to be manually edited.

Thus spake fil512:

I’ve got an issue where I need to find all the places that are listening
for a particular keystroke. There’s no way that I can see to do that in
the current interface.

Has anyone build a module → XML exporter that exports the entire module
as XML? This would allow me to search the XML to find all the places
that trigger on the keystroke so I can find them all.

Thanks!
Ken

The buildfile you’ll find in a module is technically XML. I say
technically becuase it isn’t really human-readable. One of my long-term
goals is to switch us over to something which is human-readable, so that
these things can be more easily edited by hand when the need arises.


J.

To a certain extent it is human readable, and I’ve done just what you
describe. The trick is to find out what the keystroke looks like in the
buildfile within the .vmod archive file. Once you figure out what that
stroke looks like (often a couple of numbers), you can to a text search for
it. Usually, you can read something that comes before it in the buildfile
that indicates what component the stroke is located in.

However, strokes are indicated in the buildfile for a lot of different
things. Triggers, reports, restrict commands, etc…

Good luck.

  • michael.

On 19 July 2010 05:56, Joel Uckelman uckelman@nomic.net wrote:

Thus spake fil512:

I’ve got an issue where I need to find all the places that are listening
for a particular keystroke. There’s no way that I can see to do that in
the current interface.

Has anyone build a module → XML exporter that exports the entire module
as XML? This would allow me to search the XML to find all the places
that trigger on the keystroke so I can find them all.

Thanks!
Ken

The buildfile you’ll find in a module is technically XML. I say
technically becuase it isn’t really human-readable. One of my long-term
goals is to switch us over to something which is human-readable, so that
these things can be more easily edited by hand when the need arises.


J.

To a certain extent it is human readable, and I’ve done just what you describe. The trick is to find out what the keystroke looks like in the buildfile within the .vmod archive file.� Once you figure out what that stroke looks like (often a couple of numbers), you can to a text search for it.� Usually, you can read something that comes before it in the buildfile that indicates what component the stroke is located in.


However, strokes are indicated in the buildfile for a lot of different things.� Triggers, reports, restrict commands, etc…

Good luck.

- michael.

On 19 July 2010 05:56, Joel Uckelman <uckelman@nomic.net> wrote:

Thus spake fil512:
> I've got an issue where I need to find all the places that are listening
> for a particular keystroke. �There's no way that I can see to do that in
> the current interface.
>
> Has anyone build a module -> XML exporter that exports the entire module
> as XML? �This would allow me to search the XML to find all the places
> that trigger on the keystroke so I can find them all.
>
> Thanks!
> Ken
>

The buildfile you'll find in a module is technically XML. I say
*technically* becuase it isn't really human-readable. One of my long-term
goals is to switch us over to something which is human-readable, so that
these things can be more easily edited by hand when the need arises.

--
J.

FYI I wrote a tool that solves this problem. See my post titled “Introducing Vassal Module Analyzer”.