Serverside or Clientside?
-
I’m thinking it’s controlled in a .dll somewhere…which working on a .dll makes me cringe and twitch a little bit. Microsoft, with this game, seems to have made it two ways: hey, here, you can change all this great stuff, but you can’t MOVE anything without a mod, that’s a no-no.
Weirdos.
Thanks for the replies, guys, mbases.ini if it gets changed at all apparently breaks missions on bases AND people in bars.
-
mbases.ini is what defines the NPCs on the bases. Some are ‘always on’ like the bartender, ship dealer, equipment dealer, etc. The random NPCs populating the bar or other sections such as the commodities room on Manhattan are randomly chosen by the server. So, you’ll see different NPCs each time you visit, but eventually you’ll start seeing familiar faces and names because only so many ‘random’ NPCs have been defined for each base. The server throws a number at the client and the client software matches up the server hash with what’s defined on the client and shows the appropriate info. So, mbases is both when referring to NPCs but server side when defining what level missions are available. For example you can offer higher paying missions on bases by doing a simple server edit but you can’t change the faction or NPCs without doing both. The client however, if he knew how to do it could change the names and text of the communication with the NPCs.
Physical fixed objects such as tradelanes, bases, etc. are both client and server side. The client could have the items installed but if the server doesn’t have them you won’t be able to interact with them. If you try either nothing happens, or you crash. Fixed items defined on the server will show up only to players who have those items defined in their files as well.
NPCs in space are defined and generated by the server only which is why you see them BUT, their parameters are defined in the client as well and must match. You couldn’t for example create a new faction on the server and expect the client to see them in space. In all likelihood the client would crash as well.
I’ve found that you can’t mess with the arch files (solararch, shiparch, etc.) without REQUIRING a matching client mod. You can’t add ships to the shiparch unless all clients have the same edits. Either the NPCs will be flying weird stuff, or the client will just crash when they encounter the new stuff. We tried adding in the Starblazer and ran into that issue.
Weapons are both. Hull damage is defined by the server but muzzle velocity and refire rate are defined by the client for example.
In our mod we’ve mostly limited our edits to enabling those features and code that exists in the vanilla install but was never enabled by MS/DA. There are some additional edits made that require an optional client mod, but all changes are made only to systems that would not be normally accessible in vanilla FL. This way the player can choose to play modded or unmodded. Modded gets you the enhancements, unmodded gives you straight vanilla gameplay.
-
Wow. That is a thoroughly well put together explanation of what’s going on, much better than I had hoped. Thank you sir. But, why would Microsoft decide to control the game in such a wacked out way? I mean, locations and all are already reported to the server, and every client file’s controlled by the server, so why not every file? Your reply includes every bit of what I was asking, it’s just a shame that there’s no way around adding existing ships to bases, ships already in the game, not new ones, without a mod, optional or not.
I can see more headaches and confusion occurring as soon as we dream up some more changes
Thanks for all your help, guys. You rock. -
Well, you have to remember that when FL first came out it was only 2003 and online multiplayer gaming and game development was still in its relative infancy… At least at FL’s scale. In 10 years game developers have learned much. My modding experience is limited pretty much to Freelancer and after ten years I’m still a noob at it. I’m not doing anything ground breaking or earth shattering, I’m just struggling along with the EXTREMELY patiently provided help offered by fine members of the modding community.
-
For the more technically curious, I have attached a plugin that logs INI_Reader::is_value & get_name_ptr. There’s some caveats, though, look at IniLog.cpp - it’s also quite slow. The gist of it is (as is already mostly suspected), the MP client does not read the path files (shortest_illegal_path.ini, shortest_legal_path.ini, systems_shortest_path.ini) or mbases.ini at all, nor does it read system encounters or object behavior.
-
I’m certainly not one to question the almighty Adoxa but you sure about mbases? I know the NPCs are generated by the server, but the ids_name and ids_info information is certainly looked at by the client. Without that info on the client the player won’t see the names and/or messages, no?
-
So I could change any ids_info on any base NPC to say [Admin]-Robocop is an almighty server god!!! and anyone would see it, even the unmodded player?
(I’ve gotta check this out… this has possibilities.)
-
I made a vanilla (test) server which used mission scripts to create new bases and objects but it is still in the testing stages and a lil too complicated to explain as yet…
But any client that joined the server could interact with these objects and bases without having to install any mods… (i think a few members of this site visited it)with that said, i did use base info from the single player bases not used in multi-player. and objects that existed in the vanilla files. The only issues i had was if the client didnt have the 1.3sdk installed (possibly the 1.1 server patch too).
There are many reasons why not to use mission scripts so i guess people will say this method is out of the question, but i thought i’d mention it for future info.
Hopefully gonna put the server back online in the next few weeks if you want to see it. Im just trying to implement cloaking NPC at the mo, but not having much joy (in MP).
If you visit and like what you see, i could send ya/ upload the script(s) and try explain how they should be added.
-
robocop wrote:
I’m certainly not one to question the almighty Adoxa but you sure about mbases? I know the NPCs are generated by the server, but the ids_name and ids_info information is certainly looked at by the client. Without that info on the client the player won’t see the names and/or messages, no?In our testing it seemed like some of Mbases.ini was read, and some was ignored. We could populate empty bars [such as Ryuku] with people, but we couldn’t get them to say anything. It definitely reads parts of it, but it seems to ignore others. We’ll take a look at Adoxa’s file.
At the moment we’re [“we” meaning Throcken and myself on our server] just trying to do as MUCH as possible without adding a mod. Partly as a personal challenge to ourselves and partly to create the coolest experience possible without requiring a mod download. Nothing too big and exciting obviously but we’ve been able to do some pretty fun stuff with the NPCs.
khayman wrote:
I made a vanilla (test) server which used mission scripts to create new bases and objects but it is still in the testing stages and a lil too complicated to explain as yet…
But any client that joined the server could interact with these objects and bases without having to install any mods… (i think a few members of this site visited it)THIS is what we’ve been looking for! We’d love to be able to implement stuff like this, so definitely expect myself, or throcken [or both of us] to be inquiring more about this. Spawning in destructible battleships for players to log on and frag, spawning random npc raids on unsuspecting freelancers… stuff like that is something really exciting to us that I’ve only seen implemented on 24/7 Procyon. So, hell yeah, we’ll be in touch.
And also, I’d like to thank all of y’all for your input and feedback, it’s great to see the Freelancer modding/coding community is still alive and vibrant after all these years, this site has been a big help.
-
adoxa wrote:
For the more technically curious, I have attached a plugin that logs INI_Reader::is_value & get_name_ptr. There’s some caveats, though, look at IniLog.cpp - it’s also quite slow. The gist of it is (as is already mostly suspected), the MP client does not read the path files (shortest_illegal_path.ini, shortest_legal_path.ini, systems_shortest_path.ini) or mbases.ini at all, nor does it read system encounters or object behavior.And if to add to dacomsrv.ini at the server-side?
-
From dacomsrv.ini
[DACOM]
IgnoreDACOMEnv = true <- curious about this line
DllPath = .\[Engine] <–-manages animation/hardpoints on server side, right?
Animation
Hardpoint
RenderManagerProbably the [engine] is the game engine, since it handles rendering. I’m curious where Ignoredacomenv comes into play.
Since [Libraries] has to have flhook.dll on it to load it automatically, which in turn allows clients to interact with flhook commands, what about sticking infocards.dll under there? Wouldn’t that ‘enable’ clients to see the server’s view of things? Since flhook doesn’t exist for the client until it’s activated?
edit: infocards.dll loads wtih no problems, but client couldn’t see it. testing setting ignore line to false now.
edit2: Hasn’t changed anything, clients still can’t see any information. Knew it wasn’t that simple, but had to try anyway.
-
robocop wrote:
So I could change any ids_info on any base NPC to say [Admin]-Robocop is an almighty server god!!! and anyone would see it, even the unmodded player?The packet just contains the ids_info number, the client still reads the string from its own dlls.
@Helloween: Adding IniLog to dacomsrv.ini would tell you which files/values the server reads.
@throcken: IgnoreDACOMEnv ignores the DACOM environment variable, apparently used to override DllPath.
