12 réponses à ce sujet

[dorkinator99]

Hi, I'm digging around through the scripts in the toolset - I can't seem to find the structure behind crafting skills.  It seems like they're considered abilities, that when impacted invoke the crafting UI.  What drives the recipies/etc. that are pulled into the UI? Where would I define a new crafting skill?  I'm assuming the recipies themselves are pulled from the MSSQL database - but I really am just guessing right now.  If anyone knows more I'd be very appreciative.  Thanks

[Axe_Murderer]

Items have a Crafting Recipe Type property that references into the recipes.2da file.

[Phaenan]

Spent the last week working on a new craft, and I'm hopefully done, so yep you bet I've learned a few things in the process.
Long story short, recipes are pulled from the 2DA tables like almost everything else, but only the recipes from the original skills. It's hardcoded into the craft GUI actionscript :
- Pastie
That code include my attempt to add another skill to that actionscript before recompiling the UI, so don't pay attention to the TWF declarations here and there.

Anyway, I had an interesting discussion with FollowTheGourd about it, and he hinted I should have a try and modding the UI p-code. Something I didn't do yet cause I couldn't find the time. But if you want to add a new skill to the craft UI, that's apparently the way you should go.  Afraid adding a new craft skill to the UI it's not just a matter of 2DA tweaking.

Modifié par Phaenan, 03 décembre 2009 - 10:04 .

[dorkinator99]

cool, thanks for the reply - I'm new to dragon age modding, where are the 2da tables located? I can't find anything through the editor, so I'm assuming they're external flatfiles somewhere? I can't find the recipies.2da file you mentioned Axe_Murderer - but maybe I'm just not looking in the right spot.



After reading your discussion with FollowTheGourd Phaenan - am I correct in saying that the dragon age UI uses a slimmed down version of actionscript - and the issues you were having were in decompiling/recompiling correctly (since you would decompile from slimmed down, and all available compilers are 'standard' actionscript)? Which is why you suggest modifying the assembly code?

[Challseus]

dorkinator99 wrote...

cool, thanks for the reply - I'm new to dragon age modding, where are the 2da tables located? I can't find anything through the editor, so I'm assuming they're external flatfiles somewhere? I can't find the recipies.2da file you mentioned Axe_Murderer - but maybe I'm just not looking in the right spot.

$Install_Dir/tools/Source/2DA

[dorkinator99]

ahh, thanks so much Challseus

[Phaenan]

Which is why you suggest modifying the assembly code?

FollowTheGourd did, it's just that I pretty much agree with him 'cause it makes sense. Plus, I know from reading other topics that he could actually make p-code mods and is working on some project using this kind of UI modification. So I know for a fact that it does work.
But that's as far as I can go to be honest. To me, using the native GUI was a fluffy bonus and not a vital component, so I just pushed that aside for the time being and didn't look into it.

Modifié par Phaenan, 03 décembre 2009 - 05:16 .

[dorkinator99]

Ok, great - I just wanted to make sure I was following your dialog correctly. Thanks

[FollowTheGourd]

dorkinator99 wrote...
After reading your discussion with FollowTheGourd Phaenan - am I correct in saying that the dragon age UI uses a slimmed down version of actionscript - and the issues you were having were in decompiling/recompiling correctly (since you would decompile from slimmed down, and all available compilers are 'standard' actionscript)? Which is why you suggest modifying the assembly code?

Hi, dorkinator99.

It's not so much that it's slimmed down (it's complete enough as far as I know), but rather that essential parts of some classes in the ActionScript seem to use properties that aren't normally defined, so it won't compile "as is" (after cleaning up a bit).

It's probably possible to eventually get that to work (protoypes, instrinics, or just add "fake classes/properties" then compile and fix the p-code), but I focused on editing the p-code for now, since I could continue to make measurable progress that way.

The other thing is that even if the ActionScript compiles, we'd still need to get it back into the UI file... you could re-export the flash file back to a SWF, but then it'll probably be missing some of the tags it needs to display properly in-game. While it shouldn't be too hard to add those missing tags back, it's something that won't happen by itself.

Modifié par FollowTheGourd, 04 décembre 2009 - 12:46 .

[dorkinator99]

Ok, well I'm familiar with assembly programming - but I've never worked with actionscript assembly, what files contain the crafting GUI info? And do you have a link to actionscript assembly docs or something I could use as a reference to start playing around?

[FollowTheGourd]

Some of what I wrote in these particular posts:
social.bioware.com/forum/1/topic/72/index/256239#262799
social.bioware.com/forum/1/topic/72/index/310138#323315

But mostly by comparing it against the ActionScript to see how it came together in practice. The flasm site has a seemingly somewhat incomplete reference, but the m2osw site has a good list of actions starting here: www.m2osw.com/en/swf_alexref.html#tag_doaction. They're just not in "flasm form". Adobe also has some stuff in their open SWF file specs under the "action model" sections. Search for swf_file_format_spec_v10.pdf (there's also a v9 doc) or flash_fileformat_specification.pdf (older one, and apparently requires Adobe reader to agree to some license in the document). But Adobe's references aren't as compact, I find.

Usually the main class is named the same thing as the GUI: So the Crafting class for the crafting GUI. Just search for something like push r:1, 'StartScene' to find where it takes off - stuff before that function getting called is less important to modifying the overall behaviour.

Modifié par FollowTheGourd, 04 décembre 2009 - 02:16 .

[dorkinator99]

Great, thanks - so I have the flasm decompiled code, and I'm comparing it to the .swf decompressed file. I'm sort of just searching around trying to figure out the way things are organized, I see a bunch of 96 0C 00 commands, which are push commands (according to that SWF reference link you provided) - so I'm not sure what you're saying when you say 'Just search for something like push r:1, 'StartScene' to find where it takes off'. Is that a push of the string 'StartScene'? Also I'm not seeing how a register is defined (which is what I'm assuming you mean with the 'r:1' - it just says it 'Push[es] some immediate data on the stack'.



Any pointers would be awesome, thanks

[FollowTheGourd]

You don't have to delve too deeply into the SWF file itself - flasm's default .ini file should give you p-code with symbol names for the constant pool - just do something like "flasm -d crafting.swf > crafting.flm" and then edit the crafting.flm file. When you want to update to get a SWF back: "flasm -a crafting.flm". If it's giving you something else, then I'd check flasm.ini to see what the settings are - make sure it isn't set to output bytecode or something strange.

You might eventually need to understand more about the SWF file format to do certain things, but if it's just to make some additions to the crafting GUI, then probably not so much. One common case is if you need to manipulate a movieclip from script but it doesn't have an instance name.

Instead of comparing the output of flasm to the SWF file, compare the output of flasm to the ActionScript from flare or sothink's commercial tool.

"push" is just a basic building-block instruction kind of like MOV, but stack-based.  push r:1, 'StartScene' is just the prelude to defining a member function where the finale is a "setMember" call. The symbol r:1 is a register and it's probably better if I just referred you to the flasm page for an explanation of those, since I'll probably give a worse and confusing explanation off-hand. Flasm helps take care of register allocation for you, but there are global and local registers, and some automatically defined ones. It somewhat depends on if you're using "function" or "function2" instruction to define the function even...

Anyway, I'd recommend reading the flasm site over a few times to get the hang of it a bit. If you still have questions, feel free to ask and I'll do my best to answer.

Modifié par FollowTheGourd, 05 décembre 2009 - 01:09 .