Quote :

The IS_OCO packet works fine, I tested all aspects of it. I don't know what your issue is so you might need to go into more detail. The problem I was having was that I wasn't optimising the layout before trying to use the lights.

Confirmed, I wasn't aware of that. Somehow never thought of that. It works fine now, but I still have to check when optimising through InSim IS_AXM. I just tested an optimised LFS layout.

Quote :

Yes, checkpoints and circles are only detected if you drive above them.

How does LFS manage InSim checkpoints with same x,y,h but different z? When you drive above them is there a max height you can be above them for the detection to work?

Quote :

A question about IS_PLC - I'm considering trying to update its function today. It has been requested to make it as strong as the /cars command.

1) It would force you to spectate if you were driving a car that you are no longer allowed.

2) A disallowed car could not be 'already selected' so that means you wouldn't be able to join with it.

Would there be any problems with this?

This would be a welcome improvement although I try to think of situations where it could be useful to "overwrite" IS_PLC with /cars. Would /cars be ignored by IS_PLC so that you can actually select a car which is not enabled by /cars as that sounds like a bad idea. IS_PLC should remain less powerful than /cars but this will still be the case or did I miss the point?

Other observations:

• Is it intentional that a race car spawned by IS_JRR has pit speed limiter turned on by default?

• I always found it annoying that you can't force a player to click GO when you did /end and changed to a new /track. Is there no way to force the track to show so that you don't have to wait for the players who clicked "join race" to click "GO"? (It would be useful for automatic track rotations)

EDIT:
One more suggestion. When /canreset=no you get "Car reset is not allowed on this host" and no IS_CRS reply is sent. If instead you still send it, with IS_JRR it would be easy to decide if the player who wanted to reset is allowed to reset or not but you would have to remove the "Car reset is not allowed on this host" message.

Last edited by sicotange, Thu 11 Feb 2016, 16:43.

Ok that seems to work well! However I don't understand the use of:

Quote :

enum
{
OCO_ZERO, // reserved
OCO_1, //
OCO_2, //
OCO_3, //
OCO_LIGHTS_RESET, // give up control of all lights
OCO_LIGHTS_SET, // use Data byte to set the bulbs
OCO_LIGHTS_UNSET, // give up control of the specified lights OCO_NUM
};

I still haven't found the issue with IS_OCO for autocross startlights. I was hoping to get this ready for tonight. Anyway, perhaps you will quickly find the problem.

Still haven't looked enough into GitHub but I can still make 1 small contribution (see attachment). The files attached are those I made or modified. The other files remain untouched.

NOTE: Can you check IS_TTC.cs in debt? I have tested my implementations and IS_TTC seems to work well (replied by IS_AXM etc.). Can you still double check as I am not 100% confident of what I modified.

Quote :

I can change the main start lights but not the AutoX ones.

I'm almost certain BulbInfo is still bugged. Setting main start lights works half but certainly not correctly.

By the way, any chance on implementing IS_TTC tonight? If not I might attempt it, I want to have a version ready for tomorrow because I might be away this weekend.

I suppose you already read this?

https://www.lfs.net/forum/post/1903173#post1903173

I still can't make it work properly.

Quote :

Sico, how does that animated gate work? Is that a new kind of feature in these test patches?

These are just selections of autocross objects opened/closed by the new InSim checkpoints.

Quoting GitHub:

Quote :

Updated for 6K20, added IS_OCO packet and associated enums.

DarkTimes, I made an account on GitHub. I haven't looked into it enough yet to help but I'm tracking down an IS_OCO bug. I can make track start lights work although there seems to be an issue with BulbInfo. On the other hand setting the movable lights (autocross object: AXO_START_LIGHTS (index 149)) won't work at all.

Last edited by sicotange, Wed 10 Feb 2016, 19:18.

Quote :

I suppose it's cruise mode, but practice mode would also work, I guess.

The server you joined this morning is in cruise mode.

Quote :

I joined this morning but it didn't seem to be in race mode. Maybe there's a good time later today or this evening?

Anytime is fine today, the program is now in race mode. Anyone is welcome, it needs testing

EDIT:

Server is 0.6K20 version

Last edited by sicotange, Wed 10 Feb 2016, 11:11.

Quote :

How did you implement start lights? Now you can use the start light object, using a separate ID per racing area.

That will be fun to implement

At the moment I just use buttons as start lights.

Quote :

Do you run the race in practice mode?

Do you mean /laps=0? I don't understand.

Quote :

Looks good. I'd like to experience that.

You are obviously welcome to join my testserver called testing for a quick test if you want to.

Last edited by sicotange, Tue 9 Feb 2016, 23:08.

Quote :

I'm not sure what you mean by this. Some AXM packets do have the UCID set. Please can you explain what situation you mean. Is it a packet going into or out of LFS? I'm a bit tired, hopefully will understand when I read your reply!

A packet going into LFS. To put it bluntly:
• Player x types command !i_want_objects_added_here
• InSim program creates the IS_AXM and assigns the UCID of the player to the IS_AXM packet UCID
• InSim program sends the packet
• LFS receives the packet, adds (or deletes) the objects and sends the IS_AXM reply

That IS_AXM reply with that player UCID can be useful. The InSim program can detect exactly who sent IS_AXMs and when they are received. It's the same as what LFS reports when a player adds an object using the LFS autocross editor only for custom InSim IS_AXM packets.

In the end after some thought I think it's a messy explanation and probably only useful to me but on the other hand I maintain that TINY_SEL on multiplayer hosts would be nice

Quote :

Yes, the selection must be all Index < AXO_NUM or all Index >= 252 (circles / insim checkpoint).

Good to know

EDIT:

Quote :

Please let me know if it seems there is enough to do your ideas like multiple races in one environment, or if something else would help.

To answer your question from a few pages back. I successfully tested this multiple race idea running 3 races on Westhill simultaneously. It works seamlessly (although that might be another story on a packed server). But InSim wise it is now easy to implement multiple races.

Last edited by sicotange, Tue 9 Feb 2016, 22:18.

Quote :

Changes from 0.6K18 to 0.6K19 :
Changes from 0.6K17 to 0.6K18 :

Thanks a lot for these new features and improvements!

Quote :

New IS_AXM option PMO_SELECTION to set the current editor selection

As LFS dedi reports TINY_SEL - not for dedicated host I suppose it is a no-go to try to lift this restriction by being able to set the UCID from the IS_AXM (with PMO_SELECTION) so that this also works online?

It can also be useful to send an IS_AXM (with PMO_ADD_OBJECTS or PMO_DEL_OBJECTS) with UCID set so that you can easily know who sent the IS_AXM. But it comes outside my jurisdiction, I suppose this is not easy to implement?

Also, when your selection is a combination of objects and marshalls, the marshalls are excluded from the selection. I'm sure this has been thought through but can you confirm this is the right thing to do?

Quote :

I can send a IS_AXM with PMO_SELECTION set and it will select the specified objects.

Sorry, I wasted your time. This does work well (apart from 1 anomaly I will report). I didn't think things through and thought it would work on a host (without UCID "setable" it should have been obvious it isn't possible so LFS dedi reported "TINY_SEL - not for dedicated host".

Small typo:

Quote :

public enum ActionFlags {
/// <summary>
/// Sent by the layout loading system only.
/// </summary>
PMO_LOADING_FILE,

/// <summary>
/// Adding objects (from InSim or editor).
/// </summary>
PMO_ADD_OBJECTS,

/// <summary>
/// Delete objects (from InSim or editor).
/// </summary>
PMO_DEL_OBJECTS,

/// <summary>
/// Clear all objects (NumO must be zero).
/// </summary>
PMO_CLEAR_ALL,

/// <summary>
/// A reply to a TINY_AXM request.
/// </summary>
PMO_TINY_AXM,

/// <summary>
/// A reply to a TINY_SELL request.
/// </summary>
PMIO_TINY_SEL,

/// <summary>
/// Set the current editor selection.
/// </summary>
PMO_SELECTION,
}

Firstly, thanks for the information. Granted at the moment my program doesn't deal with unicode. It is a mistake but it is mainly because I could happily throw any string at InSim.NET without it complaining or give distorted results.

Quote :

Edit: OK - just to help you out these are the three unicode characters you're using.
\u00D7
\u25B2
\u25BC

Your quick fix gave semi-distorted results (see attachment). The red cross is fine but those arrows now have an unwanted dot behind them. Could it be related to the issue PeterN reported: https://www.lfs.net/forum/post/1901919#post1901919


Secondly, all InSim.NET updates (in sync with Scawen's patches, thanks for that) went fine until the last one concerning 0.6K18 & 0.6K19. I'm talking about the IS_AXM updates. I had to fix some things with PMOFlags (cast enum to byte and vice versa) but the recent implementations quoted below don't seem to work. Am I missing something? Could you check please before I report it in the incompatible test patch thread. I have a vague suspicion it is InSim.NET related.

Quote :

Changes from 0.6K17 to 0.6K18 :

InSim :

Added TINY_SEL to request an IS_AXM with layout editor selection
New IS_AXM option PMO_SELECTION to set the current editor selection

Quote :

All of this code is freshly written, there was a lot to change, and almost certainly it will have bugs.

This quite a big change to the library. For now all you need to know is that InSim.NET no longer tries to hide language tags (^L, ^J etc..) from you. These will appear in strings sent from LFS but also you can use them to hint to InSim.NET what the correct encoding for a string is.

I hate to bring you the bad news, I hope it is an easy fix (?) (see attachment).

Quote :

public const string EXIT_BUTTON_RED = "^1^S¡Á"; //NOT OK
public const string ARROW_UP = "^H¡¶"; //NOT OK
public const string ARROW_DOWN = "^H¡¿"; //NOT OK
public const string ARROW_LEFT = "‹"; //OK displays correctly
public const string ARROW_RIGHT = "›"; //OK displays correctly

The strings above give the following output (EXIT_BUTTON_RED should have been a red cross in upper right corner):

Quote :

This may be a silly question, but what's the problem that occurs when you send all those buttons to all those players? Is it that there is an error, does the connection close, does LFS grumble, or is it just really slow? I know we may have talked about this before, but I don't work on the library often and so will forget things. The main problem is that I don't have a server with 47 players to test it on, I just test on my own machine, and in that case I can send 239 buttons each with 240 characters of text over and over again and it works fine.

I can actually reproduce it easily. If I send 200 buttons continuously to several players online this is the result after less than a minute:

Quote :

07/02/2016 21:19:29 System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.BeginReceive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, AsyncCallback callback, Object state)
at System.Net.Sockets.NetworkStream.BeginRead(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.BeginRead(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.IO.Stream.<BeginEndReadAsync>b__d(Stream stream, ReadWriteParameters args, AsyncCallback callback, Object state)
at System.Threading.Tasks.TaskFactory`1.FromAsyncTrim[TInstance,TArgs](TInstance thisRef, TArgs args, Func`5 beginMethod, Func`3 endMethod)
at System.IO.Stream.BeginEndReadAsync(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.Stream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
at System.IO.Stream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count)
at InSimDotNet.TcpSocket.<ReceiveAsync>d__50.MoveNext()

It seems to slow down over time and then fail eventually.

Ignore the time of the logs (I did several tests) but this is what LFS dedi reports near the crash:

Quote :

Feb 07 21:28:13 TCP ERROR : INSIM LIMIT
Feb 07 21:28:13 INSIM ERROR : INSIM LIMIT
Feb 07 21:28:13 TCP ERROR : INSIM LIMIT
Feb 07 21:28:13 INSIM ERROR : WOULDBLOCK
Feb 07 21:28:13 TCP ERROR : INSIM LIMIT
Feb 07 21:28:13 INSIM ERROR : INSIM LIMIT
Feb 07 21:28:13 TCP ERROR : INSIM LIMIT
Feb 07 21:28:13 FATAL INSIM ERROR : BUFFER SIZE
Feb 07 21:28:13 InSim closed : ClaViCo

Quote :

Layout editor :

Multiple object selection is now available in marshall mode

Fixes :

Quick repeat moving checkpoints in multiplayer caused duplication

Nothing to report so far, it seems to work well

EDIT:
(Just for the sake of reporting, when doing multiple object selections in marshall mode, you can't adjust the width of InSim checkpoints or diameter of InSim circles. I can't picture situations where it would be crucially important to be able to do this anyway.)

OFF-TOPIC:

One small suggestion. In the autocross editor you can right click the X Y Z arrows for incrementation to move your object faster. What about having this also for concrete objects flags (WIDTH, LENGTH, HEIGHT, SIZEX, SIZEY, PITCH, ANGLE).

For example:
• Increment factor 2 when right click width arrows.
• Increment factor 3 when right click pitch arrows.

It would make it easier to make a horizontal slab object (pitch 0°) vertical (pitch 90°) for example.

Last edited by sicotange, Sat 6 Feb 2016, 11:52.

Yes, you can't ground level check your object again once the dot is blue. I always thought it was a design choice. Although it works with InSim IS_AXM.

Quote :

If you could try and give me an example of the kinds of characters that cause the problem that would be helpful.

I have a note somewhere about this. I will get back to you once I can give you info on how to reproduce it easily.

Quote :

Again, not sure what you mean. Could you explain what you mean by overflow and can you give me an example of how you currently need to deal with them?

For example, you have a panel of 200 buttons. All 47 players of a full server should be shown this panel at the same time. I'm looking for the best & fastest way to do this. Same for buttons who get updated often (text updates every 100ms of several buttons for example). Basically a way to queue packets, making batches and send them at appropriate intervals. You master this stuff. I don't have enough knowledge about sockets & netcode to implement this well.

Quote :

This falls into the same category as ButtonHelper. It's not something I would add to the main library but could be added to the helpers section.

Thanks for the library updates (EventHelper & 0.6K13). I will test EventHelper once I'm done updating my program with IS_UCO & IS_JRR.

So far so good except for 1 little artefact. When you add an InSim checkpoint and spam the arrows in the autocross editor to move the InSim checkpoint a new InSim checkpoint is added at that position. It doesn't happen with InSim circles.

With marshall objects there was always that odd "Can't add : intersecting object" message when you move the object with the arrows.

OFF-TOPIC:
Another (old) artefact but unrelated to 0.6K (or 0.6J) is that you can't select multiple marshall objects (CTRL +) but I'm sure you are well aware of this. Or is this intentional?

Quote :

I've just increased MAX_CIRCLES from 120 to 180. That covers these:

const int CIRCLE_IS_CP = 252; // insim checkpoint
const int CIRCLE_IS_AREA = 253; // insim circle
const int CIRCLE_MARSHALL = 254; // restricted area
const int CIRCLE_ROUTE = 255; // route checker

Such a clean implementation


One more inquiry, is there any shareable data available concerning:

• The autocross objects dimensions.
• The cars dimensions.
• The center of gravity of the cars.

I'm asking because if it's easy to share, this data can be useful. For example when adding objects relative to a car or organising grids (the gap you should leave between cars at start). It's unimportant so don't bother if it's no easy copy/paste.

Quote :

I have done a few small things today, most notably I have changed the InSim.Send(IEnumerable<ISendable>) method to be InSim.Send(params ISendable[]) instead.

This makes sending packets in batches simpler. Now you can just do this:

Cool improvement

Quote :

As I am in the mood to update the library let me know of any features you want added or bugs you want fixed.

• A very old bug you are probably aware of is IS_BTN special characters problem. Some special characters result in a bugged output. I forgot how to reproduce it easily (I think it was a combination of special characters).
Either way, it's not a big nuisance.

There are a few suggestions I have for InSim.NET:

• A fool proof packet buffer (mainly concerning IS_BTN's): insim.NET would deal appropriately with the many buttons sent so you wouldn't have to worry about overflows etc. For IS_AXM I use the safe LFS system for example (wait for packet arrival, then send new packet).

• A button manager: I made a far from ideal button manager where I group buttons (parent -> child). Maybe you know the perfect way to deal cleanly with buttons (clickID & text updates)?

• Improving the socket loss detection (the error I mailed you) to improve our chances to catch the reason of the disconnection.

• An event manager: it seems to be a pain to maintain 8 InSim connections with all packet events bound. Maybe you have some clearer thought about this?

Quote :

The packet to place InSim objects into the selected objects is on my notes and as far as I know it shouldn't be a problem.

I'm prioritising the incompatible things but do hope to do that as well.

Looking forward to this!

Quote :

Would it be better to drop the route checker style sequence?

Personally, I'm not fond of the route checker ID sequence. I suppose it isn't possible to have the same indexing system as Start Position & Pit Start Point?

Quote :

Preview of the IS_UCO:

Looks great so far

Will the InSim checkpoints & circles be reported by IS_AXM? And will there be a limit to the amount of InSim checkpoints?

OFF-topic:

Quote :

I am very helpful for the last seven years. And what you want is not helpful, for him. Stop thinking about your own personal interest. It's very arrogant.

And yes I would say exactly the same face-to-face. Thats even better because you don't miss the body language and tone of it. (Which probably makes everything a bit softer instead of stronger). Dirt? It's just what it is. Nothing to do with dirt. I am very direct you know. By the way, I don't know you.

@cargame.nl: So much frustration and animosity...I'm not going to respond to your personal attacks, I'm only interested in LFS development and this thread is about exactly that.
You don't seem to realise the chance you have to directly correspond with the game developers. With such hostility, no wonder some game developers avoid public fora like the plague.

cargame.nl, do you realise you wouldn't dare to say half of what you said if you were face-to-face with the people you throw dirt at?

Instead of being destructive why don't you do something helpful like contacting him?