tom.morrow

. Wellcome back to our final chapter of "How is this game Building my Mount?" In my last post I have a detailed outline of what the following changes / additions will be. Before we continue, let me note what is expected: Myra, my seraphim, should have again all 4 exclusive mounts offered. Since we reverted all changes, she should not be affected in any way from now on. Nevertheless, when all is done, I will test her one final time to make sure all is well. Test-Y, my high elven mage, should get her standard 4 exclusives offered, plus one more. This last one should have the icon of the sabertooth and the name of the ring we replaced. I expect her to be offered a sabertooth mount called "Mormegil's Finger Hoop" and, once bought, to be able to mount a sabertooth that is called "Anducar's Dark Thoughts". Weird, I know, but something like that may happen with the changes we introduced. OK, time for the changes... done... done... done... I'd like to spare you quite a few pages of boring script code, since I have already outlined completely and in detail, step by step, what has to be changed and / or added. Let me instead treat you straight with the results: (the Temperature Artifact reads 1 hand and 1 finger.) Myra passed the test with flying colours, all was exactly as expected, no surprises, no problems. :check: Test-y had the sabertooth (that belongs to Myra now, wrong class mount) already bought/equiped from last test. When I loaded her she had lost her helmet, maybe the game broke the item loading process once it encountered an invalid equiped item, that is my best guess here. Anyway, she had an seraphim-exclusive mount and of course refused to mount it: "You got to be kiddin me, right?". She went to Hugard, who bought the invalid mount off of her and also offered her an assortment of 5 "items", her 4 exclusive windserpents, and this: "Burn meh, this is ossum.!" she thought "We get offered a magic ring, that summons a sabertooth. Yeeehaa.!" and promptly bought it: Summoned and ordered it to attend windserpent classes in AHEMCT (Advanced High Elven Mounted Combat Tactics): And, when finally convinced it had caught up in its training, they went to study a few shrouds: A few final notes: The magic-ring item on offer was named as expected, but was not named as expected once bought. In fact the game seems to have retained the mounts name by the blueprint/tradeitem/"CLF_ICON" class. In hindsight this makes some sense. You can have X items based on the same itemtype but with different names, its the blueprints that get named. Well... hindsight is a marvelous thing, helps in understanding the workings of our multiverse. And, thus, it endeth... Which brings me at a full circle back to: [ my 1st post in ] Any comments, ideas, changes, requests, beginnings and / or endings, are welcome and greatly appreciated. best regards Difficulties get solved Immediately.! Impossibilities take a little bit longer.!

. We are still having trouble with that mount. And I'm fairly certain that all the changes we did are correct. Almost everything I could think of, has been completed.! And I say almost because ... well ... I just created a new item, what is its name.?.!.? Before we continue, lets drop all the changes we made since we started and revert the original Data files. Reasons: Some of the changes are intertwined, if we keep changing the same spots, scripts will become chaotic. Since we will script the whole data-chain again, its best to start fresh from the original data. Less comments and less intertwined changes in the scripts = easier to read, follow and understand. Also there are a couple spots that have changes we made to "share" a mount between classes. Those changes never suceeded for the lack of a wildcard in one specific place (creatureinfo.specialmountfor). Altho those changes by themself may be harmless, they are also useless, since they do not contribute anything. Furthermore, we have intertwined and exchanged structures between the high elf and the seraphim, quite a few times. This was based on the 1st test to swap a mount, shift it to another class for testing. But ever since, we kept those as we left them, even tho we do not intend any change for the seraphim. So reverting makes sure the seraphim-structures stay untouched. This will allow us to focus specifically on one class and will also cut down testing times.! We can leave the double set of 3 icons for now, we will use them anyway. We will have to rename them, when the time comes. Since we started editing we have made changes in 6 text files, we need to revert those back as they were before we changed anything, so that is what we do now. Reverted.! Lets start over. Is a name needed? IIRC, once, when I tried to create a new set, I had failed in the same manner, because there was no way to give it a name, altho everything was carefully scripted, the set was not in the game, the items refused to spawn/drop. Once I replaced parts the of an existing set, all went well, the items started dropping. Hmm... trully... I need a horse.! But wait, I've done that, time and again, and it worked, because horses and exclusive mounts are described and build the same way. Perhaps, instead of a horse, I should try with some other named unique object. How about locating a few unique_ring_ types, 2-3 of them should be enough. Good source and an incredible help in all this, will be the unique database from our sacred wiki Uniques_Database Kudos to all people who helped composing and completing this task.! I would have been lost, many times over, without all your awesome good work. I picked some named unique rings and located them in blueprint.txt. Here's the list: named object blueprint id blueprint name itemtype id to be used for --------------------- ------------ --------------------- ----------- -------------- Anducar's Dark Thoughts 2545 unique_ring_anducar 11526 "CLF_WARHORSE" Mormegil's Finger Hoop 2529 unique_ring_mormegil 11523 "CLF_ICON" Eramil's Finger Hoop 2513 unique_ring_eramil 7140 - - spare - - Those should do. Now lets note all additions/changes we are going to apply: icons in folder ...\pak\data\icons\items we need to rename one set of 3 icons to match the "CLF_ICON" itemtype id 11523 and one set of 3 icons to match the "CLF_WARHORSE" itemtype id 11526 file ...\shared\itemtype.txt: a. comment out the itemtype structure: mgr.typeCreate(11523, xxx b. comment out the itemtype structure: mgr.typeCreate(11526, xxx c. copy 2 structures from: mgr.typeCreate(3400, and: mgr.typeCreate(10458, to the end of the file and adapt necessary changes file ...\shared\creatureinfo.txt d. copy 1 creatureinfo structure with type = 3400 and adapt necessary changes file ...\server\creatures.txt Note: We are not replacing an existing creature, this is a NEW creature. Since we need a new creature_id, we can use the one found by research.2 e. copy 1 creature structure with itemtype_id = 3400 and adapt necessary changes f. copy 1 CreatureBpRelation structure with blueprint_id = 1766 and adapt changes file ...\server\blueprint.txt g. comment out the blueprint structure with id = 2545 h. comment out the blueprint structure with id = 2529 I. copy 1 blueprint structure with id = 1766 and adapt necessary changes new id will be 2529 file ...\server\drop.txt j. ( optional step, since this mod will probably not finalize here ) Remove all references to blueprints 2529 and 2545 We have hijacked their types and blueprints, they do not reference rings anymore. Since we do not want a sabertooth to drop, we have to remove them from any droplist they have been on. This is optional because this mod is still in alpha stage. Research.4: Since we are going to create a new droplist, we need to locate the MAX droplist_ID used in this file and take the next available Note1: 1. This was already done in [mod.1 - part.2.b] but was not documented 2. the resulting free ID to use was 1545 3. Yours may differ based on game version and / or installed mods. k. create new droplist for the new mount, droplist id = 1545 entry0.blueprint=2529 L. induce the newly created droplist into the horsetrader droppattern list as done in [mod.1 - part.2.c] file ...\shared\iteminfo.txt m. copy 1 iteminfo structure with type 10458 and adapt necessary changes new type will be 11523 This is the plan for mod.2 , we will see the changes and subsequent results in my next post. No plan survives after the 1st shots are fired.!

wow gogo looks up at his post: that right there is a quote-gone-weird Uhm.. about that video... I never done a video, dun even got a capture prog installed sowwy mate, tho its fairly easy to replicate

Thats what came to mind, the dryad comes equiped with a ranged weapon from start when all other toons need to search a while for a decent ranged weapon And range at the begining makes things alot faster going. One small thing here: in general I dont like the blowpipe, it has that strange graphic bug. When a toon has a ranged weapon equiped and you CTRL + left click, that toon stays put and fires from spot. When you move your cursor around while doing that, the toons start turning and shooting. Well... the dryad with any other ranged weapon does, not so with teh blowpipe. With that she just stands there, looking north for example, even when shooting west, resulting the darts flying sideways or even backwards Its weird.... Warning: Don't try this at home!

With "items" there are 2 places you need to check / change to enable other classes to use them 1st place is in itemtype.txt, here is an example: newItemType = { -- standard info renderfamily = "RENDERFAM_WEAPON", renderprio = 0, family = "FAMILY_WEAPON", subfamily = "SUBFAM_PRI_2H_AXE", classification = "CLF_2H_AXE", flags = "FLAG_HASPREVIEWIMAGE", weargroup = "WEARGROUP_INVALID", -- 3d model + animation info model0Data = { name = "models/weapons/2h/t_miniboss-minotaur-hero-axe.GR2", user = "WEARGROUP_CENTURIO", }, -- logic bounding box logicBox = { minx=-14.696, miny=-31.29, minz=-3.817, maxx=14.696, maxy=25.417, maxz=3.817, }, dangerclass = 0, } mgr.typeCreate(11850, newItemType); To enable this weapon for all classes the only change you need to do here is: newItemType = { -- standard info renderfamily = "RENDERFAM_WEAPON", renderprio = 0, family = "FAMILY_WEAPON", subfamily = "SUBFAM_PRI_2H_AXE", classification = "CLF_2H_AXE", flags = "FLAG_HASPREVIEWIMAGE", weargroup = "WEARGROUP_INVALID", -- 3d model + animation info model0Data = { name = "models/weapons/2h/t_miniboss-minotaur-hero-axe.GR2", user = "WEARGROUP_DEFAULT", -- <- changed from "WEARGROUP_CENTURIO", }, -- logic bounding box logicBox = { minx=-14.696, miny=-31.29, minz=-3.817, maxx=14.696, maxy=25.417, maxz=3.817, }, dangerclass = 0, } mgr.typeCreate(11850, newItemType); The 2nd place is in blueprint.txt, take the above type_id (11850) and search, found: newBlueprint = { id = 2796, name = "legendary_bergonix_axe_2h", palettebits = "1111111111111111", dmgvariation = 170, minconstraints = {20,15,1}, lvljump = 10, usability = 0, allotment_pmfpi = {1000,0,0,0,0}, uniquename = "unique", specialuseonly = 0, bonusgroup0 = {522,1250,1,9,0}, bonusgroup1 = {766,1750,1,9,0}, bonusgroup2 = {875,1455,1,9,0}, bonusgroup3 = {750,1000,1,9,0}, bonusgroup4 = {859,1000,1,9,0}, bonusgroup5 = {751,1000,1,9,0}, itemtypes = {11850,}, wearergroups = {'WEARGROUP_CENTURIO',}, } mgr.createBlueprint(2796, newBlueprint); Here is the 2nd change you need to make: newBlueprint = { id = 2796, name = "legendary_bergonix_axe_2h", palettebits = "1111111111111111", dmgvariation = 170, minconstraints = {20,15,1}, lvljump = 10, usability = 0, allotment_pmfpi = {1000,0,0,0,0}, uniquename = "unique", specialuseonly = 0, bonusgroup0 = {522,1250,1,9,0}, bonusgroup1 = {766,1750,1,9,0}, bonusgroup2 = {875,1455,1,9,0}, bonusgroup3 = {750,1000,1,9,0}, bonusgroup4 = {859,1000,1,9,0}, bonusgroup5 = {751,1000,1,9,0}, itemtypes = {11850,}, wearergroups = {'WEARGROUP_DEFAULT',}, -- <- changed from {'WEARGROUP_CENTURIO',}, } mgr.createBlueprint(2796, newBlueprint); Thats all.! Only those 2 small 1-line changes and the item is usable by all classes (who dont have restrictions.!) I hope this clears things a bit, let us know the result. best regards Knowledge is a weapon... I intend to be formidably armed.

Uhm... technically BFG is not a weapon, its a CA, but yeah, should be doable aswell Cut the strings and fly away...

Of course you can do that with shields, but it will only work for classes who can use a shield, for example the T.G can not use a shield. I did that sucessfully unlocking the round blue seraphim shield, making it multi-class user = "WEARGROUP_DEFAULT", -- instead of "WEARGROUP_SERAPHIM" EDIT: AFAIK weargroup in itemtype.txt is useless. At least whenever I make a change, I change the user: model0Data = { name = "models/npc/ridingcreatures/hippocampus/v_hippocampus@std.GR2", user = "WEARGROUP_HIGHELVE", }, like the 2 examples example above Also possible with weapons and other items, even with armor. Keep in mind that classes have their own restrictions for weapons, for example some classes dont allow a 2-handed weapon, others dont use a bow etc... But Armor has some points it connects to the model and will probably not clip well as you mentioned already A good example of a bad connection can be seen in the picture of this post by SX255 http://darkmatters.org/forums/index.php?/topic/21447-remove-character-startingplaceholder-equipment-freshly-baked-I-candy-without-the-pesky-glow-effect/&do=findComment&comment=6963716 There he attached a T.G. arm on his D.M. you can see if you max the picture, some bad parts connecting his arm with his leg. This kind of things happen when you put gear made for other classes, but you can experiment It almost always will not crash the game, look what I did with a ring once: http://darkmatters.org/forums/index.php?/topic/21413-funnyinteresting-sacred-2-screenshots/page-2&do=findComment&comment=6963917 This game offers so much freedom in experimenting, dont be afraid to do some crazy thing once in a while. Just ALWAYS make sure you have a backup, in case something explodes best regards Press F for fast loading now... Skipped. Proceeding with slow loading...

Same here, thats something I am having with all my toons that jump or port from one spot to the next, and its bugging me no end I was intent looking into it, but it seems to be something integral to the camera ... Not completely sure, but looks like it

That was exactly my thought for days now, +1 Probably Flix is too heavily involved in da wiki these days, he's doing a great job

you meanie, thats about the only toon I havent played "Good morning, Mr. Andesron." 1st time I heard that from him I was dumbstruck Funny bugreport #7753: A highelf who is playing with the ball is needed...

Modding gone in unexpected ways: a Mod gone Bad.! While wrestling during the free-the-mounts project, at one point something realy weird happened. Some changes I made resulted in this: of course Myra was thrilled, she dropped it to take a closer look, and started the happy-drops-dance: and finally promptly proceeded to pick it up again: This is not a bug, its a feature.!

That's great sometimes I have my moments and sometimes wicked thoughts This is not a drill. This is the Apocalypse. Please stay calm and exit the building.

You want to adjust the inventory size of an Item? if yes, then you 1st need to find the blueprint and the line itemtypes = { xxxxx , }, take this new code and search in iteminfo.txt with that new code, you should find a section: newItemInfo = { type = xxxxxx, material = "0_default", usability = 0, invbreite = 1, invhoehe = 1, } mgr.itemInfoCreate(newItemInfo); what you need to change is: invbreite is the width of that item in your inventory invhoehe is the height of that item in your inventory I hope this is what you were looking for, if not let me know best regards Guru meditation...

Since we have all we need already neatly outlined, lets proceed to the actual additions/changes. Research 1-3 are is completed. Icon sets have been extracted into proper folder and renamed according to predefined pattern. Lets start scripting, here is part.3.b in file...\shared\itemtype.txt: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.b - START -- purpose: add 2 new sections for the new itemtypes: "CLF_WARHORSE" and "CLF_ICON" -- newItemType = { -- copied from mgr.typeCreate(3400 -- standard info . . . dangerclass = 0, } mgr.typeCreate(12001, newItemType); -- <- changed id newItemType = { -- copied from mgr.typeCreate(10458 -- standard info . . . model0Data = { name = "models/npc/ridingcreatures/Frosttiger/c_tiger.GR2", user = "WEARGROUP_DEFAULT", -- <- changed user }, . . . dangerclass = 0, } mgr.typeCreate(12002, newItemType); -- <- changed id -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.b - END Those 2 sections are copied from the mentioned places to the bottom of the file and were edited Changes are marked by: -- <- This is part.3.c in file...\shared\creatureinfo.txt: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.a - START -- purpose: new section to add the sabetooth also back for the seraphim -- newCreatureInfo = { type = 12001, -- <- mod.1 part.3.a value = 3400 -- <- mod.1 part.3.c value = 12001 . . . specialmountfor = 1, . . . } -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.a - END This section already existed since part.3.a The only change here was to shift the type over to the new "CLF_WARHORSE" we just created in itemtype.txt of part.3.b. That change is marked by: -- <- Next is part.3.d in file ...\server\creatures.txt: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.d - START -- purpose: add a new section for new itemtype: "CLF_WARHORSE" -- mgr.createCreature { -- copied from section with itemtype_id = 3400, id = 2001, -- <- change itemtype_id = 12001, -- <- change . . . elite_creature_id = 2001, -- <- change . . . tenergy_creature_id = 2001, -- <- change . . . can_strafe = 0, } -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.d - END New section, copied just below the one mentioned and changed accordingly. Changes are marked by: -- <- And part.3.e in file ...\server\creatures.txt: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.e - START -- purpose: add a new link section between new itemtypes: "CLF_WARHORSE" & "CLF_ICON" -- mgr.addCreatureBpRelation { -- copied from section with blueprint_id = 1766, creature_id = 2001, -- <- change blueprint_id = 4001, -- <- change } -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.e - END This also is a new section, copied just below the one mentioned and changed as planed. Changes are marked by: -- <- Next is part.3.f in file ...\server\blueprint.txt: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.f - START -- purpose: add a new blueprint section for new "CLF_ICON" itemtype -- newBlueprint = { -- copied from section with id = 1766, id = 4001, -- <- change . . . itemtypes = {12002,}, -- <- change wearergroups = {'WEARGROUP_DEFAULT',}, -- <- change } mgr.createBlueprint(4001, newBlueprint); -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.f - END A new section, copied just below the one mentioned and changed accordingly. Changes are marked by: -- <- On to part.3.g in file ...\server\drop.txt: mgr.createDroplist(1484,{ -- Stock_specialmounts1 id = 1484, . . . entry3 = { -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.2.a - START -- purpose: remove the non-aspect windserpent reference in this droplist -- -- - - - - - - - - - - - - - - - - - comment out the original section/values: start -- -- -- drop (offer) propability of windserpent -- weightedprob=255, -- <- original value = 2 -- -- <- mod.1 value = 255 (insanely high) -- -- blueprint=2132, -- }, -- entry4 = { -- weightedprob=2, -- blueprint=2136, -- }, -- entry5 = { -- -- - - - - - - - - - - - - - - - - - comment out the original section/values: end -- -- - - - - - - - - - - - - - - - - - replace with new section/values: start weightedprob=2, blueprint=2136, }, entry4 = { -- - - - - - - - - - - - - - - - - - replace with new section/values: end -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.2.a - END weightedprob=2, blueprint=2137, }, -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.g - START -- purpose: add our new blueprint blueprint into this droplist -- entry5 = { weightedprob=255, blueprint=4001, -- <- change }, -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.g - END }) This is the droplist we had already moded in part.2.a Here we just added another entry (entry5) for the new blueprint we created in part.3.f The marked change is just to highlight where the blueprint ID is to be inserted (in case this entry was copied from another entry) And finally part.3.h in file ...\shared\iteminfo.txt: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.h - START -- purpose: add a new iteminfo section for new "CLF_ICON" itemtype -- newItemInfo = { -- copied from section with type = 10458, type = 12002, -- <- change . . . invhoehe = 1, } mgr.itemInfoCreate(newItemInfo); -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.h - END A new section, copied to the end of the file from the section mentioned in the comment. The change it marked by: -- <- This completes the changes and additions I had outlined in my last post, time to test them out. (the Temperature Artifact reads 3 fingers.) The Results: Test-Y, the elven mage, could buy, mount, sell and buy back the sabertooth. All well here. She gets a solid 5 mount offer, so the bug we introduced in the final test of part.3.a was fixed by part.3.c Thats good news. Myra, the seraphim, did not get an offer to buy it. Hugard was offering her only the 3 aspect mounts. Hmm... ok, this did not go as well as expected. We fixed the elf, as intended, but failed to fix the seraphim aswell. to be continued ... Please stand by for an important announcement.

by far.. the Wood Elf, I kinda dont like the dryad, its not her CA's, its mostly the toon and armor I dont like and given that I am looking at the toon 95% of the time while playing... yeah Wood Elf, miss you sooooooo In fact, the s1 chars had way deeper personalities, even their voice overs were more interesting Anything that promotes immersion is welcome Hit any user to continue.

you are most welcome In fact its a pleasure to be able to answer direct and to the point Anything that furthers the game and fun is All prisoners are to be executed at once.!

This one's for Flix and SX255 and anybody else who has trouble in camera views, and in satellite views during boss fights These are my camera settings from options.txt -- DO NOT EDIT THIS FILE -- -- To customize your settings, edit optionsCustom.txt, -- and add only parameters which you want to overide if not camera then camera = { behaviour = 0, cam1_rotx_emax = -1.22, cam1_rotx_max = -0.99, cam1_rotx_min = -0.03, cam1_trackdist_max = 1500, cam1_trackdist_min = 100, cam2_rotx_emax = -1.22, cam2_rotx_max = -0.99, cam2_rotx_min = -0.03, cam2_trackdist_max = 1500, cam2_trackdist_min = 100, cam_autorot_speed = 25, cam_autozoom_max = 1500, cam_autozoom_min = 100, cam_autozoom_speed = 25, cameraDamping = 1, cameraShake = 0, cover_detection_dist = 1000, customsettings = 1, dng1_rotx_emax = -1.22, dng1_rotx_max = -0.9, dng1_rotx_min = -0.03, dng1_trackdist_max = 1500, dng1_trackdist_min = 100, dng2_rotx_emax = -1.22, dng2_rotx_max = -0.9, dng2_rotx_min = -0.03, dng2_trackdist_max = 1500, dng2_trackdist_min = 100, editorDevCam = 0, heromenu_rotx_emax = -1.22, heromenu_rotx_max = -0.99, heromenu_rotx_min = -0.03, heromenu_trackdist_max = 1500, heromenu_trackdist_min = 100, leaf_occlusion_fact_x = 1, leaf_occlusion_fact_y = 2, } I've got no optionsCustom.txt file since some options I wanted to change got either ignored or constantly overwritten by the game, even if I never changed a setting during the session So, in spite of the friendly warning at the top of this file, I changed whatever I needed changing in options.txt to somewhat fit my liking and then flaged that file as readonly, so the game does not rewrite it everytime. That of course makes all setting-changes I do in-game temporary, but thats a trade-off I can live with Here's how my max zoom looks like: and this is my min zoom: This is max zoomed while boss fighting: and this min zoomed: The camera has some strange behavior when entering a boss-fight, it pans and tilts and does some ... but with those settings it has never gone into satellite view. I have'nt tried those setting in a cave boss fight yet, but am fairly certain they will work fine aswell I hope this helps a bit best regards Coffee missing. Insert cup and press any key

Valkyr, in general you are correct. Only thing is that those sections you mention do alter all the items in a category, potions and other drops included. If you want to change something specific then -> I agree with Flix, thats sounds the most reasonable thing. You only have to dig a bit through the blueprint.txt to locate and note down the blueprint ID's for the potions, then get into drop.txt and lower their weightedprob value, that should do it. EDIT: I see you are trying to make your game a bit more difficult / interesting I just had a wicked idea, instead of altering their probability to drop you could maybe make them way more rare, that would be done in blueprint by altering minconstraints = { xxx , yyy , zzz }, where: xxx is the min level for this item yyy is the rarity, values 0..15, higher value = higher rarity zzz is the min dificulty level ( <- this last one is an assumption, I have not confirmed yet) (0 = bronze , 1 = silver .... ) and since you will already be diving into blueprint.txt to get the ID's maybe you'd like to try this one out instead best regards All the doors in Ancaria have been programmed to have a cheery disposition.

File Name: seraphim with 75% survival bonus File Submitter: tom.morrow File Submitted: 24 Oct 2013 File Category: Fallen Angel Seraphim Builds A savegame Seraphim with 75% survival bonus -------------------------------------------------------------- Description: -------------------------------------------------------------- This is a Sacred.2 v.2.43 save game. It should be compatible with all newer versions, including Ice & Blood and CM Patch Hero Myra, a Level 1 Seraphim with 75% Survival Bonus -------------------------------------------------------------- class Seraphim hardcore yes level 1 expert touch no faith Lumen mode created LAN - free -------------------------------------------------------------- -------------------------------------------------------------- ZIP-file contents (4 entries) : -------------------------------------------------------------- (Readme file) Readme.txt (folder) \saves (save file) \saves\hero99.sacred2save (save file) \saves\hero99.sacred2stats -------------------------------------------------------------- -------------------------------------------------------------- Installation: -------------------------------------------------------------- Extract the files from \saves folder into your savegame folder -------------------------------------------------------------- best regards Refilling wyvern pass water bottle... Click here to download this file

welcome back. This post will dive into some more changes on top of those we did in the last 2 parts. In my last post we were experimenting with the following structure in creatureinfo.txt newCreatureInfo = { type = 3400, . . . specialmountfor = 5, -- <- original value = 1 (seraphim class) -- <- mod.1 value = 5 (h.elf class) . . . } and how different values in specialmountfor affected the way the game deals with the sabertooth. Unfortunately specialmountfor does not accept any wildcards, so we need 1 structure for every class we want to use this mount for. And since we already have this section set up for the elf, I'm going to copy this section to a new one below this, changing the new one's specialmountfor value so it will be be pointing to the seraphim. This will be part.3.a: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.a - START -- purpose: new section to add the sabetooth also back for the seraphim -- newCreatureInfo = { type = 3400, . . . specialmountfor = 1, . . . } -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.a - END Hmm... now we have 2 almost identical structures. They only differ at the specialmountfor value. I doubt this would be enough to solve our problem, this may even crash the game, but lets try it. ( the Temperature Artifact reads 1 palm and 2 fingers.) The results were somewhat backwards crosswise unexpected: The game did not crash.! Test-Y, my elven mage, was offered the mount, bought it, mounted it, sold it and bought it back. This was a welcoming surprise, since I expected her having trouble with the mount at this point. Myra, the seraphim, had said mount already from the last test. She refused to mount it.! She sold it to Hugard but was not offered to buy it back since. OK, this is unexpected. If any class should have had a problem, I would have expected it to be the one who's values are defined 1st, since the 2nd section "may" have overriden the 1st one. But that does not seem to be the case, actually it "seems" that since the section already existed, the game did ignore the 2nd reference. Hm... there is a way to make sure this is the case: I can move section no.2 before section no.1 like this: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.a - START -- purpose: new section to add the sabetooth also back for the seraphim -- newCreatureInfo = { type = 3400, . . . specialmountfor = 1, . . . } -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.3.a - END newCreatureInfo = { type = 3400, . . . specialmountfor = 5, -- <- original value = 1 (seraphim class) -- <- mod.1 value = 5 (h.elf class) . . . } Now, with this order, 1st defined is the seraphim, if my last assumption stands, the game will treat this mount as exclusive for seraphim and ignore the 2nd section defining it for the elf mage. Testing this order confirmed the above. Test-Y, the elven mage, had said mount already equiped from the last test. She refused to mount it. She sold it but was not offered to buy it back. Myra (seraphim) had sold it before so she went and bought, mounted it, sold it and bought it back. well... Defining 2 creatureinfo structures that point to the same itemtype does not seem to solve this, as only the 1st structure is kept and any subsequent ones get ignored. That, in turn means, we need a new itemtype structure to point our copied creatureinfo at. Alright, this will get messy. We saw in the 1st post, where I was exploring the data relations, that there is a sequence of structures in at least 6 files, and 2 of them have 2 sections each. We will have to replicate this entire chain, if we are going to introduce a whole new itemtype. Alright then, lets note what changes/additions we are going to need, aswell as their ID's: research.1 file ...\shared\itemtype.txt we need to determine the MAX ID used by mgr.typeCreate(xxxxx to get the next 2 free ID's for the 2 new itemtype structures result: use 12001 for new "CLF_WARHORSE" and 12002 for new "CLF_ICON" NOTE: Having Ice & Blood (with or without CM Patch installed) will probably yield other MAX ID's for you. Make sure you take 2 unused ID's for this.! research.2 file ...\server\creatures.txt we need to determine the MAX ID used by mgr.createCreature to get the next free ID for a new creature structure result: use 2001 for new creature_id NOTE: Having Ice & Blood (with or without CM Patch installed) will probably yield a different ID for you. This file is huge and the ID's are not sequentially defined.! Make sure you take an unused ID for this.! research.3 file ...\server\blueprint.txt we need to determine the MAX ID used by mgr.createBlueprint(xxxx to get the next free ID for a new blueprint structure result: use 4001 for new blueprint_id NOTE: Having Ice & Blood (with or without CM Patch installed) will probably yield a different ID for you. The blueprints in this file are not defined sequentially.! Make sure you take an unused ID for this.! icons we are going to need 2 tripple pairs of icons, sources will be for "CLF_WARHORSE" : 003400a.DDS , 003400b.DDS , 003400c.DDS and for "CLF_ICON" : 010458a.DDS , 010458b.DDS , 010458c.DDS icons will be extracted from ICONS.ZIP archive into ...\pak\data\icons\items and renamed with target ID's (found by above research.1) for "CLF_WARHORSE" : 012001a.DDS , 012001b.DDS , 012001c.DDS and for "CLF_ICON" : 012002a.DDS , 012002b.DDS , 012002c.DDS part.3.b file ...\shared\itemtype.txt new "CLF_WARHORSE" section, copied from type 3400 with ID = research.1."CLF_WARHORSE" new "CLF_ICON" section, copied from type 10458 with ID = research.1."CLF_ICON" part.3.c file ...\shared\creatureinfo.txt replace seraphim's creatureinfo.type value from 3400 to research.1."CLF_WARHORSE" part.3.d file ...\server\creatures.txt new mgr.createCreature section, copied from the one with itemtype_id = 3400 with values: id = research.2.creature_id itemtype_id = research.1."CLF_WARHORSE" creature_id = research.2.creature_id tenergy_creature_id = research.2.creature_id part.3.e file ...\server\creatures.txt new mgr.addCreatureBpRelation section, copied from the one with blueprint_id = 1766 with values: creature_id = research.2.creature_id blueprint_id = research.3.blueprint_id part.3.f file ...\server\blueprint.txt new blueprint section, copied from the one with id = 1766 with id = research.3.blueprint_id part.3.g file ...\server\drop.txt locate droplist section Stock_specialmounts1 and add a new entry with blueprint_id = research.3.blueprint_id fortunately we have already moved the other mount for this character class (the elven mage) out of this section and into a whole new droplist. we have done that in mod part.2 .a through .c and it was tested and passed. No conflicts are expected here, both mounts should spawn on offer by trader part.3.h file ...\shared\iteminfo.txt new iteminfo section, copied from type 10458 with type = research.1."CLF_ICON" This outlines the plan for the next post. It should cover all needed changes/additions to replicate the sabertooth as another mount for the High Elf while retaining it also for the Seraphim. Backup not found: ( A )bort, ( R )etry, ( P )anic

Thats the 2nd time someone mentions satelite view on boss fights I have adjusted my view/zoom range to like 1200 or so, but never remember to have had a problem in boss fights If anything, in a boss fight I get a slight zoom in that is almost annoying well... almost = not quite enough to have bugged me to look into extending it yet I got to take a look at my settings and report back to you, maybe we can figgure out a combined setting where normal exploration zooms out well but boss-fights dont go that far out The... no. A... no... wait, sorry, that one sounded better in my head...

Last post raised an important point: droplists produce 1 out of x included items. That, in turn, leads to the importance of creating another droplist for the 5th item to show on offer by the exclusive mount trader. OK, back to modding. This is a continuation on top of the changes done in the last post, so with those still in place, I will now attempt to edit the file ...\server\drop.txt and change/add following: part.2.a remove the non-aspect windserpent from the traders Stock_specialmounts1 droplist part.2.b create new droplist containing the above removed non-aspect windserpent part.2.c induce the newly created droplist to the traders droppattern list This should effectively force the trader to produce 5 items for the H.ELF instead of 4. ( Before starting, remeber the Notes to SELF.! ) ok, here is part.2.a: mgr.createDroplist(1484,{ -- Stock_specialmounts1 id = 1484, . . . entry3 = { -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.2.a - START -- purpose: remove the non-aspect windserpent reference in this droplist -- -- - - - - - - - - - - - - - - - - - comment out the original section/values: start -- -- -- drop (offer) propability of windserpent -- weightedprob=255, -- <- original value = 2 -- -- <- mod.1 value = 255 (insanely high) -- -- blueprint=2132, -- }, -- entry4 = { -- weightedprob=2, -- blueprint=2136, -- }, -- entry5 = { -- -- - - - - - - - - - - - - - - - - - comment out the original section/values: end -- -- - - - - - - - - - - - - - - - - - replace with new section/values: start weightedprob=2, blueprint=2136, }, entry4 = { -- - - - - - - - - - - - - - - - - - replace with new section/values: end -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.2.a - END weightedprob=2, blueprint=2137, }, }) Well now, here we shifted values of original entry4 into entry3, shifted values of original entry5 into entry4 and removed reference to now empty entry5. By doing that shift we eliminated the entry values for the windserpent, that were originally contained in entry3. Next is part.2.b: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.2.b - START -- purpose: create new droplist containing the removed non-aspect windserpent -- mgr.createDroplist(1545,{ id = 1545, rank = 0, dmgpreference = 0, dmgprobability = 0, entry0 = { weightedprob=255, blueprint=2132, }, }) -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.2.b - END This new droplist now contains only the non-aspect windserpent, removed from the other list in part.2.a A small remark here: since we are creating a new droplist, we need a new, unused, ID for it. An ID that is unused in any other droplist, so ID #1545 may not be free in Ice & Blood. You need to check for its existance in this same file before trying this out. If that ID is taken then you need to keep searching the droplists until you find an ID thats unused. And on to part.2.c: mgr.createDroppattern(113,{ -- Priest id = 113, . . . entry3 = { expecttype=15, droplist=1526, minquality=14, -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.2.c - START -- purpose: add the new windserpent droplist to the traders droppattern list -- }, entry4 = { expecttype=15, droplist=1545, minquality=14, -- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mod.1 - part.2.c - END }, }) Pretty straight forward, right? Just adding another droplist into this list, making for a total of 5 entries. The new droplist entry should have droplist=xxxx, where xxxx = the ID used in part.2.b. This should now produce 5 mount types in offer by the unique horsetrader for the elf. Time to save and try it out. (the Temperature Artifact reads 2 palms and 1 finger.) The results were solid, everything as planed/expected: Myra, the seraphim, was getting a solid 3 offers, all 3 aspect related mounts, every time. Test-Y, the high elf mage, was getting 5 offers, all 4 of her original mounts plus the non-aspect sabertooth. Ok, now you may ask, why was I claiming my attempts where mostly failed? Well... what I just did was shifting a mount from one class to another. The original plan was to "unlock" the non-aspect mounts to be usable by all classes. This is something we have not achieved yet. If you remember in part.1 we changed the user/wearergroup of the "tradeitem" definition in 2 places (wearergroups value in blueprint.txt and model0Data.user value in itemtype.txt) Those changes are solid, we set them to "_DEFAULT", so nothing needs to be done there. However there is another spot we changed, one that effectively shifted the defined class of the user of this mount. This was made in the file ...\shared\creatureinfo.txt: newCreatureInfo = { type = 3400, . . . specialmountfor = 5, -- <- original value = 1 (seraphim class) -- <- mod.1 value = 5 (h.elf class) . . . } Now if only we could set also here a value to "_DEFAULT" or "suit-all-classes", we'd be done. Sadly, this value here does not seem to accept a wildcard, suit-all value. The value of this one seems to be pointing to either no class (value = 0) or a type ID of a specific class who can use it. Common mounts are missing this parameter altogether (assuming I guess a default value of 0) Setting this value = 0 for the sabertooth produces this result: Observe that the sabertooth now shifted over to the common mount slot. Mounting it in this case produces following result: Observe that the character buff is grayed out, and that all character combat arts are gone, obviously to be replaced by those of the mount. The game is treating it now as a common horse, one that has no Combat Arts defined. Ofcourse, since this is a common mount, Hugard stoped selling it. Next I set that value = 255, the mount shifted back into the unique mount slot, but the H.Elf is: "...doing alot of bad things but [she] will not sit on THAT thing.! " and a couple more interesting lines of refusal. Press any key... Nooo.! Not that one.!

WOWWW uhm... what just poped into my head? (wait for da gogo-multi-quote) Anything that helps the hYpe ... awesome incredible great work Cookiegurl is da best.!

My manual 's just the same, just checked it out, but IIRC (wich I doubt, since I have a permanent condition with memory leaks) there was an announcement, something like a last-minute addition that that page was "outdated" and the concept of mount-gear had to be scrapped On a sidenote, this looks to be right in my backyard right now, maybe, if ever I get around finishing that exclusive mount freeing thingy, I could have a look at this "feature" Hmm.. This game never has bugs. It just develops random features!