The online racing simulator
DLL Implamentation (Callback on Event)
Quote from Gai-Luron :
Quote from Dygear :InSim direct DLL that allows for direct plugin development utilizing a callback mechanism. (When player pits, call function player_pits() on each plugin if the function exists within the plugin.)

I have added this feature in experimental LFSLapper to add plugin in DLL, but i don't know if there are people who want or can use that.

I have some ideas on the subject, and have made this thread to disscuss that.

I'm not going to type out the details on my iPhone, but I will when I get home, does anyone else have any ideas on the subject.
Native & Callback Functions.

Native functions are the run on demand functions, where as callback functions are run as a result of an event. A callback function would be the bread and butter of the InSim plugin system, with the native functions providing support inside of the callbacks.

When InSim sends a NPL (New PLayer) packet, the client_connect() callback function is run within each plugin. That client_connect function within the plugin will contain some native functions that might cause an event. An example of this is as follows.


<?php 
#include <lfs>

public plugin_init() {
    
register_plugin("Hello On Connect""1.00""Dygear");
}

public 
client_connect(id) {
    
server_cmd("/mso Hello %s"get_user_name(id));
}
?>

Here the callback function is client_connect, where as the get_user_name function is the native.
*sigh* Swing, and a miss.
Hello,

it's that i say, i don't know if much people have interest to write DLL.

Gai-Luron
#5 - Krayy
From my perspective, you can do pretty much all you need to be able to do with LFS in Lapper and GLScript.

DLL extensions would only really be useful in an Outsim app (as opposed to an Insm one) for sending or receiving data to or from peripherals (guages, joysticks, gamepads etc).
Would be cool if natively implemented by Scawen but he maybe had his reasons to choose TCP instead.

It's good for script languages, yes...
Hello,

I think reason is that you can put application on different computer, one for LFS and other for insim app


Gai-Luron
Quote from CLRS530 :Would be cool if natively implemented by Scawen but he maybe had his reasons to choose TCP instead.

It's good for script languages, yes...

If Scawen is reading this, I would love for him to take a look at the AMX Mod X, and Source Mod. They have some awesome ideas that I would love to see implemented in LFS, even if just on a small level. The idea is that scawen makes a client.dll / server.dll file, that we can replace with out own dll. That will allow us to hook into the engine directly, and allow for the use of plugins.

I want direct engine hooks that will allow me the change the drag coefficient of the front wing, and rear wing on the fly, I want total control of the wing angle at all times. I want to be able to change the displacement of the engine with a function call, and then also change it's type and configuration. I want client functions, that will allow me to hook into the chat system. I want functions that will allow me to edit the engine fired RCMs, and any of the 'buttons' (like that of the build in connection menu) so that I can change the color to anything that I want, with any alpha level (both button background and text), and any border radius plus callbacks for when a new button is added.
I doubt we will see this anytime soon, although I see where you're coming from. RBR uses a DLL plug-in system like that, just not quite as "invasive" as you describe your ideal LFS system.

I think it's generally a good idea, but anything beyond regular InSim functionality should wait till S3 final.
Quote from morpha :I think it's generally a good idea, but anything beyond regular InSim functionality should wait till S3 final.

I understand where you coming from, and I totally respect it, but there is a problem with waiting until S3 final. That problem is, if you don't program with modifications in mind from the get go, you become stuck when you wish to add them on later. I believe that Scawen is one of those programmers that can pull this off from any angle, but I think the path of lease resistance is the best approach not only for development, but also for it's use.

RBR might have had something like this, but the Half Life engine, with the likes of Meta Mod, and AMX Mod back in the days CS1.5 was and standard of programming. Then we moved over to AMX Mod X and again, Metamod, who again set the standard of programming, mind you this was 5, 6 years ago. Now it's still AMX Mod X, and Source Mod paving the way with Metamod and Metasource respectively. The devs at valve are wiping the floor with 3rd party, community addons, and it would be best to learn from there example 10 years ago, as it's the reason why they are still so popular today. Why should the devs have to continue to make this game interesting, when the community has some much programming talent (with the likes of Gai-Luron, the_angry_angel, filur, darktimes, T-RonX, elmohellno, MaKaKaZo, xergio, rheiser, dougie-lampkin, JamesF1, and the devs them selfs!) they don't need access to the source to make an awesome addon.

The past has shown the future is about community development, and LFS is starving from some content right now. Let the community add that content, give the programmers the tools they need to make great additions to the game. Yes, some of the functions due leave the door open for abuse, but the community will police it's self just as it does with bad servers. Let's grow this community and make it stronger, because I have never seen a more motivated group of users, and mod and admins before in my life. Given the right tools this game could live for 10 years, it might even live for 20.

Just give us the tools, our imagination should be our only limit.
List of Native, Callbacks and Functions
  • Natives
    • General
      • get_clients(); -- Returns Array of All Connected Ids.
      • get_spectators(); -- Returns Array of Spectators Ids
      • get_players(); -- Returns Array of All Drivers Ids Currently on Track.
      • get_grid(); -- Returns Array of Ids for Each Driver on Grid.
      • get_places(); -- Returns Array of Ids from 1st to Last.
      • get_sectors(); -- Returns Array of What Id is in What Sectors
    • Server
      • get_server_slots(); -- Returns Int of Servers Max Slots.
    • Track
      • get_track_nodes(); -- Returns Int of Nodes on Track.
      • get_track_sectors(); -- Returns Int of Total Sectors on Track.
    • Client
      • get_client_info(uint id); -- Returns Array of Client Information.
      • get_client_place(uint id); -- Returns the Current Place of Driver.
      • get_client_sector(uint id); -- Returns the Current Sector of Driver.
      • get_client_time(uint id); -- Returns the Current Total Time of Driver.
      • get_client_laps(uint id); -- Returns the Current Lap Driver is on.
      • get_cleint_laptime(uint id); -- Returns the Current Lap Time for Driver.
      • get_client_split(uint id, uint sector); -- Returns the Split time for Given Driver's Sector.
      • get_client_speed(uint id, float speed); -- Returns the Current Speed of the Car.
      • get/set_client_drag(uint id, ufloat drag); -- The drag coeffecnt of car.
      • get/set_client_wing(uint id, uint front, uint back); -- Wing angle for front and back.
      • get/set_client_engine_cylinders(uint id, uint cylinders); -- Engine Type (V, Inline, Flat).
      • get/set_client_engine_config(uint id, E_TYPES type); -- Engine Configuration (V, Inline, Flat).
      • get/set_client_engine_intake(unit id, float occluded); -- Can be negative, making a bigger hole.
  • Callbacks
    • on_connect(uint id, bool admin); -- When a client connects to server.
    • on_disconnect(uint id); -- When a client diconnects to server.
    • on_join(uint id); -- When a client joins the race.
    • on_pit(uint id); -- When a client Shift+S.
    • on_race(); -- When a new race session starts.
    • on_qual(); -- When a new qulification session starts.
    • on_cruse(); -- When a new cruse session starts.
    • on_pit_entry(uint id); -- When a client enters the pits.
    • on_pit_exit(uint id); -- When a client exits the pits.
    • on_split(uint id, ufloat time); -- When a client splits.
    • on_lap(uint id, ufloat time, uint lap); -- When a client enters a new lap.
    • on_spectate(uint id); -- When a client joins to spectators.
    • on_rcm(string msg[]); -- When a RCM is emitted.
    • on_say(uint id, string msg[]); -- When a client speaks.

FGED GREDG RDFGDR GSFDG