Serverside or Clientside?
-
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.