Quick update: I’ve managed to fix the crashes. Because I was running low on options, I started just pulling out files and replacing them with the vanilla’s game’s to see if anything changed. On my first copy-over, which was common.dll, the mod stopped crashing.

Thank you all for the assistance, as i’d probably have given up again and not reached this point without it.

Fixed them not loading in, I think. Beyond that, was still having an issue with them not playing, but that was tied to my not realizing Music.ini existed and thinking the system ini just looked for the name directly from the file, so hopefully there’ll be no more issues there.

It’s definitely still in the contact list. The text just isn’t on the navmap.

I think, after accidentally bricking my game files by accident several times trying to work it out, i’ve managed to narrow it down to one line from FLSpew for what’s probably causing this crash.

E:\FL\Scratch\Source\RPCLocal\RPCServer.cpp(62) : *** ERROR: Connect - failed to LoadLibrary(server.dll)

It’s not able to load the server.dll for some reason (my mod doesn’t have a unique server.dll to replace the basic one). I’ve double checked this by trying to load a server rather than start the game, and I run into an error there flat out.

🙂

Thank you. I’ll be doing this now. 🙂

Yeah it’s overzealous AV having false positives, been a huge headache for me to solve so far, seems I’ll have to do installer in different software and code signing is a mess. There’s no malicious code in it, in fact there are no executable installed at all, just a bunch of maxscript files, shaders and png icons.

Thaddeus wrote:
Infocardmap.ini in the Interface folder is where the magic occurs.

Bare statistics are directed by the base/planet entry in the whatever-system_01.ini file as ids_info = xxxxx

When you land on the base the visit flag changes and you can then access the bigger info card which is mapped in infocardmap.ini as

map = (system_ids_info)xxxxx, (bigger_infocard)xxxxx

I think there was a tutorial on this in the archive, just search for infocardmap

Thank you. This is exactly what I was looking for. I should be fine without the tutorial now that I know where the file is, but it’s good to have it there if I run into any problems. 🙂

It’s things like ‘We’ve gotten word from [blank double space where missing text should be] that there are Bounty Hunters in the area…’.

To display the name of an asteroid field or nebula in the mission task, add these names to the library’s DLL and make an entry in the knowledgemap.ini file
Еxample:

ids_name = 261208–—>NameResources.dll -->Badlands_Nebula
261208 + 70473 = 331681 —>OfferBribeResources.dll -->Badlands_Nebula
331681 + 200 = 331881 —>OfferBribeResources.dll -->Badlands_Nebula

Map = 261208, Zone_Li01_Badlands_Nebula, 33
Map = 331681, Zone_Li01_Badlands_Nebula, 33
Map = 331881, Zone_Li01_Badlands_Nebula, 33
Map = 332081, Zone_Li01_Badlands_Nebula, 33 —>this and further lines about this zone have no information.

Livsi wrote:
eu-St01_02_Base should also be added to mbases.ini and added the ini files of rooms to the system folder (similar to other databases)

I already had it in mbases.ini. The issue, in the end, was it not being in universe.ini, which I overlooked for some reason.

Thaddeus wrote:
not sure about the first - would have to see what you have done. Mining zones are controlled by the DATA\SOLAR\ASTEROIDS\system_your_asteroids.ini

Property flags do not affect the visibility of the zone only the visit = line in the system.ini does that - and you have to go there to add it to you nav-map.

Cpt_Rei_Fukai wrote:
This site has a seach function, so try it out 😉

Anyway to your questions:
1. A zone is displayed as minable in the navmap depending on it’s visit parameter
Property flags change the display on the navmap, e.g asteroids or nebula etc.

I considered that it might be a visit thing, but the only values i’ve known for that up til now have been 0, 1 and 128, none of which are related to mineable zoning. Having looked at the lists in the links, the property flags list shown there is actually the one i’ve been consulting for other things, but I couldn’t work out how to put the ‘0x-’ numbers into context (and still am a little, but that’s what trial and error is for), whilst the other visit numbers are news to me and are a big help. I’m assuming that a mineable zone (4), is automatically invisible until visited, or would be a 5 if it wasn’t?

And I probably should search more. It’s a bad habit of mine not to when i’m the middle of doing something and can’t immediately find what i’m looking for.

Thaddeus wrote:
your 2nd Q - radiation level is set by the damage = x line of the [zone] you have surrounding you object (or just an ambient radition zone) in the system.ini file

Cpt_Rei_Fukai wrote:
2. As Thaddeus said, simply add a “damage”(Range = 0-inf) parameter to your zone for “radiation damage”.
If you want to reduce the sensor efficiency simply add the parameter “interference”(Range = 0.0-1.0).

I know I have damage values for planetary atmospheres and sun coronas, but I wasn’t sure if that also worked for general radiation. These numbers, both for radiation and sensor efficiency (which i’m going to use more immediately) are good to know, though. Hopefully this isn’t something i’ll have to ask again.

Thank you. 🙂

robocop wrote:
Might also be the encounters themselves. If they’re not set up properly that can cause what you describe. Create the patrol path but leave out the encounters, then add in each encounter until the crashes resume. If the crashes resume after adding the first encounter it’s either the patrol path itself (see advice in above posts) or the encounter. If the crashes don’t resume until a later encounter is added it may be that last added encounter.

I have also been getting crashes related to encounters, as it happens, but it’s generally been because i’ve forgotten to insert a reference to the encounter archetype required at the start of the system ini.

Right now, though, everything seems to be working fine. 🙂

This has a massive chunk of what I was looking for. Thank you. 🙂

Is Chips still around? I’d like to ask if I can have their permission to use this as part of the groundwork for what i’m thinking of working on. If not, I can still try and learn what they did to implement it myself.

Cpt_Rei_Fukai wrote:
I investigated a bit and it seems FL always tells you “No best path” if a system cannot be reached with jumpgates. For example plotting a course to Omicron Alpha tells me “No best path” as well.

Adoxas FLHack has an option for that.

Really? huh. I’ve been playing Freelancer since I was a kid, you’d think i’d have notice this by now. 😛

Well, given the modding i’m doing, i’ll leave this as is rather than using FLHack to try and fix it. Glad to know it’s not just my system being buggy.

Cpt_Rei_Fukai wrote:
So your FLMM mod replaces dlls from Freelancer with your own ones? If so you don’t need to add them to the resources

I have all my names and infocards in two DLL files separate to the vanilla ones. It’s mainly so I can more easily keep track of what i’ve inserted. The FLMM mod contains a version of the freelancer.ini which has them listed in the resources.

Cpt_Rei_Fukai wrote:
Fled-IDS is great for this.

I’ll take a look at it shortly. Thanks for the link. 🙂

Cpt_Rei_Fukai wrote:
Technically the infocards are xml, though some of the syntax is similar to HTML. I don’t think FL supports HTML.

I get the impression ResourceHacker just registers it as HTML because of the similar syntax, then, so maybe that’s where the issue is. That said, if Fled-IDS ends up solving all this, that won’t be a problem anymore.

Cpt_Rei_Fukai wrote:
FLspew is Freelancers logfile, it is located at %User%\Appdata\Local\Freelancer\

FLScan II is a great tool to find errors in your mod…

Thank you for linking both of these. They’ve already helped me squash a couple of bugs related to something else I was having issues with. One more thing I can check off. 🙂