Home » MODDING HQ 1.13 » v1.13 Modding, Customising, Editing » v1.13 XML Customization » prof.dat -> xml
|
|
|
|
|
|
|
|
| Re: prof.dat -> xml[message #181473]
|
Tue, 15 April 2008 15:15  
|
|
 Lt.Havoc |
 |
Messages:34
Registered:April 2006
Location: Germany |
|
|
Nope, I say we need a GUI, then I dont know how to edit XML in notepad! We are not all Profi coders and modders who mod games efore thier first coffee, ya know. Also, what are 20 sec of wating? Notepad needs the same amount of time to load a huge XML file. The XML editor is one of the best things I ever saw, then its really easy to use that every dumbass can change the XML files.
So, if we externalized the prof dat, I also want XML editor support so I can change everything I want without scrolling though endless lines of numbers and letters, I mean, you can eaisly search with the editor, not with a notepad.
So, I say, brake it so it fits a GUI.
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: prof.dat -> xml[message #181493]
|
Tue, 15 April 2008 16:09
|
|
| BirdFlu |
 |
Messages:438
Registered:September 2007
Location: Lampukistan |
|
|
Easy guys. The xml editor is the last thing we need (i said the LAST, i didn't say we DON'T need it). There is still a lot that has to be done before.
We have to define a proper structure for the files. I don't really like long parameter lists, that is if you consider the xml file as a tree
(not a real tree), then i would rather have depth (not too deep) instead of breadth.
Once the file structure is stable (only the basic structure, the order of the children of a node should not matter much), we actually have
to USE the file in the game. Without that the whole discussion is pointless. We also have to decide where we want to use the files.
The data in the prof.dat file describe only the initial stats of a merc, but these stats change after some while. These changes are
saved in the savegames, i suppose. So maybe we want to save the changed merc profiles as xml files too, or maybe even save the
savegames itself as xml files.
When all this is done, then we can start with the xml editor. Until then just grab a regular xml editor, it will do the job just fine.
Report message to a moderator
|
|
|
|
|
| Re: prof.dat -> xml[message #181534]
|
Tue, 15 April 2008 18:39
|
|
| the scorpion |
 |
Messages:1834
Registered:September 2004
Location: CH |
|
|
i'm not really sure about prof.dat anymore.
these days, i personally would prefer externalising things about characters that ARE NOT EVEN IN PROF.DAT YET but hardcoded in the actual exe first, otherwsie, prof.dat in xml format will still bear a lot of severe restrictions
maybe that shoud come first, felxibility first, then the possibility to amend stuff to prof.dat
take for example the playable character slots. If they were arbitrary rather than limited to very specific numbers, modmakers would gain countless times more than what they would if 10 characters can be amended to the list in prof.dat
take for example the hardcoded npc/ rpc placement routines: if they would be editable, modmakers could use all existing slots for all purposes
the same about trader ID's. make any unused char a trader as we like in, say, traders.xml.
all of these things are in fact more limiting that prof.dat/ proedit the way it is now.
maybe both can be done at once: when you externalisze prof.dat to new xml's, maybe externalising those important values that are not even in prof.dat as well to the same xml's would be the way to go. But it would complicate things even more.
as mentioned before, i'm unsure as to what has to be done first. what's important is to find a solution that gives the most gain. There are many ways in which prof.dat hinders other development, that's why it should be bought into an easier format.
people have accused me that viewing things that way is shortsighted. But i'd like to have brought the aspects enumerated above to people's knowledge before prof.dat is externalised and people recognise that there are still various limitations.
Report message to a moderator
|
Sergeant Major
|
|
|
|
| Re: prof.dat -> xml[message #181569]
|
Tue, 15 April 2008 21:27
|
|
| BirdFlu |
|
Messages:438
Registered:September 2007
Location: Lampukistan |
|
|
@ the scorpion : are you talking about having an arbitrary number of mercs with arbitrary/multiple group affiliations?
The two main data structures in the code are the "NPCIDs" (enum) and "gMercProfiles" (MERCPROFILESTRUCT[NUM_PROFILES]).
The merc profile array is used all over the code, thus changes should be as non-invasive as possible. But i think this
array can be replaced with a class (object) that overloads the [] operator :
MERCPROFILESTRUCT& MercProfileClass::operator[](int ID);
MERCPROFILESTRUCT& MercProfileClass::operator[](string Name, bool bFullName=false); // name or nickname
The effect on the outer world should be minimal. And inside the class we can do whatever we want, like
choosing a profile order that does not depend on any predefined data. We only need to handle the "NPCIDs"
properly, so maybe we could just register them in our new class in order to identify them later.
Now we have the following data in prof.dat (multiplied 170 times)
CHAR16 zName[ NAME_LENGTH ];
CHAR16 zNickname[ NICKNAME_LENGTH ];
UINT32 uiAttnSound;
UINT32 uiCurseSound;
UINT32 uiDieSound;
UINT32 uiGoodSound;
UINT32 uiGruntSound;
UINT32 uiGrunt2Sound;
UINT32 uiOkSound;
UINT8 ubFaceIndex;
PaletteRepID PANTS;
PaletteRepID VEST;
PaletteRepID SKIN;
PaletteRepID HAIR;
INT8 bSex;
INT8 bArmourAttractiveness;
UINT8 ubMiscFlags2;
INT8 bEvolution;
UINT8 ubMiscFlags;
UINT8 bSexist;
INT8 bLearnToHate;
// skills
INT8 bStealRate;
INT8 bVocalVolume;
UINT8 ubQuoteRecord;
INT8 bDeathRate;
INT8 bScientific;
INT16 sExpLevelGain;
INT16 sLifeGain;
INT16 sAgilityGain;
INT16 sDexterityGain;
INT16 sWisdomGain;
INT16 sMarksmanshipGain;
INT16 sMedicalGain;
INT16 sMechanicGain;
INT16 sExplosivesGain;
UINT8 ubBodyType;
INT8 bMedical;
UINT16 usEyesX;
UINT16 usEyesY;
UINT16 usMouthX;
UINT16 usMouthY;
UINT32 uiEyeDelay;
UINT32 uiMouthDelay;
UINT32 uiBlinkFrequency;
UINT32 uiExpressionFrequency;
UINT16 sSectorX;
UINT16 sSectorY;
UINT32 uiDayBecomesAvailable; //day the merc will be available. used with the bMercStatus
INT8 bStrength;
INT8 bLifeMax;
INT8 bExpLevelDelta;
INT8 bLifeDelta;
INT8 bAgilityDelta;
INT8 bDexterityDelta;
INT8 bWisdomDelta;
INT8 bMarksmanshipDelta;
INT8 bMedicalDelta;
INT8 bMechanicDelta;
INT8 bExplosivesDelta;
INT8 bStrengthDelta;
INT8 bLeadershipDelta;
UINT16 usKills;
UINT16 usAssists;
UINT16 usShotsFired;
UINT16 usShotsHit;
UINT16 usBattlesFought;
UINT16 usTimesWounded;
UINT16 usTotalDaysServed;
INT16 sLeadershipGain;
INT16 sStrengthGain;
// BODY TYPE SUBSITUTIONS
UINT32 uiBodyTypeSubFlags;
INT16 sSalary;
INT8 bLife;
INT8 bDexterity; // dexterity (hand coord) value
INT8 bPersonalityTrait;
INT8 bSkillTrait;
INT8 bReputationTolerance;
INT8 bExplosive;
INT8 bSkillTrait2;
INT8 bLeadership;
INT8 bBuddy[5];
INT8 bHated[5];
INT8 bExpLevel; // general experience level
INT8 bMarksmanship;
UINT8 bMinService;
INT8 bWisdom;
UINT8 bResigned;
UINT8 bActive;
UINT8 DO_NOT_USE_bInvStatus[OldInventory::NUM_INV_SLOTS];
UINT8 DO_NOT_USE_bInvNumber[OldInventory::NUM_INV_SLOTS];
UINT16 usApproachFactor[4];
INT8 bMainGunAttractiveness;
INT8 bAgility; // agility (speed) value
BOOLEAN fUseProfileInsertionInfo; // Set to various flags, ( contained in TacticalSave.h )
INT16 sGridNo; // The Gridno the NPC was in before leaving the sector
UINT8 ubQuoteActionID;
INT8 bMechanical;
UINT8 ubInvUndroppable;
UINT8 ubRoomRangeStart[2];
UINT16 DO_NOT_USE_inv[OldInventory::NUM_INV_SLOTS];
INT8 bMercTownReputation[ 20 ];
UINT16 usStatChangeChances[ 12 ]; // used strictly for balancing, never shown!
UINT16 usStatChangeSuccesses[ 12 ]; // used strictly for balancing, never shown!
UINT8 ubStrategicInsertionCode;
UINT8 ubRoomRangeEnd[2];
INT8 bPadding[ 4 ];
UINT8 ubLastQuoteSaid;
INT8 bRace;
INT8 bNationality;
INT8 bAppearance;
INT8 bAppearanceCareLevel;
INT8 bRefinement;
INT8 bRefinementCareLevel;
INT8 bHatedNationality;
INT8 bHatedNationalityCareLevel;
INT8 bRacist;
UINT32 uiWeeklySalary;
UINT32 uiBiWeeklySalary;
INT8 bMedicalDeposit;
INT8 bAttitude;
INT8 bBaseMorale;
UINT16 sMedicalDepositAmount;
INT8 bLearnToLike;
UINT8 ubApproachVal[4];
UINT8 ubApproachMod[3][4];
INT8 bTown;
INT8 bTownAttachment;
UINT16 usOptionalGearCost;
INT8 bMercOpinion[75];
INT8 bApproached;
INT8 bMercStatus; // The status of the merc.
// If negative, see flags at the top of this file.
// Positive : The number of days the merc is away for.
// 0 : Not hired but ready to be.
INT8 bHatedTime[5];
INT8 bLearnToLikeTime;
INT8 bLearnToHateTime;
INT8 bHatedCount[5];
INT8 bLearnToLikeCount;
INT8 bLearnToHateCount;
UINT8 ubLastDateSpokenTo;
UINT8 bLastQuoteSaidWasSpecial;
INT8 bSectorZ;
UINT16 usStrategicInsertionData;
INT8 bFriendlyOrDirectDefaultResponseUsedRecently;
INT8 bRecruitDefaultResponseUsedRecently;
INT8 bThreatenDefaultResponseUsedRecently;
INT8 bNPCData; // NPC specific
INT32 iBalance;
INT16 sTrueSalary; // for use when the person is working for us for free but has a positive salary value
UINT8 ubCivilianGroup;
UINT8 ubNeedForSleep;
UINT32 uiMoney;
INT8 bNPCData2; // NPC specific
UINT8 ubMiscFlags3;
UINT8 ubDaysOfMoraleHangover; // used only when merc leaves team while having poor morale
UINT8 ubNumTimesDrugUseInLifetime; // The # times a drug has been used in the player's lifetime...
// Flags used for the precedent to repeating oneself in Contract negotiations.
// Used for quote 80 - ~107. Gets reset every day
UINT32 uiPrecedentQuoteSaid;
UINT32 uiProfileChecksum;
INT16 sPreCombatGridNo;
UINT8 ubTimeTillNextHatedComplaint;
UINT8 ubSuspiciousDeath;
INT32 iMercMercContractLength; //Used for MERC mercs, specifies how many days the merc has gone since last page
UINT32 uiTotalCostToDate; // The total amount of money that has been paid to the merc for their salary
UINT8 ubBuffer[4];
Writing this values as they are into a xml file would result in a file with similar structure (long list of parameters). But i would rather have something like this
MERCPROFILESTRUCT:
Name
NickName
MercTraits:
Attributes:
Strength
Wisdom
...
Skills
Mechanical
Explosives
...
...
GameData
Sounds
OkSound
DieSound
...
FaceOffsets
EyesX
EyesY
MouthX
...
...
...
One way to structure the variables is to group the values as it is done in proedit.exe, but maybe we can come up with something better.
And of course we are not restricted by prof.dat and can include any other data that can be linked to a merc (in a reasonable way).
Report message to a moderator
|
|
|
|
|
| Re: prof.dat -> xml[message #181571]
|
Tue, 15 April 2008 21:58
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
BirdFlu@ the scorpion : are you talking about having an arbitrary number of mercs with arbitrary/multiple group affiliations?
don't know what you mean by "group affiliation"
what i was suggesting is to get rid of the very severe slot assignements all characters in prof.dat have. I guess this has to do with the NPCID enums.
i'd like to be able to use any character slot for any type of character with any type of placement routine. ATM, all of these important factors are hardcoded and cannot be changed in proedit.
if they could, we'd gain a lot of flexibility in the handling of the slots even before prof.dat has to be touched.
of course these restrictions go clearly beyond prof.dat, and i was thinking aloud whether it is better to have these restrictiosn cleaned out first before prof.dat is restructured.
Report message to a moderator
|
Sergeant Major
|
|
|
|
| Re: prof.dat -> xml[message #181576]
|
Tue, 15 April 2008 22:11
|
|
| Lesh 2 |
 |
Messages:107
Registered:September 2006
Location: Izhevsk, Russia |
|
|
the scorpionmaybe both can be done at once: when you externalisze prof.dat to new xml's, maybe externalising those important values that are not even in prof.dat as well to the same xml's would be the way to go. But it would complicate things even more.
as mentioned before, i'm unsure as to what has to be done first. what's important is to find a solution that gives the most gain. There are many ways in which prof.dat hinders other development, that's why it should be bought into an easier format.
people have accused me that viewing things that way is shortsighted. But i'd like to have brought the aspects enumerated above to people's knowledge before prof.dat is externalised and people recognise that there are still various limitations.
I understand you, Scorpion.
I think, the first to be done is an overview of an game aspects, somehow related to prof.dat ( = character list). Let me start.
Ja2 has many types of game characters:
- AIM mercs;
- MERC mercs;
- RPC's;
- robot;
- vehicle;
- player chars;
- NPC's (RPC's), that has subcategories:
--- traders, repairers;
--- terrorists;
--- assasins;
--- miners;
--- ordinary npc, that is involved into some quest;
--- special npc, that is shown in meanwhile scene;
... maybe forgot something ...
My point is that prof.dat is a middle-ware, a character list. This list holds various attributes and stats, used by every char in game. But it lacks something. Prof.dat doesn't contain information about role of the character (and it's associated data) in the game. So there must be high-level structures, like miner's list, that refers to character list and points, which characters are miners.
But I said, prof.dat is a middle-ware. There is low-level structures, referred by prof.dat itself, a faces list. The faces list contain information about eyes and mouth (x,y) coordinates for big and small faces, face expression.
The current problem with faces is that some characters have only small faces (mercenaries), some characters have only big faces (non-recruitable npc's), some characters have both big and small faces (recruitable npc's), some characters doesn't have animated face (robot, vehicle) and the last, special character Elliot has several (!!!) faces. His face is changing during the campaign, as the queen slaps him more and more.
So final scheme:
role --> character --> face
Let's discuss!
Report message to a moderator
|
|
|
|
|
| Re: prof.dat -> xml[message #181583]
|
Tue, 15 April 2008 22:41
|
|
| ctiberious |
 |
Messages:605
Registered:March 2007 |
|
|
@BirdFlu: Couple things. First, as of the NIV merge, starting equipment has been moved from prof.dat over to MercStartingGear.xml at least while in NIV mode. It would be simple enough to update the code so that MercStartingGear.xml was used regardless of the inventory mode. I simply left it as an NIV only system so that people who prefered OIV and the existing prof.dat could use them.
Prof.dat (and mercstartinggear.xml) only equate to profile data. These files are only read once when a new game is started. From that point on, all profile information is stored in the gMercProfiles array. This array is part of every save.
Lastly, there's one other thing you should consider. At the present, we actually use 8 different prof.dat files. There's a different prof.dat for each difficulty and equipment mode. Assuming you wanted to keep that same functionality, you'd be looking at 8 different files, each with 70k+ lines. This is one of the main reasons I didn't try to completely externalize prof.dat when I setup the mercstartinggear.xml file. More then converting the existing prof.dat files over to xml, I'd rather see someone create a new prof.dat editor that pulled data from the existing xml files, and included functionality to read all 8 different versions of the prof.dat files.
Report message to a moderator
|
|
|
|
|
| Re: prof.dat -> xml[message #181610]
|
Wed, 16 April 2008 01:03
|
|
| BirdFlu |
|
Messages:438
Registered:September 2007
Location: Lampukistan |
|
|
the scorpiondon't know what you mean by "group affiliation"
being a member of a group, like rebels, traders, police, army, AIM, MERC, barkeeper guild etc.
Quote: .. MercStartingGear.xml ..
I thought about splitting the file too, but where should the limit be, 2 files or maybe 5 or 10. Or we create a file for each merc (-> 170 files).
Quote:Prof.dat (and mercstartinggear.xml) only equate to profile data. These files are only read once when a new game is started. From that point on, all profile information is stored in the gMercProfiles array. This array is part of every save.
Is that good or bad? Do we want to change mercs profiles after game start? Should savegames be binary or xml files (compressed, to keep them small)?
Quote: .. 8 prof.dat files ..
we could include everything into one file, so we would not need to duplicate data that doesn't change.
...
80
75
70
50
...
20
30
...
Of course the parsing would take longer, but we have to decide at a point, many smaller files or one big file, or something in between of course.
Quote: More then converting the existing prof.dat files over to xml, I'd rather see someone create a new prof.dat editor that pulled data from the existing xml files, and included functionality to read all 8 different versions of the prof.dat files.
But that doesn't affect the internal processing of the files inside the game.
Report message to a moderator
|
|
|
|
|
| Re: prof.dat -> xml[message #181622]
|
Wed, 16 April 2008 01:35
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
these "groups" you mention are very different. some of them are just factions as defined in prof.dat, others are hardcoded slot limitations.
i'd really like you guys to keep in mind what lesh wrote up there. There is a lot of important data at a "higher" level than prof.dat that needs to be adressed.
and i was wondering whether it'd be necessary to externalise this first.
lesh mentioned the most important case, the character's "role", or, better, what one can do with a character on a specific slot.
I think this is extremely important and steps forward in this department could help a lot when adressing prof.dat
then something else is placement routines. If you look at prof.dat, you typcially encounter two different possible entries for the sector in which the character appears: an explicit sector on the one hand, and "@0" on the other hand.
Now every @0 character has a hardcoded placement routines which can only very unreliably and in very crude ways be changed.
This is something that is typcially not really editable in prof.dat, even if you set a specific sector, you still get the hardoded placement routine
this effecttivly keeps many slots from being used arbitrarily and restricts many a slot.
then what lesh also mentions is face coords. Only AIM and MERC characters have their face coords defined by prof.dat, RPC's, IMP's and EPC's have theirs hardcoded.
if we want to be able to expand on prof.dat, which seems the main point in porting it to .xml, there must be ways to define new coords for new RPC chars. In order to define new RPC chars, we must be somewhat flexible with the slots...
all of these things have very rigid ties to each other. I think it may have to be deal with as a whole package in order to achieve the best results.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
| Re: prof.dat -> xml[message #181631]
|
Wed, 16 April 2008 02:30
|
|
| BirdFlu |
|
Messages:438
Registered:September 2007
Location: Lampukistan |
|
|
Quote:Factions was the term you were looking for when you said affiliation.
I actually meant more than just factions. Inside a faction there could be more subgroups like admins, elites etc.,
and a merc can be a member of multiple groups (nationalities, employer, etc.)
Quote:then something else is placement routines. If you look at prof.dat, you typcially encounter two different possible entries for the sector in which the character appears: an explicit sector on the one hand, and "@0" on the other hand.
Now every @0 character has a hardcoded placement routines which can only very unreliably and in very crude ways be changed.
This is a good point. @0 actually means (sSectorX=0, sSectorY=0) in the file and is an invalid sector, i suppose. That means that
the real numbers have to be determined in the code and the game just does it. I found the "HandleEarlyMorningEvents" function that sets
sector values for some mercs by using their hardcoded ID. Now, if we would refer to them by name (instead of their ID), then this
problem would go away just so , since it would not depend on a special position in an array.
Quote:Having all these 'spring' from the Prof.xml 'trunk' would be a way to illustarate/externalise them into an editable format. Right?
Is a 'spring' just a link or a reference to another file?
Editable format? Is the prof.xml file not editable?
Quote:lesh mentioned the most important case, the character's "role", or, better, what one can do with a character on a specific slot.
Is a role linked to a specific slot? Do i misunderstand the concept of a role?
Report message to a moderator
|
|
|
|
|
|
|
| Re: prof.dat -> xml[message #181694]
|
Wed, 16 April 2008 16:19
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
your last question birdflu:
yes, the some of the roles lesh mentiones are directly dependant on the character's slot.
there are many things, like factions like nationality like gender etc. that are actually defined by prof.dat, for many other things, very important things, prof.dat is just the "messenger" of the data or simply sais nothing about them.
e.g. slot 131 can't be at AIM, can't be an RPC, can't be a trader, can't be placed according to a script like character 68 or 61 (and tons of others) etc.
Let's think of the most important distinction: playable character vs. not-playable character
hardcoded. Do we really want to go through all the trouble externalising prof.dat without having the possibility to select for any given slot if the character can be a PC or just an NPC?
Wouldn't it even be necessary to have this first before we can add any slots to a new, open-ended prof.dat? wouldn't we require to hardcode the role of any additional character if we just externalise prof.dat and not the exe's slot restrictons?
a new character would have to have the possibility to be defined in prof.dat to appear at AIM, MERC, as an RPC, as an EPC as a Trader a vehicle a heli pilot, etc see lesh's list. prof.dat alone wouldn't allow that yet --> need to hardcode.
all of this is stored "higher" than prof.dat in the exe, and many of this things have logical connectons to "lower" data like maps, face files, speech and subtitle files etc.
I was hoping that we can tackle the entire complex of things by its head, which i, personally woudl say, is the slot assignment.
then we could go "down" subsequently to prof.dat, to the faces files etc. I am well aware i am asking probably impossible things here, but what i hope is give future modmaking the best possibilities, and one of the most important limitations are the slot limitations.
i think you saw the problem with this @0 thing. What we hope for is of course to have some sort of control over what happens if we pick @0 for any given character. Or, at least, that we can disable the script from happening ideally from within prof.dat
so maybe another flag that says "uses exe placement script yes/ no"
(ideally, the fle woudl also give an index of the script which would point to "placementscripts.xml" where we coudl select. But this is far away dreaming, kaiden and dealtar have writting some things about scripting, maybe then this could become topical)
currently, this is possible in very limited ways only. It seems to work for some npc's, not for others, some work partly, and sometimes we even break prof.dat if doing too many changes to the @0 entries (yes, it can cause a blackscreen-ctd at the beginning of the game and other ugly things)
vengeance NK may still have had it in certain versions.
of course, the impact of this scripts is vastly bigger as long as all the slot hardcodings exist. If a modmaker can just select NPC 131 to take over tony's or devin's or skyrider's role, the placement routines of said characters would restrict modding much less.
the reason why i put so much emphasis on these things is because i don't consider them "spring" of prof.dat at all, i consider many of these things a requirement for prof.dat to work efficiently. I consider the slot restrictions to not be dependant on prof.dat, but the other way around. your externalisation of prof.dat would probably suffer from this "parental" limitations the way i understand it.
of course, my grasp of these things is very limited, so if it can be explained to me how to solve the problems, or, that these problems are not really problems once you guy(s) have done your magic, then the better.
i hope my point gets across, it is sometimes difficult for me to correctly formulate these ideas as they come from very specific modmaker perspectives.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
|
|
|
|
|
| Re: prof.dat -> xml[message #181883]
|
Thu, 17 April 2008 19:25
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
yes, the identification by slots isn't necessarily bad. i think if the restrictions on slots can be broken up, the slots themselves wouldn't be much of a problem.
so what would be needed is an intermediate file between the exe and prof.dat that defines which slot can hold what type of character, especially the distinction PC/NPC and then also in some more detail (what kind of pc, traders etc)
now in theory, that's easy, but i can see a bunch of issues coming up there, e.g. this file would need to be able to cause many "slot-dependant" things to change.
Report message to a moderator
|
Sergeant Major
|
|
|
|
| Re: prof.dat -> xml[message #181918]
|
Thu, 17 April 2008 23:26
|
|
| BirdFlu |
|
Messages:438
Registered:September 2007
Location: Lampukistan |
|
|
OK, lets clarify some things. We have N merc profiles and they are stored in a list. Every position or location in that list can be referred
to as a slot. The problem now is the"VIEW" on the merc profiles. This view defines that slot A to B belong to AIM members and C is a
merc with a special behaviour and D to E are the player's characters, and so on. You can define a range (A to B), because you know
that you have a list (that is immutable!).
So how would you add new mercs? Assuming there were no free slots in the list, you would have to replace existing mercs. But actually you
don't really replace that merc, because a slot identifies a POSITION in the list and not the merc that happens to be in this slot. A merc
is defined by his/her attributes and behaviour. Attributes are defined in the merc's profile but not his behaviour. It is statically
linked to a slot. So by replacing only the the attributes you only replace a part of a merc.
(For the sake of simplicity i define membership of for example AIM as behaviour, as all AIM members behave in a similar way (they let hire them etc.))
Imagine now a merc's behaviour would be linked to his profile, then the order of your mercs would not matter anymore. You also don't
have identify them by some hardcoded id or slot number, you actually cannot do it because you cannot rely on the number and
order of mercs in the data files. The number and order could change anytime between two games, not necessary in a game. I suppose you
want that kind of flexibility or something similar.
Now you have to identify mercs by another id, a name for example. Important is that it is defined in a file and not somewhere in the code.
The mapping from name to merc is done by the program and no statement was made about the actual storage. It could still be a simple
list (as it is now) or multiple lists or a tree (map) or any other complex data structure. With this flexible approach you lose the
concept of a slot (which is a good thing in my opinion). It is as if they never existed.
Report message to a moderator
|
|
|
|
|
|
|
| Re: prof.dat -> xml[message #181975]
|
Fri, 18 April 2008 14:16
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
i think especially the .npc files and several hardcoded routines all over the place in the .exe use references to slot numbers.
so if you remove this "identification of mercs by slot number" i guess a big number of quest triggers and maybe the entire npc interaction code would have to be adjusted.
so my equally uneducated guess is that it might be a lot more complex to get rid of these slots than it appears at first.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: prof.dat -> xml[message #182181]
|
Sat, 19 April 2008 14:38
|
|
| Khor1255 |
|
Messages:1817
Registered:August 2003
Location: Pleasantville, NJ |
|
|
I see where using the term Mercs.xml would have been confusing. Sorry about that. We were taliing about the hireable characters from MERC at the time.
What I meant by a 'Mercs.xml' is just a way to isolate parts of the regular prof.dat list into 'branches' that could be defined by their own characteristics.
For example, maybe we would have an AIM.xml that would cover all the characters in AIM but also be opened to any addition we might want to add to that branch or array.
We might have one for Merc, one for Rebels, one for Kingpin's goons, etc. Or maybe it would not have to be divided so many times. Looking at the code you would know this far better than me.
Anyway, if we did it like this their Prof.dat index number would only be relevant for their placement in the Parent list. The "branch' lists or subdirectories might be opened eventually to add as many of one type of character (AIM mercs for instance) the modder wanted.
In this way we would not have to change all of the times the game called for a merc by his Prof.dat index. You could leave these numbers alone for now. With subdirectories you might have AIM characters occupying Prof.dat slots 0-39 but also (because the program would be looking at their uiIndex number instead of the Prof.dat slot number only) you might have AIM characters occupying slots 151-155 as well. The way the game would read it would be by the uiIndex (or whatever you would call it in the .xml) so that Prof.dat number 151 would be equal to uiIndex 40 in the AIM.xml (because it is added to the end of the AIM list.
This is exactly how the items.xml does it with one exception. In the Items.xml slot 0 has to be a nada (or blank) item. I do not know if this would be problematic.
But if you could make factions and such referenced by Prof.dat first but then REALLY referenced by a 'Child' directory like is currently the case with items a lot of the restrictions of slots might become arbitrary through externalisation of each faction type.
I am speaking largely from intuition here but I think if the 0 = Barry slot is not an insurmountable barrier in the Prof dat (maybe by making the last number in Prof.dat act as the beginning/end of the array) we might be able to do all sorts of cool things possibly including adding more characters to the total list.
But even if we couldn't do that, just being able to add as many of whatever type of characters we wanted (factions, rpcs, whatever) within the existing list would be golden.
[Updated on: Sat, 19 April 2008 15:51] by Moderator Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
| Re: prof.dat -> xml[message #182251]
|
Sun, 20 April 2008 00:49
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
why would you have to change the order of mercs?
wouldn't that be the task of somebody modifying the files? the only thing that needs to be done is creating the possibility of a flexible handling of the slots.
there will be many other dependencies, so by no means should the slots be shuffled, just the possibility to use any slot as wanted would be required.
Report message to a moderator
|
Sergeant Major
|
|
|
|
| Re: prof.dat -> xml[message #182256]
|
Sun, 20 April 2008 01:50
|
|
| BirdFlu |
|
Messages:438
Registered:September 2007
Location: Lampukistan |
|
|
Quote:why would you have to change the order of mercs?
Because. If it is possible then someone will do it. The game will (probably) not crash, but there will be some strange results (i.e. unfitting comments).
Quote:wouldn't that be the task of somebody modifying the files?
Exactly. And why should anyone forget to do it, it's so obvious. %-(
Quote:the only thing that needs to be done is creating the possibility of a flexible handling of the slots.
there will be many other dependencies, so by no means should the slots be shuffled, just the possibility to use any slot as wanted would be required.
If you add a new AIM merc right after the other AIM mercs (because it's nices to have them all together), all following mercs
will have another id/slot (+1). So if a merc in slot 55 likes another merc in slot 66, then after the insertion the number has to
change to 67 (or not, depending on where the new merc was inserted).
If the implementation can/will easily handle such cases, then everything is fine. If not, then we will have to do it in the files.
I'm just saying that this problem could occur and that we should be aware of it.
Report message to a moderator
|
|
|
|
|
Goto Forum:
Current Time: Thu Apr 25 22:08:45 GMT+3 2024
Total time taken to generate the page: 0.03588 seconds
|
Blog
Search
Help
Members
Register
Login
Home
