Player control plugin
-
The plugin requires that freelancer.ini exists so that it can find information from the ini files. If you have renamed ‘freelancer.ini’ then you need to make a copy of it named ‘freelancer.ini’ so that the plugin can find it.
@Syd: What problem are you having and can you provide the full text of the error message?
-
@Syd : You need to install Freelancer SDK before using FLPlayerControl. (Can be found HERE )
Cannon, we really don’t want to be boring, but there’s still something we need to know :
The compilation has been passed with success using Microsoft Visual C++ Express (in it’s latest version). InGame, the plugin seems to be working quite well (commands like /stuck, /dice, or /pos are working perfectly). But for unknown reasons, human players don’t loot nothing…
When we just replace our half-working DLL with the one in the ZIP archive, all is working.
So here are my guesses :
- We are using VC++ with bad compilation options (or bad version ?)
- We need to add something in the linker or somewhere else (like FlakCommon.lib ? even if we already tried), or some headers or .cpp files
- There might be a problem with the .cpp files given in the archive.
Could you help us ?
Thanks in advance,
Kid -
Cannon wrote:
The plugin requires that freelancer.ini exists so that it can find information from the ini files. If you have renamed ‘freelancer.ini’ then you need to make a copy of it named ‘freelancer.ini’ so that the plugin can find it.No, that’s not our problem. Because we rename ‘freelancer.ini’ only in the client version of the mod, but not in the server version
Renaming ‘freelancer.ini’ works perfectly : players can’t use Flexplorer, companion, data storm… And we started making RP quests with hiding depots or wrecks in the mod. The only way to find these objects… visit NPC with rumors. As I say, more fun
For our problem with player control plugin, always the same thing : a dead player doesn’t lose nanobots, shield batteries and ammo in his cargo after death.
Edit : It seems that you used Visual studio 7 (or Visual studio .NET 2002) to code ‘player control plugin’, right ?
-
Finaly, we did it.
This is our modification of Cannon’s player control plugin :
- when a player dies, he loses all ammos, nanobots and shield batteries. No cheat with double cargo.
- additionnal commodities : 1 escape pod and some scrap metal.
- all lootcrates have their specific design in space, not only one.
- a command /pvp. When a player does that command, and fights against another player who does the same thing, they don’t drop anything and don’t lose ammo, nanobots and shield batteries. But if a player commits a suicide (selfkills include) with /pvp, he drops his cargo and loses all of it anyway.
When a ‘pvp’ player attacks a ‘nopvp’ player, he couldn’t do any damage to this player.
When a ‘nopvp’ player attacks a ‘pvp’ player, a message tells it to players around, and the /pvp command is removed. - in the original player control plugin, the number of cargo dropped is based on the quantity that the player had at its last backup (entry system, off a base …). Our version does a calculation based on the amount at the time of death of the player. It’s better for chasing a player who just stoled weapons on wrecks.
Thanks to Kidsquale who did that great job. And, of course, Thanks to M0tah, V0dka and Cannon who develop FLHook plugin !
If someone wants some information, or wants to try our modified version of player control plugin, just ask. -
we found another problem that disturbs us a little bit in our work on FLSES, you can’t access any of your admin commands via telnet.
Take a look at thefollowing tempban plugin functions on how to do it:
EXPORT bool ExecuteCommandString_Callback(CCmds* classptr, wstring wscCmd) { returncode = NOFUNCTIONCALL; // flhook needs to care about our return code if(IS_CMD("tempban")) { returncode = SKIPPLUGINS_NOFUNCTIONCALL; // do not let other plugins kick in since we now handle the command CmdTempBan(classptr, classptr->ArgCharname(1), classptr->ArgInt(2)); return true; } return false; }and for an entry in the consoles help command:
EXPORT void CmdHelp_Callback(CCmds* classptr) { returncode = DEFAULT_RETURNCODE; classptr->Print(L"tempban <charname>\n"); }</charname>we may include that to our version on Sirius Hegemonia, and send it to you
EDIT: Sorry haven’t seen it’s in V1.0 of your plugin
-
Ladwin wrote:
Finaly, we did it.This is our modification of Cannon’s player control plugin :
.
.
.If someone wants some information, or wants to try our modified version of player control plugin, just ask.
Is still an offer valid? I wanna try it. Or is the public one same?
So far with current public available I got 2 small problems:
1. I made new scanner which only one ship has it (nomad fighter) and is available trough /restart command. Also it suppose to be used for rep-fixer which through plugin I can set it as item that cant be lost/seen.This doesn’t work!
2. The odd thing is now present with pimping lights. As I was convinced that involving buyable engines to the mod and thus revealing invisible hardpoint in game the lights cant be pimped.
But now, even after removing engines from mod I still cant get full setup shown!
(Eagle in this case)Suddenly it stopped to work in full!
For 1. case is maybe the addon = ge_s_scanner_03, internal, 1 as no external hp type of item? I tried also mounted/unmounted settings.
NOTE: Im not in rush and this isnt on fire, so easy - other important stuff 1st to be solved.
THANK YOU ALL !
-
Back to story.
Sry all and especially Cannon who is busy with 1.6.1 but with this 2 things left to solve (look previous post) lets focus on 1st.
I attached all relevant evidence which concerns this control.
Some of details:- On server, nomad faction players (not listed in rep list) which holds place of fc_f_grp cant fix permanently hostile reputation towards civilian factions.
- Even changes to empathy.ini
<data file="DATA\MISSIONS\empathy.ini" method="sectionreplace">[RepChangeEffects] group = fc_f_grp <dest>event = object_destruction, -0.030000 event = random_mission_success, 0.140000 event = random_mission_failure, -0.045000 event = random_mission_abortion, -0.067500</dest> <source> event = object_destruction, 0 event = random_mission_success, 0 event = random_mission_failure, 0 event = random_mission_abortion, 0</data> ```not do a trick. Any suggestion why? -
I think you misunderstand how the reputation fixer works. It changes the reputation only on the ships that mount the item. It does not change the reputation of other ships.
I think you want all players who do not mount ge_s_scanner_03 to be hostile to fc_f_grp.
To do this, you need an item that is mounted by other ships and set the reputation for fc_f_grp to -0.9 for this item. For example: [ge_s_scanner_02]
fc_f_grp = -0.90, 1The alternative way to do this is to make non nomad ship hostile when the ship is are created for the first time. I think you set the initial reputations in the multiplayer.fl file.
-
Cannon wrote:
I think you want all players who do not mount ge_s_scanner_03 to be hostile to fc_f_grp.No. I need opposite fix. All players that have ge_s_scanner_03 to be hostile to all other factions (except fc_n_grp - NPC nomads).
As it is now for example, nomads can dock Malta
- see attachment!Don’t know what mpnewcharacter.fl has effect on this which is set to be Freelancer faction.
mpnewcharacter.fl[Player] name = %%NAME%% rank = 28 house = 0, li_n_grp house = 0, li_lsf_grp house = 0, li_p_grp house = 0, br_n_grp house = 0, br_p_grp house = 0, ku_n_grp house = 0, ku_p_grp house = 0, rh_n_grp house = 0, rh_p_grp house = 0, co_alg_grp house = 0, co_be_grp house = 0, br_m_grp house = 0, co_nws_grp house = 0, co_hsp_grp house = 0, co_ic_grp house = 0, co_khc_grp house = 0, co_kt_grp house = 0, rh_m_grp house = 0, co_me_grp house = 0, co_ni_grp house = 0, co_os_grp house = 0, co_rs_grp house = 0, co_shi_grp house = 0, co_ss_grp house = 0, co_ti_grp house = 0, co_vr_grp house = 0, fc_bd_grp house = 0, fc_b_grp house = 0, fc_c_grp house = 0, fc_fa_grp house = 0, fc_g_grp house = 0, fc_gc_grp house = 0, fc_h_grp house = 0, fc_j_grp house = 0, fc_lh_grp house = 0, fc_lr_grp house = 0, fc_lwb_grp house = 0, fc_m_grp house = 0, fc_ou_grp house = 0, fc_rh_grp house = 0, fc_or_grp house = 0, fc_u_grp house = 0, fc_x_grp house = 0, gd_gm_grp house = -0.65, fc_uk_grp house = -0.65, fc_n_grp house = -0.65, fc_ln_grp house = -0.65, fc_kn_grp house = -0.65, fc_rn_grp house = 0.91, fc_ouk_grp house = 0, fc_q_grp house = -0.65, fc_f_grp house = 0, gd_im_grp house = 0, gd_z_grp house = 0, gd_bh_grp rep_group = fc_ouk_grp money = 10000 . . . -
sumanuti wrote:
2. The odd thing is now present with pimping lights. As I was convinced that involving buyable engines to the mod and thus revealing invisible hardpoint in game the lights cant be pimped.
But now, even after removing engines from mod I still cant get full setup shown!
(Eagle in this case)Suddenly it stopped to work in full!
Possible the cause is custom setup on some eagles I have:
equip = 2521707779, HpRunningLight01, 1 ; FastLargeRed
equip = 2521707779, HpRunningLight03, 1 ; FastLargeRed
equip = 2521707779, HpRunningLight04, 1 ; FastLargeRed
equip = 2824251401, HpRunningLight01, 1 ; FastLargeBlue
equip = 2824251401, HpRunningLight03, 1 ; FastLargeBlue
equip = 2824251401, HpRunningLight04, 1 ; FastLargeBlue
Regular eagles with regular setup also fail to show correctly.
