Pasquale1223

Same version. You do need to have a file open in the toolset in order for Edit -> Find or Ctrl + F to be available.

Edit --> Find or Ctrl + F will bring up the pertinent panel.

It's not just the PC version. The junk tab and sell all option were added in DA2.

I would actually encourage you to do it the other way 'round. You haven't ever said what kind of script this code is going into and how it will be invoked - and the exact lines of code you'll need are entirely dependent on that. The examples I've provided are sort of generic. I would expect that you're going to have a dialogue for your NPC, and the branch that gives the armor would be conditional on having completed the joining. That dialogue would set your custom plot flag, and its plot script is where the work of issuing the armor would occur. Anyway, I'll be around. I would encourage you to develop that NPC dialogue and the plot flags they'll need. Then I could help you put the right code in the right place in the plot script. Happy modding.

First of all, TRUE is the same as a value of 1 and FALSE is the same as a value of 0. It probably gets a little confusing for folks who haven't done much coding, but... some of us tend to use those values interchangeably. Plot flags are stored as bits, and have only 2 possible values: 0 (FALSE) or 1 (TRUE). So this: if(WR_GetPlotFlag(PLT_PRE100PT_RITUAL, PRE_RITUAL_END) == TRUE) does exactly the same thing as this: if(WR_GetPlotFlag(PLT_PRE100PT_RITUAL, PRE_RITUAL_END) == 1) .. since the if statement would evaluate the same in either of them. This line: int flag_value = WR_GetPlotFlag(plt_pre100pt_ritual, PRE_RITUAL_END); would be corrected to this: int flag_value = WR_GetPlotFlag(PLT_PRE100PT_RITUAL, PRE_RITUAL_END); ... and it would serve the purpose of declaring an int variable named flag_value and storing that plot flag in it. Sometimes coders use variables like that to avoid repeated function calls. If you were going to check the value of that plot flag repeatedly, then it can be handy to store it in a variable that is easier to type; but if you're only going to look at it once or twice, it's usually not worth it to declare a variable for it. Basically, declaring and setting that variable would just mean that you could replace this: if(WR_GetPlotFlag(PLT_PRE100PT_RITUAL, PRE_RITUAL_END) == TRUE) with this: if(flag_value) going forward. In the first code example you provided, this part: WR_SetPlotFlag(plt_pre100pt_ritual,PRE_RITUAL_END, TRUE); WR_SetPlotFlag(plt_pre100pt_ritual,PRE_RITUAL_END,1); once corrected to this: WR_SetPlotFlag(PLT_PRE100PT_RITUAL,PRE_RITUAL_END, TRUE); WR_SetPlotFlag(PLT_PRE100PT_RITUAL,PRE_RITUAL_END,1); ... would basically set that plot flag to the same value twice. In the second code example you provided, this part: if(WR_GetPlotFlag(plt_pre100pt_ritual,PRE_RITUAL_END) == TRUE) { WR_SetPlotFlag(plt_pre100pt_ritual,PRE_RITUAL_END,1); once corrected to this: if(WR_GetPlotFlag(PLT_PRE100PT_RITUAL,PRE_RITUAL_END) == TRUE) { WR_SetPlotFlag(PLT_PRE100PT_RITUAL,PRE_RITUAL_END,1); ... will check the plot flag, and if it's true, set it to true again. In other words, it wouldn't do anything useful. And I want to strongly suggest that you do not change any vanilla plot flags! In the original example I provided, I checked a custom plot flag that you would define to track whether you'd given the items yet or not, since you had indicated you wanted to give them only once. If that plot flag had not yet been set, I set the flag and gave the items. In order to provide that functionality, you'll need to define a custom plot and flags. Hope I helped.

A couple of things: plt_pre100pt_ritual needs to be in all caps, like so: PLT_PRE100PT_RITUAL. It's a constant, and case sensitive. Note: the #include line is fine, but the WR_GetPlotFlag lines need the constant in all caps. The #include line tells the compiler to source in the file it knows as plt_pre100pt_ritual, but within that file is the constant PLT_PRE100PT_RITUAL needed by the WR_GetPlotFlag and WR_SetPlotFlag functions. Also, I got a little overzealous with the parentheses in the example I gave you. I included one too many close parentheses in the GetCreatureCoreClass checks I provided, so instead of this: if(GetCreatureCoreClass(oPC) == CLASS_WIZARD)) { it should be this: if(GetCreatureCoreClass(oPC) == CLASS_WIZARD) { ... and that needs to be changed for all 3 of those lines. Sorry about that. Once you make these changes, that should compile for you. Oh, and I just took a little closer look at what you're doing, so I'll have more to say here in a bit...

Glad I could help. Will your NPC just be at Ostagar, then, or... maybe also in camp or something? Whatever you decide to do, it sounds like a fun project - good luck with it, and we'll be around if you have any more questions.

The way we usually control giving something only once is to use a plot flag that initializes as Not Set, and give the item at the time the flag gets set. So that would look something like this (also making the specific item given dependent on class): #include "utility_h" #include "wrappers_h" object oPC = GetHero(); if(WR_GetPlotFlag(PLT_MY_PLOT,MY_GIVE_ITEM_FLAG) == FALSE) { WR_SetPlotFlag(PLT_MY_PLOT,MY_GIVE_ITEM_FLAG,1); if(GetCreatureCoreClass(oPC) == CLASS_WIZARD)) { UT_AddItemToInventory(R"my_mage_item_resource.uti",1); } if(GetCreatureCoreClass(oPC) == CLASS_ROGUE)) { UT_AddItemToInventory(R"my_rogue_item_resource.uti",1); } if(GetCreatureCoreClass(oPC) == CLASS_WARRIOR)) { UT_AddItemToInventory(R"my_warrior_item_resource.uti",1); } } You could also automatically equip the gear if you'd like. But I'm a little confused about exactly what you're trying to accomplish. It sounds like your custom outfitter NPC has dialogue, yes? You can make any line of their dialogue conditional, so you could have an entire branch dependent on whether you've completed the joining. It looks like you're trying to give the player only one set of this gear, specifically for the player. If you're interested in making more sets available for followers as you recruit them, you could just make a console runscript or three...

Well - if you're wanting to use the toolset to do something other than database manipulation, you'll need to get it to work with your SQL installation. But it doesn't sound like you actually need it for anything at this point, since you're working on a database. I haven't had any issues using either GDApp or the ExcelProcessor. As I mentioned earlier, I just open File Manager and drag the xls source file onto the ExcelProcessor executable, and the GDA is generated. I put them all (the xls source file and the ExcelProcessor executable) in a directory where I'm doing my GDA development work so I don't lose track of the output - it all stays right there in the directory I'm working in.

Roger that. If all you're looking to do at this time is change a database, that should work for you. Otherwise - if you want to get the toolset working - the info I supplied should help, and if you have further questions, don't hesitate to ask. Good luck with your project.

Having 2 threads with the same questions probably isn't going to be helpful. You might want to delete the other one. I have successfully installed the toolset in Windows 10, and it works fine. The original SQL database that installs with the toolset worked for quite awhile, too, but... then it didn't, and I suspect it may have been a Windows update. I followed the instructions posted here and was able to install a different SQL Server. I used the 32 bit fix files, as the 64 bit fix files did not get things going for me even though I'm on a 64 bit system. The toolset wiki also offers information and help with troubleshooting problems. The ExcelProcessor is also working for me, but I'm using Microsoft Excel 2002. I just drag the source .xls file onto the ExcelProcessor executable - a window pops up and finishes really quickly, leaving the generated GDA file. You can also just use GDApp to create and edit GDA files. Hope I helped.

I'm so glad you got it solved! Maybe the lighting mod doesn't get along with your new video card or drivers? If the mod page doesn't offer any clues, you might want to check the posts tab there. Sometimes people post issues they've had along with solutions. Have fun with your new rig!

Hello, ghost. :) Sorry you're having such troubles. I can see you've been through quite a lot. The ..Documents\BioWare folder typically holds info about your install - like profile, saves, mods, that sort of thing. Unless you've changed your profile (like by unlocking specializations or earning achievements) or have some saves you'd like to keep, you can ditch the folder when you uninstall... or rather, I should say the BioWare/Dragon Age folder. The ... Documents\BioWare folder also contains files associated with other BioWare games in their respective sub-folders, which you may wish to keep. Your installation lists more steps than I remember ever going through - but I install through Origin. FWIW, and if you're interested in trying a different platform - you can register your CD Key from Steam into Origin and download/install it through Origin instead. Whether you stick with Steam or move to Origin, I would suggest: -- Make sure you uninstall everything. Unless you have a profile or character save you'd like to keep, ditch .. Documents\BioWare\Dragon Age -- Fresh install -- Start the game and make sure it works. Create a character, play a bit. -- Install LAA patch. (large address aware, sometimes called 4GB). -- Play awhile, make sure everything is still working. -- Then install mods a few at a time. Do not use Vortex to install DA mods. Make sure the game still runs okay after you've installed each (small) batch of mods.

Personally, I've never used any sort of mod manager for DAO. Dazips are easily installed with the daupdater that comes with the game, and installing/uninstalling most other mods is a simple matter of copying/deleting the files into/from your override directory. There are a few that require a bit more to install or uninstall, but the mod authors generally provide pretty good instructions either on the mod page or in the documentation that comes with the mod. Where that info is unclear, one can usually find more detail under the forum or posts tab. One note about daupdater - it generally takes only a few seconds to do its work, though it appears that it is still working.

Woot! I'm glad you got it sorted. Enjoy your new mod!

Did you create a PRCSCR gda file for your mod as described here? There's also some info about custom PRCSCRs in a recent post here.

I would highly encourage you to study the wiki page about tactics - their actual operation is not entirely intuitive, and it's easy to misunderstand how to set them properly. A couple of things I'd like to point out: -- For each "round", the logic starts at the top of of the programmed tactics and examines the conditions of each one until it finds something it can do. By that, I mean the condition is met AND the programmed action is available (not on cooldown). If there's nothing programmed that fits (and is not on cooldown), it'll do a default attack on the current target and then start again from the top. -- Some of the "Enemy:" conditions operate on the current target while others actually select a different target. Which is which is explained in the wiki page I linked. What you've typed here is a condition, but does not include the action to take. And I'll offer a couple of suggestions FWIW: - I generally avoid using the "aggressive" behavior. I choose "ranged" for archers and mages and "default" for melee characters, because it tells them to avoid hostile AOE. - I'm not sure why you're using (wasting?) talents/spells (and the stamina/mana) on lowest health. For clean-up duty (that is, to finish off enemies that are almost dead) I sometimes put Enemy: Lowest Health -> Attack at the bottom of the tactics list.

Apologies for my late entry to this thread - I've not visited the forums for awhile. If it's too late for my post to help you, OP, perhaps it will help someone else with the same problem. In order for the EquipItem function to work, you need a reference (oItem) to an existing item. Since the function that retrieves references to inventory items actually returns an array, we'll need to declare it as an array, like so: object [] oItem; Since you've already added your custom items to Oghren's inventory, you'll need to set oItem to reference each of them before you can equip them. I'm going to assume that the tags of your custom items follow the standard naming conventions, that is (for example) the tag for oghrenshirt.uti is set to "oghrenshirt". If not, you'll need to substitute the tags you're actually using. So - to set the value of our oItem variable to refer to your custom oghrenshirt - and then equip it, we need these lines of code: oItem = GetItemsInInventory(oOghren,GET_ITEMS_OPTION_ALL,0,"oghrenshirt"); EquipItem(oOghren,oItem[0]); Notice that I omitted the inventory slot arg in the EquipItem function call. It's optional, and really only needed for items that could occupy multiple slots (example: a dagger could be equipped in the main hand or offhand, and there are 2 slots for rings). We can repeat those lines for the other custom items you were trying to equip in the code segment you provided, like so: oItem = GetItemsInInventory(oOghren,GET_ITEMS_OPTION_ALL,0,"oghrenshoe"); EquipItem(oOghren,oItem[0]); oItem = GetItemsInInventory(oOghren,GET_ITEMS_OPTION_ALL,0,"oghrenbrace"); EquipItem(oOghren,oItem[0]); If you replace the EquipItem lines in the code snippet you provided with the lines in courier font I've provided here, your script should compile and execute. Hope I helped.

Okay - I'm glad you got it solved. Enjoy the rest of your game!

You might need to patch your game executable to make it large address aware.

Happy to be of service. Did you say OCD? I resemble that remark, lol. I think a lot of us have multiple playthroughs with different wardens that made different decisions, and we can see how they impact the next game when we import those saves. Hooboy, the implications of trying to maintain world state without the Keep... AFAIK, there are a couple of reasons why they needed to go there (develop the Keep) -- Inconsistencies/discrepancies with save files and transfers. I think some plot flags were just plain broke, and others might not have been imported and were needed later. Like for example if Oghren did become of interest in DA4 but nothing about him was imported from DAO/DAA -> DA2 or DAI, you're kind of out of luck. -- Changing platforms. For example, DAO & DA2 were released on PS3; DAI on PS3 & PS4. There really isn't a way to import a DA2 save from PS3 -> PS4, so they needed to do something to mitigate that - thus, the Keep. It also allows people to change platforms altogether. I originally played DAO & DA2 on PS3, but bought DAI on PC. (Actually I have all 3 games on PC now.) The other option is for each new game to have a startup sequence that allows players to input key decisions from previous games. Either way, it's kind of handy because you can set up conditions unique to each DAI run without having actually made those decisions in a prior game.

As you've probably figured out, running the script with those args is designed to set plot flags to a particular value. It looks to me like those flags are used to do these things: -- Provide the proper codex entries for those characters. -- Provide the correct version of the ending slides you're shown when you complete the game. -- Import their status to DA2. World states imported to DAI are generated by the Dragon Age Keep, which allows you to create your own world state regardless of saves. Exactly when you should run them depends on when the game's logic sets them. It's possible that they're set as soon as you make the choice to protect Amaranthine, but it's also possible it doesn't happen until later. I can make a couple of suggestions that might help you figure out when they're set. -- Keep tabs on the content of their character codex entries - look at them before and after you make the decision to protect Amaranthine, and see if there are any changes. -- Turn on script logging, and watch the log to see when those flags are accessed and set. To turn on script logging, you'll need to create a text only file (like with Notepad or similar) and save it in your game install directory, as bin_ship\ECLog.ini. The content of that file should be: [LogTypes] Script=1 Once you've done that, you'll see a lot more entries in your log file (in your documents directory, under BioWare/Dragon Age/Logs). GetPlot means the game is retrieving the plot flag to check it. SetPlot means the game is setting the plot flag to the specified value. Here are some example entries - note that plot flags are identified by the name of the plot and the specific flag within that plot: Script GetPlot [int000pt_main] [INT_MAIN__INTRO_CUTSCENE_COMPLETE] = [0] Script SetPlot [int000pt_main] [INT_MAIN__INTRO_CUTSCENE_COMPLETE] -> [1]Before I end this, I'd like to explain the arguments used in those commands you've found, so you'll understand how to do this. In this command: runscript zz_getsetplotflag set cod_cha_nathaniel 12 0 ... runscript zz_getsetplotflag tells the command console you want to run the script of that name. ... set tells it that you want to set a plot flag.. ... cod_cha_nathaniel is the name of the plot whose flag you wish to set ... 12 refers to the specific flag within that plot you wish to set. Sometimes the logging prints the actual value (12); sometimes it uses a constant (INT_MAIN__INTRO_CUTSCENE_COMPLETE). ... 0 is the value that you are setting it to (valid values are 0 and 1). Don't be surprised if that script doesn't generate any log entries - it probably doesn't. --------------------------------------------------------------------------------------------------- If you don't care about the codex entries and ending slides while you're actually playing, you can always load your last save, run the commands, and save it again to use that modified save file as your import to DA2. As to what difference those plot flags make in DA2: -- There may be some dialogue differences in the case of Anders'. -- As for Nathaniel, his survival determines which of 2 alternative sidequests are available to you. You'll get one or the other. -- I don't think Oghren's survival impacts DA2 in any way. -- As for DAI - you'll set up your imported world state via the Dragon Age Keep, anyway. Hope I helped.

Just for kicks, I started an Orlesian Arcane Warrior in DAA, and see what you mean. :sad: I did find that running Combat Magic improves the hit rate substantially, but it is still a lot lower than typical melee combatants. Also found a vid of a solo Arcane Warrior taking down Flemeth here: and noticed Miasma was included in their repertoire. Then I found this note on the Miasma page: This spell is excellent for an Arcane Warrior tank. The defense penalty applied to enemies helps a lot; Arcane Warriors often struggle with low attack score. And the extra threat (when on Hard / Nightmare difficulty) is welcome. Have fun!

I'm glad you got it going. It was nice of you to post updates as you went along - they might help someone else sometime. Enjoy your hard-earned toolset.

Per the fandom wiki, attack score is calculated as: AttackValue = Base + 0.5 * {(Strength - 10) + (Dexterity - 10)} + AttackBonuses where Base is 50 for mages, 55 for rogues and 60 for warriors. The same page also shows the Attack Roll as a comparison of your attack score versus the enemies' defense score to determine whether the hit connects. Per the properties database, max attack value is capped at 1000. Armor penetration basically reduces the opponents' armor. I also found a couple of other threads that might be useful. https://gamefaqs.gamespot.com/boards/950918-dragon-age-origins/52197307 https://gamefaqs.gamespot.com/boards/920668-dragon-age-origins/56501727