artifacts in TRAC files should be removed

[Paradox-01]

Edt said that Kon's Trac file misses some animations. Apparently those artifacts don't harm the game. But when we extract character animations errors pop up and that's simply irritating/annoying.

Do you agree in removing them?

[Iritscen]

Before I can respond to this, I'm not really clear on the report in ticket:33. Where do these errors appear? Would that change in extraction command in Vago remove the errors? Who would be removing the TRAC links to missing TRAMs, and how?

[Paradox-01]

Those errors appear when you extract animations of konoko and fury.

I just gave it a try and deleted the links: converted Kon's TRAC files to xml, deleted the links, converted TRAC back to oni. (While doing so I added links for pis/rif-sprint ​hybrids.)

Then I tested anew the extraction: no more errors for Konoko and Fury.

[Iritscen]

Sorry, but you didn't actually answer even one of my questions ^_^ Pardon me for putting on geyser's tone of voice for this post, but...

1. "These errors appear". Yes, I get that they appear. Where do these errors appear that it's worth changing Oni's game data so you won't have to see the error? A dialog box in Vago? The OniSplit command prompt? And are these errors actually doing any harm?
2. You seem to be implying that if a fixed TRAC is supplied by a mod, or even in AE core, that it will solve the problem, but you aren't extracting animations from a level data file built by the AEI, are you? ...and why would you? The vanilla/*.dats don't count, those are globalized but not modded by the AEI in any way.
3. Should I assume that EdT's advice in that ticket about Vago using a different extraction command was a non sequitur that has nothing to do with the problem of TRAC link errors, and that using that command won't avoid the error?
4. What makes these artifacts more notable than the other 1,000 missing resources in the game that generate errors in logs and in the dev console?

Do you understand now the depths of my confusion and the inadequacy of your original ticket? I hope so ^_^

</geyser>

How was that, did it remind you of our old friend? :-) Sorry, perhaps I'm a little tired and cranky but I had to get that out.

[Paradox-01]

3) The actual error in ticket:33 is that ...

-extract:dae -search level0_Final <output dir> -anim:TRAMREDCOMcomb_p <path_to_ONCCred_hard_1.oni>

... produces an DAE file that contains a non-animated Fury (she's folded).
That happens because Vago's search folder is hard coded as Script stated ​here.

4) "What makes these artifacts more notable than the other?"
I find them relevant because those errors are visible during modding, not during playing the game. More of that in point 1c.

"Where do these errors appear?"
1a) "A dialog box in Vago?" Yes.
1b) "The OniSplit command prompt?" Yes.
1c) "And are these errors actually doing any harm?"
They do harm in a way of being confusing to modders. Why are there errors? What did *I* wrong?

2) I use the GDF most of the time. It's easy to access. With an extra OniSplit in there you can do some stuff via Windows address bar (cheap way of cmd) pretty fast: oni<=>xml converting, dat<=>oni conversion (level export / plugin creation).

Another advantage of GDF files is that they contain AE cores files. So you can build a new mod on fixed files and don't have to care about vanilla errors.

[Iritscen]

Sorry, still in geyser mode here...

3) The actual error in ticket:33 is that ...
[...]
... produces an DAE file that contains a non-animated Fury (she's folded).

Well perhaps EdT should have stated that explicitly, and I still don't know why he led into that discussion by talking about TRACs. But let's leave that meandering bug report aside.

4) "What makes these artifacts more notable than the other?"
I find them relevant because those errors are visible during modding, not during playing the game. More of that in point 1c.
[...]
They do harm in a way of being confusing to modders. Why are there errors? What did *I* wrong?

This sounds to me like a job for Script -- he can set Vago to not report "Cannot find instance" errors. That way newbie GUI modders won't be confused; as for the old-school command-line modders, they can be trusted to know their stuff better, right? ^_^ Let's get to the important part...

2) I use the GDF most of the time. It's easy to access. With an extra OniSplit in there you can do some stuff via Windows address bar (cheap way of cmd) pretty fast: oni<=>xml conversion, dat<=>oni conversion (level export / plugin creation).

Another advantage of GDF files is that they contain AE cores files. So you can build a new mod on fixed files and don't have to care about vanilla errors.

Oh, 'dox. No, no, no, no, a thousand times no. See, this is the crux of the problem, and the reason why I'm closing this ticket. Don't build mods on AE level data. Not even for testing. It's morally and pragmatically wrong. You'll be duplicating the fixes that come in core without any way for us to update your "fix-based" mod if we update our core files. Please only use the globalized vanilla/ .dats as a basis for your mods. Now that I'm worrying that other modders are doing the same thing, I don't think I will sleep well tonight....

And I can't recommend using plugins at all; they were a short-lived and ill-advised experiment. The interaction between plugins and existing data is unpredictable, as you've already observed, so immediately you're getting off on the wrong foot when you're trying to test something that will end up being a package anyway if released. On the other hand, packages seem to be 100% predictable, and they're easy, so easy! Modders would have killed for this approach back in the hex-editing days. Just make a sample package that you can grab whenever you need a template -- here, you can have mine (attached).

As for this ticket, it's closed with a vengeance. Back to work, everybody, nothing to see here....

</geyser>

[Samer]

Don't build mods on AE level data. Not even for testing. It's morally and pragmatically wrong. You'll be duplicating the fixes that come in core without any way for us to update your "fix-based" mod if we update our core files. Now that I'm worrying that other modders are doing the same thing, I don't think I will sleep well tonight....

we have been doing the same thing :p ... Before this AE release anyway .. I'll give you examples where this was very useful .. When making custom TRAMS for example instead of modifiyng a vanilla TRAM and then adding glass particles yourself to it .. You would start off by modifiying the TRAM that was in globalize folder and already had the glass particle ...
instead of modifying a vanilla ONCC and then manually modifiying it to add glass particle or adjusting health so it compares with upgraded oncc ... You'd use an already fixed oncc as basis ..
To view models in xsi ..
What i used to do was install all mods i want as basis improved textures, new animations, new characters, tram fixes etc .. And then decompile the AE level0-final dat and use the resulting files in my modding. This is very useful when you want to see characters with new textures and new made animations in xsi ... You can export the dae with a tram that otherwise didn't exist in vanilla.
This approach is very practical and saves modders many steps than manually readjusting everything and comparing to AE files.

This approach may be less useful now though when xml patches are going to be used.
but still an example .. Say we made upgraded onccs an xml patch and a core pack and it increases health of copfemales .. Then someone decides to make another outfit (another oncc) for female cops .. If he uses the vanilla oncc as basis the resulting character will have lower health than the other copfem outfits when installed .. Since the xml patch won't apply to it since it's a different oncc name but applies to the other onccs .. So here one can start from the upgraded oncc ..

My point is it's not a bad idea to use modded AE dats as source like paradox is doing unless the mod you're making modifies same file (same names) modified by core xml patches because it will risk duplicated info in the xml (applying the xml core pack to a file that already had it applied) but other than than i don't see a downside.

[Iritscen]

Well, I may have overreacted a little :-) Your examples make sense -- of course we did want people to use those glass-breaking particles in their work in the past, although now this makes a problem for us because we'll need to make sure they're not already in a TRAM/ONCC before adding them. Oh well, hindsight is 20/20.

Just to be clear, I'm not so much concerned about careful experienced modders using altered .dats as I am newbie modders picking up that habit and making a mess of things. It's too easy to lose track of exactly how your files were altered by other mods since most people don't scrutinize mods in a detailed way. As long as no one writes about this in any tutorials, I think my sleep will be unimpeded.

[Samer]

I might have mentioned it in my making custom character from scratch tutorial .. I'll edit it though to explain the risks.