Custom Query – Oni Community Projects

Description

sprintf does not support floats.

Description

Let's reiterate what 'dox just stated in another ticket and then add an even worse scenario to the mix, to understand where XmlTools currently stops being useful. I've been procrastinating making this ticket because it's a doozy, but really, it has to be discussed and dealt with. Keep in mind that this is not intended to minimize the work that s10k has already done, which has been very helpful. Also, s10k, please don't start hyperventilating while reading this because there may be a "simple" solution that doesn't require much work from you.

Paradox outlined a sample use case where we would need to be able to modify one part of a tag based on another part of the same tag. So, to alter the length of time (in levels) for which an autoprompt appears, we have to look for an autoprompt like:
{{{
<ONGSAutoPrompt>
<Notes>hypo</Notes>
<FirstAutopromptLevel>1</FirstAutopromptLevel>
<LastAutopromptLevel>2</LastAutopromptLevel>
<SubtitleName>autoprompt_hypo</SubtitleName>
</ONGSAutoPrompt>
}}}

according to the value of the SubtitleName tag, then modify the LastAutopromptLevel tag if we find what we're looking for. How would we normally want this to look, in a computing environment? Probably something like this:
{{{
if ONGSAutoPrompt.SubtitleName is "autoprompt_hypo" then
set LastAutopromptLevel to 2
end if
}}}

See how simple that can look with standard procedural syntax? Now technically we're missing a 'for' loop there, but we could easily just ask for XmlTools to treat 'if' statements as a request to iterate over all the named elements.

But let's take this a step further with a much-less hypothetical scenario. Let's say that I want to add glass-breaking particles to all TRAMs (because I do). Gumby actually had to write his own tool to do this for the 2009 AE because it requires a conditional syntax ''and'' variables. This mod consists of four parts:
1. The glass-breaking particle. This is the easiest part, we just include the file BINA3RAPglass_break.oni in the mod, no patching needed.
2. A list of attacks to affect. This could be based on a pattern like "*punch*", "*kick*", etc., but there will have to be a list of names or patterns. This is currently able to be handled by the AEI's file name-matching of the .oni-patch files, so we can leave that alone, although it does limit the kind of pattern-matching we can do.
3. Now we need to let Oni know that a character can create this particle. We do this by adding this to their ONCC's ONCP array this element:
{{{
<ONCPParticle>
<Name>glass_break</Name>
<Type>glass_break</Type>
<BodyPart>-1</BodyPart>
</ONCPParticle>
}}}
Just a standard @ADDTO command, here. Preferably, we only do this if this ONCPParticle has not been added already. Not sure if duplicating the listing does any harm, though, so let's move on.

4. We add the actual emission of the particle to attacks. Here's where it gets tricky. Here's the relevant part of a TRAM (Barabas' Earthquaker):
{{{
<Attack>
<Start>51</Start>
<End>55</End>
<Bones>LeftThigh LeftCalf LeftFoot RightThigh RightCalf RightFoot</Bones>
[...]
</Attack>
}}}
Notice how Barabas does damage with all his lower bones for the duration of frames 51-55. To add glass-breaking (according to how Gumby did it), we have to go to the Particles array in the TRAM, where it currently lists only the barab_wave for one foot (since it only needs to spawn that effect once), and add this:
{{{
<Particle>
<Start>51</Start>
<End>55</End>
<Bone>LeftThigh</Bone>
<Name>glass_break</Name>
</Particle>
<Particle>
<Start>51</Start>
<End>55</End>
<Bone>LeftCalf</Bone>
<Name>glass_break</Name>
</Particle>
[etc. etc.]
}}}
So let's count the ways that this isn't possible with XmlTools:
A. We need to read and save into memory the Start and End frames from the Attack, otherwise we have no idea when the glass-breaking takes place. We could just say frames 1-100, but then the character will break glass as far away as the distance of his attack's Extents before his fist/whatever gets anywhere near the glass.
B. We need to read, parse and save the list of Bones from the Attack array. Otherwise we'd have to guess which bones to add the particle to, and if we guessed wrong, a character standing near glass would break it with the wrong parts of his body. Also, we'd be generating particles unnecessarily if we added glass_break to all bones.

(Yes, we don't need to do A and B programmatically; the use of separate files for each patch allows us to specify which bones and frame ranges to use for each TRAM, but who wants to set up over 400 patches by hand?)
C. Finally, many existing characters had the glass-breaking added to them already. Therefore we don't want to add anything to the ONCCs/TRAMs that are already modded or we double the number of glass_break particles in the system.

In traditional computer terms, just performing step 4, with A, B and C, would require us to be able to say:
{{{
for Attack in Attacks
set start_frame to Attack.Start
set end_frame to Attack.End
set array Bones{} to Attack.Bones
for Bone in Bones{}
set bone_name to Bone
set add_this_bone to true
for Particle in ONCP
if Particle.Bone is bone_name and Particle.Name is "glass_break" then
set add_this_bone to false
end if
end for
if add_this_bone is true then
add to ONCP "Particle" with properties:
Start:start_frame
End:end_frame
Bone:bone_name
Name:"glass_break"
end if
end for
end for
}}}

I haven't carefully reviewed that pseudo-code, as it's just an example, so there might be a logical error in there, but you get the idea. This is totally beyond the current scope of Vago's syntax.

Now, we could help s10k in adding this kind of capability to XmlTools manually, but perhaps that's reinventing the wheel when there's already a ton of scripting languages out there. It may be a better idea to allow an existing scripting program to be called from within XmlTools and to pass it the instructions to run. Or, it may make more sense to integrate an open-source interpreter into XmlTools' code.

Thoughts? Questions? Headaches? Angry recriminations? I'm almost sorry to bring this subject up, but I simply don't know how else we can make a glass-breaking patch mod. The only alternative is to write yet another private tool like the one Gumby wrote and didn't release, so why not make something that the community can benefit from?

Description

In the recent version of OniSplit we can now extract files directly from a level .dat file without spliting the entire level. This is especially useful since AEI no longer keeps the individual .oni files from a level in the GameDataFolder.

I'm requesting this feature be added to Vago.

The syntax is -export:NameOfOniFile <Output folder> <path_to_level.dat>

Ticket	Resolution	Summary	Owner	Reporter
#42	fixed	BSL: sprintf with floats not working	Alloc	Alloc
Description	sprintf does not support floats.
#44	fixed	Code-like syntax for XmlTools patch files	s10k	Iritscen
Description	Let's reiterate what 'dox just stated in another ticket and then add an even worse scenario to the mix, to understand where XmlTools currently stops being useful. I've been procrastinating making this ticket because it's a doozy, but really, it has to be discussed and dealt with. Keep in mind that this is not intended to minimize the work that s10k has already done, which has been very helpful. Also, s10k, please don't start hyperventilating while reading this because there may be a "simple" solution that doesn't require much work from you. Paradox outlined a sample use case where we would need to be able to modify one part of a tag based on another part of the same tag. So, to alter the length of time (in levels) for which an autoprompt appears, we have to look for an autoprompt like: {{{ <ONGSAutoPrompt> <Notes>hypo</Notes> <FirstAutopromptLevel>1</FirstAutopromptLevel> <LastAutopromptLevel>2</LastAutopromptLevel> <SubtitleName>autoprompt_hypo</SubtitleName> </ONGSAutoPrompt> }}} according to the value of the SubtitleName tag, then modify the LastAutopromptLevel tag if we find what we're looking for. How would we normally want this to look, in a computing environment? Probably something like this: {{{ if ONGSAutoPrompt.SubtitleName is "autoprompt_hypo" then set LastAutopromptLevel to 2 end if }}} See how simple that can look with standard procedural syntax? Now technically we're missing a 'for' loop there, but we could easily just ask for XmlTools to treat 'if' statements as a request to iterate over all the named elements. But let's take this a step further with a much-less hypothetical scenario. Let's say that I want to add glass-breaking particles to all TRAMs (because I do). Gumby actually had to write his own tool to do this for the 2009 AE because it requires a conditional syntax ''and'' variables. This mod consists of four parts: 1. The glass-breaking particle. This is the easiest part, we just include the file BINA3RAPglass_break.oni in the mod, no patching needed. 2. A list of attacks to affect. This could be based on a pattern like "punch", "kick", etc., but there will have to be a list of names or patterns. This is currently able to be handled by the AEI's file name-matching of the .oni-patch files, so we can leave that alone, although it does limit the kind of pattern-matching we can do. 3. Now we need to let Oni know that a character can create this particle. We do this by adding this to their ONCC's ONCP array this element: {{{ <ONCPParticle> <Name>glass_break</Name> <Type>glass_break</Type> <BodyPart>-1</BodyPart> </ONCPParticle> }}} Just a standard @ADDTO command, here. Preferably, we only do this if this ONCPParticle has not been added already. Not sure if duplicating the listing does any harm, though, so let's move on. 4. We add the actual emission of the particle to attacks. Here's where it gets tricky. Here's the relevant part of a TRAM (Barabas' Earthquaker): {{{ <Attack> <Start>51</Start> <End>55</End> <Bones>LeftThigh LeftCalf LeftFoot RightThigh RightCalf RightFoot</Bones> [...] </Attack> }}} Notice how Barabas does damage with all his lower bones for the duration of frames 51-55. To add glass-breaking (according to how Gumby did it), we have to go to the Particles array in the TRAM, where it currently lists only the barab_wave for one foot (since it only needs to spawn that effect once), and add this: {{{ <Particle> <Start>51</Start> <End>55</End> <Bone>LeftThigh</Bone> <Name>glass_break</Name> </Particle> <Particle> <Start>51</Start> <End>55</End> <Bone>LeftCalf</Bone> <Name>glass_break</Name> </Particle> [etc. etc.] }}} So let's count the ways that this isn't possible with XmlTools: A. We need to read and save into memory the Start and End frames from the Attack, otherwise we have no idea when the glass-breaking takes place. We could just say frames 1-100, but then the character will break glass as far away as the distance of his attack's Extents before his fist/whatever gets anywhere near the glass. B. We need to read, parse and save the list of Bones from the Attack array. Otherwise we'd have to guess which bones to add the particle to, and if we guessed wrong, a character standing near glass would break it with the wrong parts of his body. Also, we'd be generating particles unnecessarily if we added glass_break to all bones. (Yes, we don't need to do A and B programmatically; the use of separate files for each patch allows us to specify which bones and frame ranges to use for each TRAM, but who wants to set up over 400 patches by hand?) C. Finally, many existing characters had the glass-breaking added to them already. Therefore we don't want to add anything to the ONCCs/TRAMs that are already modded or we double the number of glass_break particles in the system. In traditional computer terms, just performing step 4, with A, B and C, would require us to be able to say: {{{ for Attack in Attacks set start_frame to Attack.Start set end_frame to Attack.End set array Bones{} to Attack.Bones for Bone in Bones{} set bone_name to Bone set add_this_bone to true for Particle in ONCP if Particle.Bone is bone_name and Particle.Name is "glass_break" then set add_this_bone to false end if end for if add_this_bone is true then add to ONCP "Particle" with properties: Start:start_frame End:end_frame Bone:bone_name Name:"glass_break" end if end for end for }}} I haven't carefully reviewed that pseudo-code, as it's just an example, so there might be a logical error in there, but you get the idea. This is totally beyond the current scope of Vago's syntax. Now, we could help s10k in adding this kind of capability to XmlTools manually, but perhaps that's reinventing the wheel when there's already a ton of scripting languages out there. It may be a better idea to allow an existing scripting program to be called from within XmlTools and to pass it the instructions to run. Or, it may make more sense to integrate an open-source interpreter into XmlTools' code. Thoughts? Questions? Headaches? Angry recriminations? I'm almost sorry to bring this subject up, but I simply don't know how else we can make a glass-breaking patch mod. The only alternative is to write yet another private tool like the one Gumby wrote and didn't release, so why not make something that the community can benefit from?
#45	fixed	Add ability to extract files from .dat file	s10k	edt
Description	In the recent version of OniSplit we can now extract files directly from a level .dat file without spliting the entire level. This is especially useful since AEI no longer keeps the individual .oni files from a level in the GameDataFolder. I'm requesting this feature be added to Vago. The syntax is -export:NameOfOniFile <Output folder> <path_to_level.dat>

Context Navigation

Custom Query (105 matches)

Results (22 - 24 of 105)

Download in other formats: