[mBase.ini concept] Fellow Travelers - Meeting the Same People at Different Bases

Timmy51m

Just cut and paste the NPC into every base you want it to appear at then edit the rumours, bribes, mission difficulty etc to suit. Steel them from another NPC at the same base to make it easy as then you can be relatively sure your NPC will offer local information on wrecks, jump holes etc, also it will give you the right mission difficulty for the area. Just pay attention to the weight, mission weight of all base factions added together cannot exceed 100 from what I recall.

To be honest though, this will take you time and effort for no good reason, all the NPC characters are there for is to offer local info, bribes and missions, seeing as that’s already available, why add more NPC’s? It’s not like it’s going to have a meaningful conversation with you, probably wouldn’t even notice it was the same NPC.

Remember also, that the bar only spawns x amount of NPC’s at any one time, you can raise the number, but the order they appear in is random as far as I know, unless the weight does factor into this. Don’t expect them to show up all the time.

Moonhead

Timmy51m,

Thaks for the general info; all of this is true. Yet it doesn’t really address the topic I tried to raise, which is to bring PCs out of their locality.

It’s true this doesn’t increase the quality (or even the quantity) of the conversations you will have, but I just think it would be nice to have a bunch of NPCs that you can meet at various bases along a given route. It makes the static-ness of the game universe a bit less obvious.

Quarks

I once tried to use the same NPC entry on two bases (What about meeting Juni on multiple bases :D), trust me, it does not work The only way is the one Timmy51m suggested. And then Trent tells him his name on every base, and he will never recognice you on different bases before you have met him there.

adoxa

If you look at the vnpc entry in the save game, you’ll see it stores base, as well as NPC. Ergo, each base has its own list of NPCs, supported by the fact you used the same nickname on two bases, without incident. I was thinking you could use rumorknowdb to make the other NPC known, but now that’s not going to work. It might be possible to work around it, but too much effort for too little result, I think.

Moonhead

@ 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_m

But -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…

adoxa

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.

Moonhead

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

adoxa

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

Moonhead

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

adoxa

The robot NPC traders have those errors; I fixed them in JFLP.

LancerSolurus

IIRC robots do not have a head entry making them unusable with certain THN files. Good fix though Adoxa!

Moonhead

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.

adoxa

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.

? Offline

Notepad - Find and Replace, takes seconds

Moonhead

Gibbon wrote:
Notepad - Find and Replace, takes seconds

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

Moonhead

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

adoxa

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

LancerSolurus

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.

Moonhead

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…

adoxa

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.