46 réponses à ce sujet

[stuntpope]

Reynen Starfyre wrote...

stuntpope wrote...

To make this safe:
1) create a test module to do this in - don't try to do it to the single player campaign.
2) don't change any core scripts - just use new scripts and hook them up to the events you need to change. Then pass back to the core scripts for anything you don't need to change.
3) never put anything in your modules core override folder - always use the module override instead
4) always empty your packages core override folder before playing.

I've been successfuly doing this for a while now with no damage to my single player game since I discovered about the junk going in the override folder..

1: This was done with a test module, but you have to include it in the SP if you want it to work.

2: It won't work properly like this because of what you have to change.  For example you have to change the values in 2da_constants_h.  You can't have the file call itself if you are making changes to it.  Also outside scripts will not override the cores scripts in this case.

3: I have to use: name/mydocuments/bioware/dragonage/addins/modulename/core/override directory because when put in the name/mydocuments/bioware/dragonage/addins/modulename/module/override directory  the changes never worked.

If you can create a class without doing what I did then by call means prove me wrong, I WOULD LOVE AN EASIER WAY TO DO THIS.....

Reynan, thanks for taking the time to respond I think it will be good for us to sort out the best way to do this. Many heads are better than one.
1. assuming you want this to work in the single player game - I have strong reservations about whether you are actually going to break some plots - but I guess time will tell.
2. When doing my backgrounds alterations I found I could just create my own constants file to extend/change what was there already. Then you just need to make sure there is no code referencing the original constants. Perhaps this was only possible because I was replacing all the backgrounds but I'm sure there's a way we could make it work for extending classes too. Was there a reason you had to change some of the existing class constants and not just add your new class at the end?
3. I have not had this problem but perhaps it has to do with extending a module vs making a stand alone. What I have found instead is that if I put things in the name/mydocuments/bioware/dragonage/addins/modulename/core/override folder then they affect every module I have installed.

I will try and get my tute for changing backgrounds up sometime in the next 48 hours. After that maybe I can have a look at seeing if we can take a similar approach to classes. I grant that it may be more complicated.

[Reynen Starfyre]

2. When doing my backgrounds alterations I found I could just create my
own constants file to extend/change what was there already. Then you
just need to make sure there is no code referencing the
original constants. Perhaps this was only possible because I was
replacing all the backgrounds but I'm sure there's a way we could make
it work for extending classes too. Was there a reason you had to change
some of the existing class constants and not just add your new class at
the end?

Actually yes there was a very big reason why I could not add it to the end.  This statement here in sys_chargen_h

int Chargen_GetEquipIndex(int nRace, int nclass, int nBackground)
{
    return nRace * 1000 + nclass * 100 + nBackground;
}

3404 = human / cleric / magi bg

If I were to add it to the end of CLA_base it would be 26.

Following the formula above: 

3000 = human
2600 = cleric
4 = magi
----------------------
5604 = BROKE GAME because it sees it as this:

5000 = no race
600 = spirithealer specialization
4 = magi

You cant increase the above formula either because it ties in with monsters / NPC and you would have to alter EVEYTHING with it.

See my delima

------------------------------------------------

As for the person who wanted to do everything as a guest.....I already tried that and I got hacked...leeched...and took me hours to fix what a "Guest" did.  No thank you, I'll lock it down from now on.  It takes 1 minute to register and it's free.  If you can't understand the reasons needed for this you can go elsewhere.  Sorry I'm not bieng abused again.  1st time = shame on you, 2nd time = shame on me.

[stuntpope]

oh dear - yes I have seen that formula from when I was editing backgrounds. Fair enough then.



But why not just add a new set of constants and use those instead of the original ones in 2da_constants_h? Then just make sure your scripts use those instead of the original ones. Since you will be using your own scripts wherever they are used anyway the original ones then never get used.

[Reynen Starfyre]

stuntpope wrote...

oh dear - yes I have seen that formula from when I was editing backgrounds. Fair enough then.

But why not just add a new set of constants and use those instead of the original ones in 2da_constants_h? Then just make sure your scripts use those instead of the original ones. Since you will be using your own scripts wherever they are used anyway the original ones then never get used.

I tried that, however the problem is so many scripts include the original 2da_constants_h file.
I would have to modidy EVERY file that included the original and change it to include my own.
Which would defeat the purpose of trying to seperate things.

The same with adding new abilities, I tried using new script files for them and the game choked on itself.
It's hard coded to use the original files for certain things it seems....

I hope in time I might be able to figure another way around it OR someone else will.
In the meantime I'l focus on building the mod and hope to have an epiphany.

[stuntpope]

You don't have to discard the original constants file completely. There is no problem having your own myModule_2daConstants_h file as well as the other one. The only place you need to include your new file is when you are wanting to use those new constants, i.e. in the scripts that you will be modifying anyway. The two contsants files can exist in tandem and be inluded from the same script so long as your constants are unique, so they should be MYMODULE_class_WARRIOR etc.

It really doesn't matter that there's still another constant called class_WARRIOR that points to a different int so long as it is never used. Since you will need to overrite any events that are using those constants anyway, it doesn't seem like a huge deal to update the constant names in your custom event handler.

It would have been really good though if we could have added classes to the end of the list as then we wouldn't have to rename the others. Maybe there is another way around the formula issue. I will have to have a look and see where else it is used.

I have finished writing my backgrounds tutorial, I just need to add some pictures and transfer it onto the Wiki. Hopefully I can get that done tonight (Aus time). I think that will make it clearer what I am talking about.

Edit - for some reason the forum doesn't like 'class' in uppercase.

Modifié par stuntpope, 25 novembre 2009 - 01:06 .

[Reynen Starfyre]

I'll try some stuff out.  I wish you luck on the formula if you find anything let me know!

[stuntpope]

I posted my tutorial on the wiki: social.bioware.com/wiki/datoolset/index.php/Backgrounds_tutorial

[stuntpope]

You know - the more I look at it the more I think Bioware accidentally crewed up that formula.

Why would you reserve only 9 spots for classes but 99 spots for backgrounds? I'm sure it was meant to be the other way. I mean in most cases if you are modifying backgrounds you will be content to replace the existing ones and they only occur in character gen so 9 is plenty, but with classes, there are all the specialisations and so on.



I will have to track down the other places you say this formula is used and see if we can alter it. Certainly there is nothing special about what it does in the backgrounds 2DA. It is just used for a lookup. There is no conversion going back the other way, but it does need to be unique.

[stuntpope]

I've had a look and as far as I can see that formula is only used in character creation. Specifically in this method



int Chargen_GetEquipIndex(int nRace, int nclass, int nBackground)

{

return nRace * 1000 + nclass * 100+ nBackground;

}



Which is not used anywhere other than to look up the background_defaults table. So why not change that formula to 1000*raceID+100*backgroundID+classID and then modify the table IDs accordingly (along with the chargen_preload ones). Then you could use the M2DA approach to adding a class and give the new class any ID in the range 26-99. Although I suggest leaving some room for Bioware to add some more of their own. Or even better make the formula 10000*raceID + 1000*backgroundID + classID and give yourself lots of room.



It would just mean overwriting the couple of events that call that function in sys_chargen - which you have to do anyway - to call a custom function from your own include file.

[pokemaughan]

I'd download it but I really can't be bothered to join another random site- host somewhere else please

[Rigortauri]

stuntpope wrote...

You know - the more I look at it the more I think Bioware accidentally crewed up that formula.
Why would you reserve only 9 spots for classes but 99 spots for backgrounds? I'm sure it was meant to be the other way. I mean in most cases if you are modifying backgrounds you will be content to replace the existing ones and they only occur in character gen so 9 is plenty, but with classes, there are all the specialisations and so on.

I will have to track down the other places you say this formula is used and see if we can alter it. Certainly there is nothing special about what it does in the backgrounds 2DA. It is just used for a lookup. There is no conversion going back the other way, but it does need to be unique.

indeed, makes more sense in having more classes then backgrounds..
on the other hand.. 6 is the limit of all 3 components,  playable i mean..

I have tried it with 7 races to see if the 7th icon would go to the next line.. unfort it only took the first 6. (bummer)
guess we have to dig in the gfx files to activate the 7th symbol (hmm that did sound very stargate..)

but i am interested in what reynen mentioned to me on the damods forum, is to have a different spellist for a class depending on the background.

[stuntpope]

yes 6 is the limit for the chargen GUI so 6 backgrounds is all you need. But for classes the 6 limit is only for core character playable classes. Specialisations etc extend the need for more class spots and since Bioware left us no room to add low numbered class IDs I think the best option is to change the formula..

[Reynen Starfyre]

stuntpope wrote...

I posted my tutorial on the wiki: social.bioware.com/wiki/datoolset/index.php/Backgrounds_tutorial

How did you get that posted on the wiki?
I can't post any tutorials on there.
I'll add it to the wiki if I can.

[stuntpope]

I just realised the way around the formula issue - Bioware may have even intended it this way. You just have to make your custom class ID a multiple of 100 and you still maintain the uniqueness of the formula result. So with classID=100 and raceID = 2 and backgroundID = 4 you get

2*1000 + 100 * 100 + 4 = 12004

change the classID to 200 and you get 22004 and so on. Those are the numbers that you put in the lookup.
This works since the classID*100 is always a multiple of 10000 and so ends in 4 zeros.

Edit - just realised that won't leave enough space for races to expand so better make it 1000 instead of 100; It does start putting limits on the max raceID though.

Modifié par stuntpope, 27 novembre 2009 - 01:08 .

[Rigortauri]

stuntpope wrote...

I just realised the way around the formula issue - Bioware may have even intended it this way. You just have to make your custom class ID a multiple of 100 and you still maintain the uniqueness of the formula result. So with classID=100 and raceID = 2 and backgroundID = 4 you get

2*1000 + 100 * 100 + 4 = 12004

change the classID to 200 and you get 22004 and so on. Those are the numbers that you put in the lookup.
This works since the classID*100 is always a multiple of 10000 and so ends in 4 zeros.

Edit - just realised that won't leave enough space for races to expand so better make it 1000 instead of 100; It does start putting limits on the max raceID though.

stunt,
i took your background tut approach to add 3 more custom races, and so far the only core file i had to overwrite with my own is the constants file.

i now have 6 playable races (4 different human, elf + dwarf) and 6 deities/paragons instead of backgrounds

but i did noticed that GDapp is quite sensitive, often a little change crashes the game.
for example, i now have for all human races default_warrior.utc  and when i change that to default_hm_noble.utc .. it crashes.
after two weeks of playing with the toold set, i almost got no hair left..

[stuntpope]

@Rigotauri



Yes it sure is sensitive and doesn't handle errors very gracefully. I don't think you should have to modify any core files. Are you sure you couldn't have made your own constants file to extend the existing ones the way I did in my tute?



I was having the same thought today about using the backgrounds for selecting deities. Good stuff. Glad you are making some progress.

[Rigortauri]

stuntpope wrote...

@Rigotauri

Yes it sure is sensitive and doesn't handle errors very gracefully. I don't think you should have to modify any core files. Are you sure you couldn't have made your own constants file to extend the existing ones the way I did in my tute?

I was having the same thought today about using the backgrounds for selecting deities. Good stuff. Glad you are making some progress.

well the problem lies indeed in the race+class+bg formula.

since i shifted all races up a bit so that 1 through 6 are the playable races, it complains about the double declaration of the constants.

the problem i have now, and i cant figure out what it is, is why it doesnt accept my default_.utc
the moment i change that in the bg_defaults.gda and chargen_preload.gda it crashes...

isnt there some errorlog file?

edit, it crashes even when trying to change it all.. for example to an existing utc char like default_elf_dal_r.utc

Modifié par Rigortauri, 27 novembre 2009 - 04:23 .

[ladydesire]

Rigortauri: I would suggest moving your new races above the existing ones; I've added a race to my game (the halfling) by placing it at ID 12 and it works just fine; I just need to wait for someone to complete a modeling tool that will allow me to scale the human model down, since editing the APR_base file to downscale it doesn't seem to work.



stuntpope: That approach to the formula seems to be in line with what I have thought as well.

[Rigortauri]

ok thanks for the tip, will try it out.

[Rigortauri]

ladydesire wrote...

Rigortauri: I would suggest moving your new races above the existing ones; I've added a race to my game (the halfling) by placing it at ID 12 and it works just fine; I just need to wait for someone to complete a modeling tool that will allow me to scale the human model down, since editing the APR_base file to downscale it doesn't seem to work.

stuntpope: That approach to the formula seems to be in line with what I have thought as well.

i did make a new thread for the races part, since this one is supposed to be about classes
http://social.biowar...72/index/321266

Modifié par Rigortauri, 27 novembre 2009 - 09:27 .

[Rigortauri]

embedded images and dascript tags to the wiki.
also added page to the tutorial list

social.bioware.com/wiki/datoolset/index.php/Add_A_New_class_Tutorial

[Sarodin]

How would I go about using this tutorial to add a class that is not for character generation, but instead for a party member... Sort of like how shale has his own set of talent trees called "Shale". I ask this as I would like to create unique classes for some of the NPCs, in particular the ones who teach Specializations.