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

[Moonhead]

NB This eventually comes down imho, to the question whether objects can be linked ‘visit-wise’ so to speak. If you happen to know that, plz read on and let me know.

In the game as it is now, Trent meets various people at the various bases. These people are randomized, but they never leave the base they are assigned to.

This is a bit lame, imho. I can understand a police or navy officer frequenting a favorite bar in the Star System he/she is working. but what with the guys from Universal, Gateway, Republican, Kishiro etc? They are just taking a rest on a long journey through sveral Star Systems (or at least, they’re supposed to give this impression). So it’s kinda lame that when Trent runs into Gateway employee Mr. So-and-so, it’s always coincidentally at the same base.

So, my idea was, to create a bunch of people that occur at several bases instead of just one.

Too bad I couln’t get it to work.

My idea was like this. Let’s say we want a Universal dude to show up both at Newark and at Los Angeles:

The [BaseFaction] should be at both Li01_08 (Newark) and Li02_01 (LA):

[BaseFaction]
faction = co_ss_grp
weight = 6
npc = li0108_li0201_universal_001_m

and, as it has to be unique, I’d figure the setup for this NPC only needs to be in mBase.ini once:

[GF_NPC]
nickname = li0108_li0201_universal_001_m
body = li_tilton_body
head = li_sales_head
lefthand = benchmark_male_hand_left
righthand = benchmark_male_hand_right
individual_name = 220071
affiliation = co_ss_grp
voice = rvp111
room = bar
etc.

Or so I thought. Like I said: it doens’t work this way. I got several undesired results (probably depending on where exactly the [GF_NPC] is put), ranging from crashes to the NPCs simply not showing up at all at one of the bases.

When I add the [GF_NPC] section (the NPC setup) to both bases, they do show up, but actually this option renders similar but non-identical people. They share name and appearance (and ini nickname - which I think the game engine will not like, alhough it didn’t crash) but they do not share memory with their counterparts. So, it doesn’t matter whether Trent has already met li0108_li0201_universal_001_m at Newark: in LA li0108_li0201_universal_001_m will introduce himself. It’s their first encounter.

So, apparently the game doesn’t look for NPCs beyond the next (or above the current) [MBase] tag.

A way I can think of that might allow to achieve this, would be if objects (in this case, NPCs) could be linked. So: getting to know Object -A- automatically makes Object -B- known / visited. If applied to persons, and the persons would then have the same appearance and name (not the same nickname, but the same in-game individual name), then they would appear as though it’s one and the same person. Trent could met Universal Shipping employee Daniel Smith at both NewArk and LA, and if it’s the 2nd time they meet, Daniel Smith would say it’s very good to see Trent, although they never met before at that base.

So, is it somehow possible to link objects, thus making them share their visited/known status ? I had hoped for knowledgemap.ini to facilitate this, but it doesn’t offer the proper format.

Well, maybe it can’t be done at all…

Anyway, I am curious for your thoughts on this.

(NB In MP this might be a bit silly, as player 1 can meet Daniel Smith in New Ark, while at the same time Player 2 is talking to Smith in LA. But I don’t think the conversation with Mr. Smith will be interesting enough to repeat it thru the chat channel, so it’s not really a problem.)

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

[Guest]

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…