Unique mounts for all

[tom.morrow 89]

This was my latest obsession, namely unlocking the non-aspect-specific mounts, making them available to all classes.

Since they dont focus on an aspect this should have been easy going...

Well... it would have been, if...

In short, it is doable, fairly easy, IF I could access and append new names.!

Since I had to introduce new entities and I have no access to the naming, this was a dead end

 

Any help or ideas? Anyone had a try on this?

 

regards

 

Go to spriegel the schmitzel wertzen or something to that effect!

[Flix 5,116]

The only thing you can't access would be the names that display in game. So it sounds you need to be able to access and edit global.res. It's heavily encrypted but there's an editor Pesmontis made that some modders have been given access to. You might try contacting him and asking permission to use it.

[tom.morrow 89]

Yes, that would be one possibility.

Actually I was hoping to avoid messing with the global.res since its encrypted.

The idea was for a little brainstorming, there may have been another way around that I havent thought of yet.

But if anything else fails, I may take your advice and contact him.

Meanwhile, any ideas or thoughts are welcome

regards

I don't have a solution, but I admire the problem.!

[Flix 5,116]

Hmmm....why don't you lay out in more detail what values and which files you're editing and what roadblocks you've hit?

[gogoblender 3,071]

This was my latest obsession, namely unlocking the non-aspect-specific mounts, making them available to all classes.

Since they dont focus on an aspect this should have been easy going...

Well... it would have been, if...

In short, it is doable, fairly easy, IF I could access and append new names.!

Since I had to introduce new entities and I have no access to the naming, this was a dead end

 

Any help or ideas? Anyone had a try on this?

 

regards

 

Go to spriegel the schmitzel wertzen or something to that effect!

Can I get a vette?

 

 

gogo

[tom.morrow 89]

 

ROFL gogo

there aint no chevy mesh in dat game buddy, sowwy much

 

 

As for the "what have I done" for the mounts, that would make for a fairly long post

How should I post that? as a reply here or in another new thread?

 

 

regards

 

 

Computer load this, computer load that, never a thank you... Rude gamers.!

[SX255 630]

Post it here, as it is technicaly the continuetion of the topic. If needed, you can ask the admins to edit it out later.

We all want to hear this.

[gogoblender 3,071]

 

ROFL gogo

there aint no chevy mesh in dat game buddy, sowwy much

 

 

As for the "what have I done" for the mounts, that would make for a fairly long post

How should I post that? as a reply here or in another new thread?

 

 

regards

 

 

Computer load this, computer load that, never a thank you... Rude gamers.!

 

Oowah, caught that Halloween vette avatar huh

Post it here, as it is technicaly the continuetion of the topic. If needed, you can ask the admins to edit it out later.

We all want to hear this.

 

This sounds good, this way it's all kept together, and makes it easier for community readers to find your data/info

 

 

gogo

[tom.morrow 89]

Alright, I will track my attempt to unlock non-aspect-specific unique mounts for all classes

This post is about locating the relevant data, namely: How is this game Building my Horse?

At first, I happened upon a section in the file ...\client\soundprofile.txt that sparked my interest:

newProfile = {

profilename = "Mount Highelf Hippocampus",

type1 = 5549,

type2 = 9693,

type3 = 9996,

type4 = 10889,

.

.

.

}

mgr.soundProfileCreate(newProfile);

This section seems to define sounds for the Elven Unique Mout, called in the game files DJINN or Hippocampus

Nice Special points of interest here: type1, type2, type3, type4 !

So, here is a list of all the types of the unique mounts for the Mage and a list of sounds they make on various events

Naturally I followed that link into the file ...\shared\itemtype.txt searching with the ID of type1 I found:

newItemType = {

-- standard info

renderfamily = "RENDERFAM_TRANSPORT",

renderprio = 0,

family = "FAMILY_TRANSPORT",

subfamily = "SUBFAM_TRANSPORT_HORSE",

classification = "CLF_WARHORSE",

flags = "FLAG_HASSOUND + FLAG_PERPENDICULAR1 + FLAG_HASPREVIEWIMAGE",

weargroup = "WEARGROUP_DJINN",

-- 3d model + animation info

model0Data = {

name = "models/npc/ridingcreatures/hippocampus/v_hippocampus@std.GR2",

user = "WEARGROUP_INVALID",

},

-- logic bounding box

logicBox = {

minx=-30.732, miny=-47.094, minz=3.773,

maxx=29.715, maxy=64.864, maxz=117.923,

},

dangerclass = 0,

}

mgr.typeCreate(5549, newItemType);

OK, some basic info. Point of interest: classification = "CLF_WARHORSE"

But, being a creature, there should be more... so next was the file ...\shared\creatureinfo.txt

Searching with the ID of type1 (same as above) I found:

newCreatureInfo = {

type = 5549,

walkSpeed = 80,

runSpeed = 230,

fightDistMin = 75,

fightDistMax = 85,

gender = 2,

agegroup = 2,

validEquipSlots = "EID_RIDER + EID_STIRRUP + EID_CHEST",

defaultSMType = SMT_HERO,

behaviour = "WildAnimal",

specialmountfor = 5,

hair1Itemtype = 0,

hair2Itemtype = 0,

hair3Itemtype = 0,

tailItemtype = 0,

dangerClass = 0,

eBloodEffect = "BLOODFX_RED",

eq_fallback = { 5550 },

}

mgr.creatureInfoCreate(newCreatureInfo);

Now this is sweet, basic creature stats, all are here.

This section describes the mount, its speed, its equipment slots...

and a very special point of interest: specialmountfor = 5,

This tells the game that this creature is, indeed, a unique mount,

and its is "reserved" for the "creature" with type = 5 (the Mage)

Hmm... if there's a creatureinfo section, then there also may be a cretures section

On into the file ...\server\creatures.txt searching with the same ID produced:

mgr.createCreature {

id = 564,

itemtype_id = 5549,

name = "Mount_hippocamus",

behaviour = "Mount_generic",

dangerclass = 0,

groupmaxcount = 1,

elite_creature_id = 564,

probabilityforelite = 0.000000,

rank = 0,

tenergy_creature_id = 564,

livesremaining = 0,

unconscioustime = 5,

palettebits = "1111111111111111",

monstertype = 0,

faction_id = 1,

modelscale = 1.000000,

rise_from_ground = 0,

has_corpse = 1,

has_soul = 1,

can_strafe = 0,

}

Alright, more creature data.

Here we get a creature_id (along with a same elite_creature_id and tenergy_creature_id)

Searching with that new ID (= 564,) in this same file produced another section of interest:

mgr.addCreatureBpRelation {

creature_id = 564,

blueprint_id = 2132,

}

OK, here we got a link, a "relation" between my creature_id and a blueprint_id.

So, since we got a blueprint, lets dive into the file ...\server\blueprint.txt

Searching with our newly found blueprint_id we get:

newBlueprint = {

id = 2132,

name = "tradeitem_hippocamus",

palettebits = "1111111111111111",

dmgvariation = 0,

minconstraints = {1,13,0},

lvljump = 1,

usability = 0,

allotment_pmfpi = {1000,0,0,0,0},

uniquename = "tradeitem",

specialuseonly = 0,

itemtypes = {10460,},

wearergroups = {'WEARGROUP_HIGHELVE',},

}

mgr.createBlueprint(2132, newBlueprint);

Well then... here is a description of a tradeitem.

Special points of interest: WEARGROUP and another (different) itemtype

since this is a blueprint and a tradeitem, I decided to take a look at the file ...\server\drop.txt

The search with the above blueprint_id yielded:

mgr.createDroplist(1484,{ -- Stock_specialmounts1

id = 1484,

rank = 0,

dmgpreference = 0,

dmgprobability = 0,

entry0 = {

weightedprob=2,

blueprint=1766,

},

entry1 = {

weightedprob=2,

blueprint=1767,

},

entry2 = {

weightedprob=2,

blueprint=1765,

},

entry3 = {

weightedprob=2,

blueprint=2132,

},

entry4 = {

weightedprob=2,

blueprint=2136,

},

entry5 = {

weightedprob=2,

blueprint=2137,

},

})

Gotcha.! This is the list (of notably 6 items) of Stock_specialmounts1,

all the blueprint ID's of the tradeitems of the non-aspect-specific unique mounts.

Alright, on we go. From our search in blueprint.txt we found a new itemtype.

So back into the file ...\shared\itemtype.txt, searching with the new type (from blueprint) 10460:

newItemType = {

-- standard info

renderfamily = "RENDERFAM_ITEM",

renderprio = 0,

family = "FAMILY_ITEM",

subfamily = "SUBFAM_OBJ_INVITEM",

classification = "CLF_ICON",

flags = "FLAG_HASPREVIEWIMAGE",

weargroup = "WEARGROUP_INVALID",

-- 3d model + animation info

model0Data = {

name = "models/npc/ridingcreatures/hippocampus/v_hippocampus@std.GR2",

user = "WEARGROUP_HIGHELVE",

},

-- logic bounding box

logicBox = {

minx=-30.732, miny=-47.094, minz=3.773,

maxx=29.715, maxy=64.864, maxz=117.923,

},

dangerclass = 0,

}

mgr.typeCreate(10460, newItemType);

OK, some basic info here. Point of interest: the classification = "CLF_ICON"

So... it seems that unique mounts (and possibly normal mounts aswell) have each 2 sections in this file.

One for the actual mount type, with classification = "CLF_WARHORSE"

and another for the tradeitem type, with classification = "CLF_ICON"

And the link between them is described in the creatures.txt

linking type_id to creature_id in one section and creature_id to blueprint_id in another.

Now, since this is an itemtype, it should also have iteminfo...

A quick dive in the file ...\shared\iteminfo.txt searching with both known itemtypes brings up:

newItemInfo = {

type = 10460,

material = "0_default",

usability = 0,

invbreite = 5,

invhoehe = 5,

}

mgr.itemInfoCreate(newItemInfo);

I see.! so, only the "CLF_ICON" type has iteminfo.!

Makes sense, since this is a tradeitem (defined in blueprint.txt) and has a user (defined in itemtype.txt)

Finally, since there are itemtypes involved, there should also be some icons.

Both itemtypes have a tripple icon set in the archives.

Also, at least the tradeitem type (classification = "CLF_ICON") should have a description in the global.res

but that is a point I cannot confirm, since that file is encrypted

Detected system: windows 3.11 - switching screen resolution to 320x480 pixels.

[tom.morrow 89]

Ok, since this obviously is going to be a work-in-progress, I need you to bare with me.

Things may evolve or change, and I will post news and results when ever possible.

Well then, first things first.

In my last post I failed to mention that I'm running sacred 2 Fallen Angel updated to ver. 2.43

So, since there aint no Ice & Blood, at least one point is surely different from most of you.

Namely the part I talk about the droplist section in drop.txt:

Gotcha.! This is the list (of notably 6 items) of Stock_specialmounts1...

Obviously those who have Ice & Blood installed, will have 7 items in that droplist, the one extra I'm missing will be the exclusive mount for the Dragon Mage.

Also keep in mind that some ID's may differ for the Ice & Blood version of the game.

It is highly unlikely (because of backward compatibility issues), but still "may".

Dont take my word on any of this for granted, since the game itself states: May contain Nuts.!

Aight, on to Part 2.

This part is about my (mostly failed) attempts at adding another unique mount for my Elf mage

"How can I tell the game to Build and offer me Another Type of Unique Mount?"

Well then... 1st thing I went to try was to change an exclusive mount from one class to another.

Since this change would be fast with minimal effort, I decided to take this as a proof of concept, just to make sure the game would behave "normal" and not crash by my mod.

My High Elf kept asking for a sabertooth mount, so 1st I went another time through the process of locating the data, taking notes of all the ID's specific to the non-aspect Sabertooth.

(see previous post: "locating the relevant data / How is this game Building my Horse?")

The final changes for mod.1 are following 4:

1. in ...\shared\creatureinfo.txt

newCreatureInfo = {

type = 3400,

.

.

.

-- mount-for-class definition

specialmountfor = 5, -- <- original value = 1 (seraphim)

-- <- mod.1 value = 5 (h.elf)

.

.

.

}

The only change in this section was to replace the value of specialmountfor = x

Originaly this was 1 (an exclusive seraphim mount) and I changed it to 5 (exclusive for H.ELF)

2. in ...\server\drop.txt

mgr.createDroplist(1484,{ -- Stock_specialmounts1

id = 1484,

.

.

.

entry0 = {

-- drop (offer) probability of sabertooth

weightedprob=255, -- <- original value = 2

-- <- mod.1 value = 255 (insanely high)

blueprint=1766,

},

.

.

.

entry3 = {

-- drop (offer) probability of windserpent

weightedprob=255, -- <- original value = 2

-- <- mod.1 value = 255 (insanely high)

blueprint=2132,

},

.

.

.

})

These changes raise the drop probability (item being on offer by trader) to insane levels for both the non-aspect sabertooth (blueprint=1766) and the non-aspect windserpent (blueprint=2132).

By themselfs these changes are rather harmless, just a way to make sure we get them offered every time, instead of having to run back and forth to other traders to force-refresh their offers

3. in ...\server\blueprint.txt

newBlueprint = {

id = 1766,

name = "tradeitem_frosttiger",

.

.

.

uniquename = "tradeitem",

specialuseonly = 0,.

itemtypes = {10458,},

-- tradeitem target wielder/wearer

wearergroups = {'WEARGROUP_DEFAULT',}, -- <- original value = {'WEARGROUP_SERAPHIM',},

-- <- mod.1 value = {'WEARGROUP_DEFAULT',},

}

mgr.createBlueprint(1766, newBlueprint);

The only change in this section was to replace the value of wearergroups = { xxx, },

Originaly this was = {'WEARGROUP_SERAPHIM',}, making it usable by (or tradeable to) only the seraphim.

I changed it to {'WEARGROUP_DEFAULT',}, effectively allowing all classes to wield/wear it

4. in ...\shared\itemtype.txt

newItemType = {

-- standard info

.

.

.

model0Data = {

name = "models/npc/ridingcreatures/Frosttiger/c_tiger.GR2",

-- "CLF_ICON" target user definition

user = "WEARGROUP_DEFAULT", -- <- original value = "WEARGROUP_SERAPHIM",

-- <- mod.1 value = "WEARGROUP_DEFAULT",

},

.

.

.

dangerclass = 0,

}

mgr.typeCreate(10458, newItemType);

The only change in this section was to replace the value of user = xxx,

Originaly this was = "WEARGROUP_SERAPHIM", making it usable (equip-able I think) only by the seraphim class.

I changed that to "WEARGROUP_DEFAULT", effectively allowing all classes to use/equip it

Notes to SELF:

1. The 1st change in creatureinfo.txt is relevant to the actual mount type, the other 3 changes relate

to the tradeitem/icon class type, hence the different (item)type ID's involved

2. Its generally a good idea to backup all the game-text-files aswell as your savegames

when doing such changes, just in case something goes BOOOM. Better save than sowwy.!

3. Run multiple tests each time, make sure observations are solid.!

4. Remember to document the readings on the Temperature Artifact.!

I have a seraphim and a H.ELF both on SP with Hugard opened as a trader of exclusive mounts.

Results of mod.1:

(the Temperature Artifact reads 1 palm and 2 fingers.)

Testing on my seraphim (Myra) yielded expected solid results:

She had said mount already equiped. Once I loaded her she was able to summon the mount, but refused to mount it. She kept saying that this "creature" was not for her class.

Which makes sense, since the mod specifically altered its creatureinfo to define it for the H.ELF class.

Hugard was offering the 3 aspect-mounts for sale but not the non-aspect one.

Hugard was also offering to buy back the now useless (to her) mount, but would not offer to sell it back again ever after, it wasnt on his list.

The tests with my H.ELF (Test-Y) yielded some unexpected results:

She had the non-aspect Windserpent equiped, could summon and mount it without a problem.

At 1st, whenever I went to Hugard, he was offering her all 4 Windserpent types (3 aspect-related and 1 non-aspect-related) but, sadly, not the moded sabertooth

No matter how many trips back and forth I went to other traders to force-refresh offers, I still only got those 4 windserpent types from Hugard.

Finally I sold my windserpent and force-refreshed his stock once more and, LO and BEHOLD, suddenly there was a sabertooth on offer, but had somehow replaced the offer of the non-aspect windserpent. Now this was getting weird.

More force-refreshing yielded same results until I went and bought the sabertooth.

This is what she looked like (btw this picture features 4 of my mini-mods all visible):

Sweet, she could mount it no problem, but subsequent requests to trade with Hugard were still missing offers on her non-aspect windserpent.

Assumption 1.

The game seems to be going to lengths to offer a replacement mount for my chosen type.

As long as I had the windserpent equiped, I was offered windserpents.

Once I sold it and got the sabertooth, I kept getting sabertooth replacement offers.

At least for the non-aspect type, since the aspect-related mounts were on offer constantly.

Finally I sold the sabertooth and continued force-refreshing offers without any success.

At any given point only 4 types of mounts were on offer: 3 aspect related windserpents and the non-aspect sabertooth.

At some point I got tired porting back and forth and decided to reload from the backup.

So I started out again with the non-aspect windserpent equiped, and mounted on it, I went to Hugard and this is what he was offering:

Well then, assumption 1 is either wrong, or, more likely, there are more factors at play here.

It was starting to look like the game was "sensing" that since I went to the trader with a mount already equiped, it should try to offer me at least an upgrade/replacement for that specific type, along with the 1 of each other type, but max 4 items in total.

When I was expecting 5.

Hm... and why was I expecting 5? This looks like an error in logic on my behalf.

Since the non-aspect sabertooth and windserpent both share the same exclusive mount type.

Furthermore, they share the same droplist, and most likely, only one item of this droplist can drop/spawn at any given time, so since that trader has 4 droplists, he can spawn a maximum of 4 offers.

This last one seems the most possible reason.! I will have to continue this investigation.

(the Temperature Artifact reads 4 fingers at this point.)

Join us on our next episode of "Pigs in Space".!

best regards

We don't have bugs, we have dragons.!

Edited October 22, 2013 by tom.morrow

[tom.morrow 89]

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.!

Edited October 23, 2013 by tom.morrow

[tom.morrow 89]

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

[tom.morrow 89]

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.

[tom.morrow 89]

.

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.!

Edited October 26, 2013 by tom.morrow

[tom.morrow 89]

.
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...

 

 

The Wheel of Time turns, and Ages come and pass, leaving memories that become legend.
Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again.
In one Age, by some called the Third Age, an Age long past, an Age yet to come,
a wind rose at the hills near a small elven village. The wind was not the beginning.
There are neither beginnings nor endings to the turning of the Wheel of Time.
But it was a beginning...

 

 

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.!

Edited October 27, 2013 by tom.morrow

[Flix 5,116]

You can have X items based on the same itemtype but with different names,

its the blueprints that get named.

 

This is one of the few things I could have told you beforehand. I kept meaning to really examine what you were doing with the scripts but I guess I missed the need for that info.

 

For example, when making the new Dragon Mage set Auspicious Powers, I won't actually have to mess with itemtypes.txt or surface.txt. I'm just going to direct the blueprint to use the proper itemtypes that are part of the Leather Standard Set, apply the bonuses, and name it in global.res. This was actually my plan for all three new sets originally, but I started editing textures which created the necessity to add the custom created stuff to surface and itemtypes.

[tom.morrow 89]

.

 

You can have X items based on the same itemtype but with different names,
its the blueprints that get named.

.
This is one of the few things I could have told you beforehand. I kept meaning to really examine what you were doing with the scripts but I guess I missed the need for that info.

For example, when making the new Dragon Mage set Auspicious Powers, I won't actually have to mess with itemtypes.txt or surface.txt. I'm just going to direct the blueprint to use the proper itemtypes that are part of the Leather Standard Set, apply the bonuses, and name it in global.res.

No worries, I had arrived there since before my 1st post, as I mentioned there the need to name a resource.

I just had to prove it, so backtrack the whole process by scripting (again) and documenting the changes and results,

since a few asked what I had done so far.

 

 

Mounts are a bit more complicated, more expanded upon.
As you can see, they are build with info in at least 8 files as they combine event sounds and creature data on top of the standard itemtype / blueprint / texture data-chain of static items.

And, I have a suspicion that they actually require 2 named resources, as they require 2 icon sets, but make use of only 1 of each.!.!
The explanation should be that they are described / created through 2 itemtype data-chains, one for the static / tradeitem and another for the creature.


On a side-note, how is the naming-resources request initiated? How far have you gotten on it? Have you had any feedback? We can PM about that if you preffer.

This was actually my plan for all three new sets originally, but I started editing textures which created the necessity to add the custom created stuff to surface and itemtypes.

Dont forget iteminfo.txt entries and the icon sets to make this all work.
Since what you do are whole new itemtypes, each of them need those.

For example, without the iteminfo entry, your item may drop but will not be pick-able
Just a another thing to keep in mind

You fight like a dairy farmer!

[SX255 630]

That’s quite a lot of R&D you put into this mod. I’m glad you were successful.

Won’t lie; I didn’t read the enormous details on how you accomplished it.

 

Can you upload the final mod for all of us to try?

And can you now unlock all the mounts for all the classes?

[tom.morrow 89]

.

Can you upload the final mod for all of us to try?
And can you now unlock all the mounts for all the classes?

.

 

There is a quick answer to both those questions and quite a long explanation.

Sadly SX255, the quick answer is: no.

Since each mount (each specific one) needs at least 1 named resource
and I assume it needs 2, because creatureinfo is in a way like blueprint
and creatures also need names and mounts use both those file-structures.

My partial success, which I reffered to as "mostly failed", is using 2 uniquely named items,
erasing them from existance and highjacking their names to build 1 mount.
I tried with 1 instead of 2, but it failed, which I believe is due to the above explanation.

So, for example, if I wanted to make 1 new sabertooth for DM and dryad and HE, I would need 6 names in total.!
If I wanted to make 1 sabertooth for each character class I would need 12 names.
If I wanted to make all non-aspect mounts available to all classes I would need...
:opens calculator:
I would have to use 84 unique name resources, cut this in half if I am wrong in my assumption.

Anyway, even if only 1 named resource is needed for each, my progress is limited,

much the same way as Flixs' new DM sets are,

namely, there can not be a blueprint of a new type without access to a name.

Actually that was the whole point of the 1st ever post I made in this thread.
To poll the community if anyone in any way has found a way around this that I could not think of
( due to being biased by the research,
it happens sometimes that I fail to see the woods because they are hidden by all the trees )

That also is the reasons, apart from your request, to why I went into such detail
re-doing all my mods and documenting every detail aswell as my reasoning for each step.

 

I know its a pain to read through all the research.

 

Anyone who wants to get a general idea, can skip all the intros, jump to THIS POST

that outlines the final changes and continue from there.

 

 

I'm not giving up on this.. there may still be hope.!

 

 

best regards

 

 

This may take a while, get yourself some coffee...

[Schot 407]

Interesting puzzle tom. I wish I had the experience to offer you some help. As much as I would have loved to had made some mods, I never did have enough time to try it out. Even now I've got such a line up of projects to do, lol. The only thing that occured to me while reading the summary post you linked to, "THIS POST" as you named the link, was when I read the below line from you:

 

Those changes never suceeded for the lack of a wildcard in one specific place (creatureinfo.specialmountfor).

 

I'm sure you already considered this and probably even wrote it somewhere but what came to my mind is that Horses are flexible creature mounts with regards to who can ride them. Are you able to borrow/replace data from the horse mount?

[tom.morrow 89]

.

The only thing that occured to me while reading the summary post you linked to, "THIS POST" as you named the link, was when I read the below line from you:

 

 

Those changes never suceeded for the lack of a wildcard in one specific place (creatureinfo.specialmountfor).

I'm sure you already considered this and probably even wrote it somewhere but what came to my mind is that Horses are flexible creature mounts with regards to who can ride them. Are you able to borrow/replace data from the horse mount?

 

 

.

 

Quite a brilliant observation, if I may say so.

 

 

Indeed I did. The result was that the special mount got treated as a normal hose:

It got shifted to the left mount slot (reserved for normal horses) and the user Combat Arts were removed,

to be replaced with whatever that "horse" would have defined as his Combat Arts.

Having non defined per se, the result can be observed at the bottom 2 pictures of THIS POST

DA WEEP GRANNA WEEP NINNY BANG!

Edited October 27, 2013 by tom.morrow

[Schot 407]

Awh well. I had no doubt you'd explored that option already but I had to at least put it out there just in case. ^^ I'm coming into this a little late and I hate playing catch up by trying to digest several days worth of detailed content. Pardon me now cause I may get a bit of indigestion and blurt some already saids.

 

Write a new quasi wildcard that somehow encompasses all classes for your template to refer to? Or is that blocked by an invincible global.res?

[tom.morrow 89]

 

No worries at all there buddy, I know how hard it is to catch up on a few hundred lines of code and rambling...

 

 

Eh...?! a "wildcard" is something defined and used by the game engine, as such its a predefined thing for the scripts.

In many ways it is constant with special meaning to the game itself.

I dont have the means to induce another constant into the game code and force the code to recognize it

And even if I had, I doubt it would fare well to do so.

 

As for the actual block, you are right, in essence it is the restrictions imposed by the encrypted global.res.

Given access to that, one could make the needed 84 named resources and build the whole thing up.

 

It would be quite a pain building 84 new blocks of script in itemtype and at least 5 times as many across 5 other files.

Quite a pain compared to a wildcard solution, if one existed, but still possible given access to names.

 

 

 

 

Overclocking CPU: 3,0GHz...3,2GHz...3,6GHz... OOPS, I broke your CPU!

Edited October 27, 2013 by tom.morrow

[Schot 407]

I was thinking quasi wildcard in terms of specifying each class within a group to be used as a wildcard rather than a wildcard who's logic was more along the line of all classes. So rather than an implicit(all classes) wildcard, an explicit(these classes) wildcard. Though now that I think of it, it would be worth it to attempt just typing out the multiple IDs in specialmountfor. Again I'm sure you tried that too.

 

Is it possible a wildcard exists but not found? In that a wildcard was created, say for testing.

[Flix 5,116]

.

 

 

On a side-note, how is the naming-resources request initiated? How far have you gotten on it? Have you had any feedback? We can PM about that if you preffer.

 

 

 

This was actually my plan for all three new sets originally, but I started editing textures which created the necessity to add the custom created stuff to surface and itemtypes.

 

 

Dont forget iteminfo.txt entries and the icon sets to make this all work.

Since what you do are whole new itemtypes, each of them need those.

 

For example, without the iteminfo entry, your item may drop but will not be pick-able

Just a another thing to keep in mind

 

 

You fight like a dairy farmer!

 

Did I forget that? Maybe I did! I'm glad you're around. I made the icons already.

 

 

As far as I can tell, for items, blueprint.txt is the "last stop" before global.res names the item. There's are entries within global.res that call for the Loka-ID and then the corresponding display text. A Loka-ID example is "BLUEPRINT_4567" For creatures it may something else instead of 'BLUEPRINT.' With the editor there are columns for:

* hashes from STRING/TEXT Loka IDs.

* text/string to be displayed in-game.