I tried messing around in there too, it was probably one of the most confusing INI files of the game, and your right, it does seem like it was a script before.

One thing i did was add a 3rd child_node building off another, and the game just crashed after ilaunced a mission, but it seemed to do something.

I managed to get gunboats and fighters spawning in random missions, but not together. Battleships and cruisers would also be possible, but without a fighter escort, it would be pretty silly. The game seems to pick one NPCShipArch with designated as class_fighter. Thought I might be able to trick vignetteparams.ini into spawning several groups, so there's more of a chance of gunboats and fighters showing up at the same time, but no dice.

I've spent probably ten hours fiddling with and trying to decipher this file. This is beginning to get on my nerves. Why don't random missions use Encounters like everything else?

I removed the class_fighter entry from shipclasses.ini to try and trace back where the random mission generator decides what class and formation of ships to spawn, but it didn't change anything. The random mission generator seems to be hard-coded to pick NPCShipArch's with a class of class_fighter. However, I was unable to find "class_fighter" anywhere else in /DATA or /EXE.

I'm stuck. Has anyone made any progress at all on the random mission generator? Documented failures might help at this point. Any ideas or thoughts are welcome!

the only thing progressing now is my headace

---

Why don't random missions use Encounters like everything else?

---

Indeed, I've been wondering the same thing... a RM vignette zone doesn't differ too much from one defined for RE's, except that variables are MUCH harder to control.

Getting RM's to take place at coordinates I picked about covers what I know.

> Getting RM's to take place at coordinates I picked about covers what I know.

Care to share? I just started trying to do that. I've been trying to limit the jobs in New York to one zone (just outside Manhattan), but I can't seem to get rid of spots in the Detroit Debris Field and in the Badlands, or make random missions happen outside Manhattan.

I've been looking through this ini file and I've walked away thinking one word: complicated.

I decided to look at the first mission in the list (the Destroy Installation mission) and to do that I looked at everytime it said child_node, looked for that specific node_id, and then copied/pasted that right under where it was called. Doing that the file took on the appearance of an extremely interconnected (aka spagetti code) web of function calls (each node representing a function).

So having inflated out the Destroy Installation to it's full glory (well almost full glory, I skipped over some of the parts that were just repeated over since I was doing it manually), I found I could actually follow what the flow of logic is (in general, there are some things that I have no clue what they do) so I could probably tinker with some of the details and get it to work. The problem is that this inflated form (for just one mission type) is LARGER that the original full ini file with all the missions in it. Nearly twice as large. It's no wonder they boiled it down to it's most basic level that it's at now or the file would easily be huge and near impossible to read.

Along that same train of thought, while the flow of logic is followable it's not very easy to do so since the results of a decision branch end up being so far away it's hard to keep track of what's happening. So with that in mind I'm thinking about trying to make a program that will read in the file, organize everything into a tree format (since it's already organized that way), and display the appropriate information for each selected node. This should make it much easier to see what exactly is going on. Course a problem that I might have is not being able to just read the file in (I hope I can do that without too much hair loss) but I might be forced to enter everything in manually as a static deal. Not the ideal solution since it'll only be good for the one file but it should help to decipher it to aid in new mission creation.

On that note here are some of the results I have (the full results would be far to large to display here, if I could attach a file then I'd make what I have more available).

<pre><font size=1 face=Courier>
[DataNode
node_id = 48
child_node = 97
</font></pre>

<pre><font size=1 face=Courier>
[DataNode
node_id = 95
objective_text = guide_to_main_battle, 327734, Hostile_group
child_node = 143
</font></pre>

Now somewhat surprisingly, these two nodes are the actual Destroy Installation mission. The first one sets up the job board entry and the second one builds the actual in space mission layout. The two do share info in terms of location (ie. 4F), the two groups (who vs who), difficulty, and whether or not you can expect any help. Now while by themselves they don't do much, what they actually end up doing is creating a big chain reacion of function calls (going to different nodes) that perform everything that is needed for the mission. Those function calls also include choosing between the different random factors.

Here's a small snippet from the job board setup that's expanded and then slimmed down a bit (removed some of the finer details, but you can easily look them up) with my added comments:

<pre><font size=1 face=Courier>
[DataNode
node_id = 48
child_node = 97
[DataNode
node_id = 97
child_node = 619
[DocumentationNode
node_id = 619
documentation = Hostile_ships_at_installation
child_node = 105
[DecisionNode
node_id = 105
nickname = Hostile_ships_after_30_s
child_node = 107
[DecisionNode
node_id = 107
nickname = Hostile_waves
child_node = 253
[DecisionNode
node_id = 253
nickname = Friendly_ships
child_node = 79
[DecisionNode
node_id = 79
//decide which welcome message to fire
child_node = 447
[DataNode
node_id = 447
//fire off welcome message from friendly ship(s)
child_node = 83
[DecisionNode
node_id = 83
//choose/create? friendly ship(s)
//TARGET_ZONE; spawn at target area (before player arrives)?
child_node = 104
[DecisionNode
node_id = 104
//decides which ships/factions to use
child_node = 88
child_node = 530
[DecisionNode
node_id = 530
//decides which ships/factions to use
child_node = 111
child_node = 514
child_node = 104
[DecisionNode
node_id = 104
//decides which ships/factions to use
child_node = 88
child_node = 530
[DecisionNode
node_id = 530
//decides which ships/factions to use
child_node = 111
child_node = 514
child_node = 448
[DataNode
node_id = 448
//fire off friendly arrival message
child_node = 269
</font></pre>

And here's an attempt I made to map out which node/function does what (but I didn't get far due to all the jumping around). I will go back to it if I get that program done and working since it'll be easier to follow the flow of logic. It's also hard to comment on what each one does when so many of them do little to nothing but are vitally important because they're a link in the chain and can't be ignored (usually). So there's lots of situations where a node builds the messages you here in the mission from mission control but then goes on to pick the ships you'll fly against (or that'll fly with you). It's all very confusing...

<pre><font size=1 face=Courier>
048 - goes to 97; sets up "Destroy Installation" mission for display in job board
056 - goes to 611
068 - goes to 2 and 279; part of "Destroy Installation" mission for in flight; starts installation type/difficulty picking process
069 - goes to 425; part of "Destroy Installation" mission for in flight; starts the documentation process (job board)
071 - goes to 73 and 30; part of "Destroy Installation" mission for in flight; adds weapons platforms or not
095 - goes to 143; builds mission control comm messages for "Destroy Installation" mission as well as kicks of rest of in space mission
</font></pre>

If you have any questions then fire away, I might just be able to answer it.

Edit: The code tage is giving me hassles, if the two nodes I mentioned at the begining look like they merged into one it's because of that.

Edited by - Lev on 09-04-2003 00:37:26

I get the feeling that vignetteparams.ini is a dead end. Looking at the instructions that the nodes have (objective_text, comm_sequence, documentation, Offer_group, offer_text, Difficulty), it doesn't seem that this file does anything other than assist some built-in script to generate mission text and tell the player what to do.

I'm starting to think that the random missions are generated by some hard-coded scripts in the EXE, or one of the DLLS. I'm hoping for the latter. Can anyone decompile these, or point me toward some tools I can use to do so?

I decompiled content.dll when I was making my OpenSP v1.1 MOD to change the hard coded behavior. I used PE Explorer to view and HDD Hex Editor to change.

The Freelancer.ini calls for the Random Missions from content.dll. You are right about the vignettes, they only just tell you what gets said by misson controller and what you hear. Just the physical interaction stuff.

I saw the logic flow and subroutines in assembler code in that decompiled content.dll. That is hard code. EXE I was not able to view much...

It can be changed; have you brushed up on your assembler code programming lately? It is all the same; but some of the pentium commands are new to me, I programmed simpler micro controllers.

Yep, you certainly can change things within the game logic controls in there. It is complicated and I do not even have a compiler to make changes easy. I have to go out and painfully Hex Edit the physical locations in raw data to add in the assember code commands. IF ELSE, JNZ, SUB_Routine all have OpCodes.

I did a simple one to make SP game start at M01a call from StoryLauncher sub routine to repoint to M13 mission sub routine end, to complete skip the whole SP campaign; then you level from 1 like MP with no more level skipping to make my new version of OpenSP v 1.1 MOD.

Give it a try. I am too busy with putting in easy stuff in my project; although I would not mind making custom made add-on missions that are more variety later. Cargo Runs, Bounty Hunt for Wanted Pirate in certain systems. As was in Original Privateer.

Medieval Man had Lock Pick; Modern Man has Hex Editor.

Edited by - Xerx on 09-04-2003 03:56:55

Sorry, bu I don't know of any programs that would help you. But that's great work so far.

Have you noticed if there's a different script for job board postings than for getting jobs from NPCs, or do the missions seem to be generated from the same script?

If it turns out that the Random Missions generator is hard-coded, would there still be a way to manipulate the hard-coded instructions or would it be hopeless at that point? Would "work-around" solutions be possible (creating a program within the program like an Addon that could function independently to generate Random Missions)?

With the program being as large as it is, it seems to me IMHO that creating a program to merely read the data would only be the first step; in other words, it would seem that creating a program for Random Mission Scripting would be in order just to keep all that data manageable. Right??

* Peace through superior firepower *

The jobs you get from the bar NPC are supposse to be more lucrative in pay ( in real life not really) and more challengeing ( but they are not) it is the same script within the content.dll subroutine. The ONLY difference I can tell is that since you do not know what is being offered it could be a lucrative mission even maybe more dificult (randomized a bit more -in theory) I do know this, if you DECLINE the offer; you take a reputation hit from that person's faction group.

Want to really make a faction angry at you real fast? Keep asking for the same personal job offer and keep refusing it. After about 10 to 20 times they will not like you very much!

Give me a house I sleep for the night; give me a hammer, I sleep forever.

Medieval Man had Lock Pick; Modern Man has Hex Editor.