[mBase.ini concept] Fellow Travelers - Meeting the Same People at Different Bases
-
@ Adoxa: Hmm, so there’s a seperate list for each base. Too bad. I was imagining an InfoCardMap.ini-like structure, but then for Objects instead of Ids_info values:
[ObjectGroupTable]
Group = li0108_universal_001_m, li0201_universal_001_mBut -if I understand you correctly- because NPC nicknames are not necessarily unique, this won’t work, even if the above format would be added to the game Unless you could also hack the game to maintain a global NPC list rather than a per-base one. But your to-do list is already fairly large, and I see there are a lot of proposals done on the forum, to hack this, hack that etc., and indeed this is probably not something that would change the game significantly.
The only way then would seem to be to use similar persons that look identical and tag them visit = 1. Trent will then know them from the start of the game, but this way at least the impression be made he meets people he knows, and these people appear like they are travelling too.
Btw even if it won’t work for the NPCs, it could have advantages if the visit/known-status of objects could be linked:
Think of a huge gas giant, > 20000, with an ambient / esthetic function. It will be in the background, and the player probably won’t get close enough to “visit” it, and it will remain an “unknown planet”. But thru the above-proposed function, it could be linked to a near planet (maybe a moon of the gas giant) where the player will probably travel to. (Btw I now use a workaround of placing a very small planet within the smaller planet, off-center, that the player will visit, then link it as a satellite to the large gas giant with a parent = line. So, when the player gets to know the smaller planet, he will then also know the big giant in the background.) Maybe this is something that could work thru RumorKnowDB.ini…
-
After having another look, it looks like it’s just stored as a vector, so if I can find where it changes it (which I should be able to do, since I can track it after it reads them from the save), I should just be able to iterate through the similar nicknames and change them, too.
-
adoxa wrote:
After having another look, it looks like it’s just stored as a vector, so if I can find where it changes it (which I should be able to do, since I can track it after it reads them from the save), I should just be able to iterate through the similar nicknames and change them, too.I guess this implies good/cool news, although I can barely understand whay you mean exactly
-
I may really have just been overthinking it. Here’s a patch to bypass the base test altogether, just testing the nickname. Untested.
content.dll 0A8793 07->00 = NPCs are global, not local to base PART 1 ~adoxa content.dll 0A8903 05->00 = NPCs are global, not local to base PART 2 ~adoxa content.dll 0A8C83 05->00 = NPCs are global, not local to base PART 3 ~adoxa content.dll 0A8CE1 8D442410508BCE->394E047412EB09 = NPCs are global, not local to base PART 4 ~adoxa content.dll 0A8D59 05->00 = NPCs are global, not local to base PART 5 ~adoxa
-
adoxa wrote:
I may really have just been overthinking it. Here’s a patch to bypass the base test altogether, just testing the nickname. Untested.content.dll 0A8793 07->00 = NPCs are global, not local to base PART 1 ~adoxa content.dll 0A8903 05->00 = NPCs are global, not local to base PART 2 ~adoxa content.dll 0A8C83 05->00 = NPCs are global, not local to base PART 3 ~adoxa content.dll 0A8CE1 8D442410508BCE->394E047412EB09 = NPCs are global, not local to base PART 4 ~adoxa content.dll 0A8D59 05->00 = NPCs are global, not local to base PART 5 ~adoxa
Wow, great!!! Just got home, nighshift. Will test it after some hours sleep and mandatory social interest in family members. Oh, and get rid of some error-triggering NPC head I apparently included in mBase.ini Got a huge bunch of Spew warnings like
WARNING:General: Sc_MLHEAD_MOTION_SHAKHEAD_NO_000LV_XA_% failed to map JOINT (parent: Head01, child: B_Left Top Lip) channel.
WARNING:General: Sc_MLHEAD_MOTION_SHAKHEAD_NO_000LV_XA_% failed to map JOINT (parent: Head01, child: B_Right EyeLid) channel.I don’t think it’s a typo on my behalf; rather some of the head files is probably corrupted or inadequate.
Too bad Spew/Spit do often not tell the exact entry that cause the reported error (not to mention many error do not reported at all).
Anyway, better test your hack with an error-free mBase to begin with.
But now I’m gonna sleep
-
IIRC robots do not have a head entry making them unusable with certain THN files. Good fix though Adoxa!
-
Weird, I only had these errors in Spew once… And I haven’t put any robots (yet) in my new bases because I knew there was an issue with them…
@Adoxa: what files should I distract from JFLP to use the robot fix? And does JFLP also allow for female bartenders? I remember there was an issue with that too. EDIT Nevermind, I just found Buck Danny’s RObot Trader Fix in an ancient direcorty on my old comp :lol:
Btw I still don’t know when I’ll test the global NPC hack. Nest days will be kinda busy and I don’t wanna do it “in-between” (like I’m now typing this). Maybe Tuesday, though I hope sooner.
-
From jflp.txt:
DATA\MISSIONS\mbases.ini - changed Scripts\vendors\li_commtrader_fidget.thn to Scripts\vendors\robot_commtrader_fidget.thn for all the robot traders (removes lots of warnings relating to Sc_MLHEAD_MOTION_SHAKHEAD_NO_000LV_XA_%); DATA\SCRIPTS\VENDORS\robot_commtrader_fidget.thn - new file based on li_commtrader_fidget.thn, deleting the "Sc_MLHEAD_MOTION_SHAKHEAD_NO_000LV_XA_%" event. {S} ```So you'll have to find all the robot traders and replace them (depends on how modified your mbase.ini is; if there's lots, you might be able to use something like KDiff3 for selective replacements), and extract the new script. I expect all the animations for the bartenders are male (like the player animations; bit of a surprise when I first tried using Juni instead of Trent). Probably a fair bit of work to change them.
-
Gibbon wrote:
Notepad - Find and Replace, takes secondsNah, at least an hour, for me, (which I do not have right now, coz I have to install the new AVG on my other pc):
- First, do all the hacks - don’t forget to backup first
Then decide what chars to make ‘global’ - again, backup first
Then test
Then run into unexpected things, either caused by, or totally unrelated to the hack, or somewhere in between, that I can’t resist of resolving
Meanwhile, family life goes on. Just finished hanging a flat screen tv on the wall. Right now I’m installing AVG at the other pc, and the I’ll have to prepare to do some groceries on foot coz its very snowy here (we aren’t really used to that anymore, and the parking lot at the mall will be like Stalingrad '42. )
Btw the AVG thing sucks, tried it earlier this week and it failed. So that’s why I do not classify it as “EASY”.
Then I have to prepare for some dinner we arranged months ago (when we didn’t know that the roads would be such a mess) and we have to at least double the estimated travelling time.
Meanwhile, my girlfriend is nagging me to do this and to do that. I will keep my temper coz when I kill here, I’ll be thrown in jail and a few months to several years later in a forensic mental hospital, and then the testing of the mBase NPCs hack will be delayed by at least 6 more months (when my excellent behaviour will have earned me the right to have a computer at my cell - where I will have no internet to report back to you guys).
So, the fastest way for me is to patiently wait until next Tuesday. Or until everyone here sleeps
Forget my whining, I’m testing it now (found a one hour gap in my tight scheme )Unfortunately, I got a crash as soon as I clicked the Bar icon
What did I do?
I apllied the proposed hacks to content.dll, then I refered to a bunch of Liberty Police officers from the mBase entries in my new base, Li_03_05, that are also at Planet Denver.Instant crash when I clicked the bar icon. Now running scans. FLScan didn’t find anything; running FLEC now.
- First, do all the hacks - don’t forget to backup first
-
FLEC doesn’t report an error either.
Anyway, it crashed. So I must assume the hack doesn’t work :(vOr I messed up the experiment, but wouldn’t know why. I did, how I intended it to work: referring to a given NPC from more than one Base.
Thanks anyway Adoxa, for the effort!!!
-
@Gibbon: Sure, if you want to replace all the human traders, too.
@Moonhead: It’s not enough to just reference the NPC (npc = …), you still have to define it ([GF_NPC]). At least, that’s all I had to do - apply patch, no crash; add npc line, crash; copy [GF_NPC], no crash.
-
As far as I know there are no female bartender thns. It seemed to be a bone issue between male and female skeletons (the left and right arm is switched). You could create a duplicate thn anim for it and switch the root arm bone names.
-
adoxa wrote:
@Gibbon: Sure, if you want to replace all the human traders, too.@Moonhead: It’s not enough to just reference the NPC (npc = …), you still have to define it ([GF_NPC]).
Of course, once. At least, that was the intention, because when I define the NPC for each base, then it will be two separate people.
So, from my Li03_06 base I refered to a NPC that was defined in the Li03_01 mBase section, with the intention that it appears as if this NPC travels between Li03_01 and Li03_06 and can be met at the basr of both stations.
adoxa wrote:
At least, that’s all I had to do - apply patch, no crash; add npc line, crash; copy [GF_NPC], no crash.
But - didn’t you then just add another NPC??? Or does the game indeed link the visit/know status of both these NPCs??
It seems a bit weird to me that there are two NPCs with the same nickname, while I understood your hack would make them global…
-
My hack makes them global by ignoring the base test and just testing the nickname, meaning the same nickname in multiple bases will reference the same NPC (whichever base you visit first will have the vnpc line; any other base will continue to reference that first one). This only affects the vnpc stuff, not mbases.ini itself. And it’s still a theory until you put it to the test…
Regarding the animations. Given Lancer’s hint about switched arms, had another play with Juni. Went into li_hatcher_body.dfm and switched the LCollarBone and RCollarBone names in the sphere parts. That improved it somewhat, but the neck was still twisted and the torso doesn’t look right (not really surprising, I guess). BTW, it’s no good just changing the animations, simply because most of them don’t exist for the female. Same with the voice.
-
adoxa wrote:
My hack makes them global by ignoring the base test and just testing the nickname, meaning the same nickname in multiple bases will reference the same NPC (whichever base you visit first will have the vnpc line; any other base will continue to reference that first one). This only affects the vnpc stuff, not mbases.ini itself. And it’s still a theory until you put it to the test…Thanks for clarifying! I’ll give it another try then.
adoxa wrote:
Regarding the animations. Given Lancer’s hint about switched arms, had another play with Juni. Went into li_hatcher_body.dfm and switched the LCollarBone and RCollarBone names in the sphere parts. That improved it somewhat, but the neck was still twisted and the torso doesn’t look right (not really surprising, I guess). BTW, it’s no good just changing the animations, simply because most of them don’t exist for the female. Same with the voice.Hmm… So, we can’t have any female bartenders?? If I’d be running a pub, I’d take that to court :pint:
-
You can’t have female characters (like bartenders or shipdealers) using the male animations, but of course, replacing the animation could be an option.
-
It is only now that I can confirm the hack, as suggested by Adoxa, does actually work. Thanks again
Btw one of the people said “Nice of you to come back” to Trent. Which is a phrase that doesn’t really suite my intentions, but hey, it comes close enough now.