Ok, now that I see the full code block it all makes sense now. I've been living in the world of bridged connections for the past few weeks as I'm been fiddling with network settings within WiFi routers. I just assumed that packets can be seen by other InSim instances. I've forgotten most of the the stuff that I've myself wrote and most of the rules that InSim uses. Not an inspiring bit of news from a Dev, huh!?

This is from what I understand of the InSim.txt file. Nowhere does it say that a ISM packet will also get all of the information for the clients and players. It simply get's the information about a host that you join or create in so far as it's host name. The requests you see are needed when PRISM is running by it's self. So that it can get the information. I think that AIRIO is doing the same thing that I am doing in so far as questing all connections, all players and then all results. That's why you are seeing the double packets.

Well, the state handler does get it's stateful information at startup from there. But as you said AIRO is already getting those packets, then PRISM does not have to request them. But if you were running PRISM standalone, then you would want to keep those lines in there. Unless you are saying that PRISM is it's self request two sets of cars and clients data.

As long as you understand the ramifications of doing that, then it's fine. Your not running PRISM stand alone, so it does not really matter. On another note, PHP 5.5.0 was released two days ago. I have it up and running on half of my web servers. So far, so good.

Quote from Shotglass :

what if he lives in the middle of the sahara?

The term, "shit out of luck", comes to mind.

Quote from dawesdust_12 :

Sell a man a fish, and you're rich.

Can't argue with the logic.

Give a man a fish he eats for a day, teach a man to fish he eats for a life time.

Quote from dawesdust_12 :

Alright, here goes my usual spiel:

Tonikuu: You are attempting to program features into a Cruise application. One of the key skills one must have when programming any application is knowledge of the language and frameworks that they are using in order to achieve their end goal.

It is clear from this thread that you don't have the required programming skills to work with LFSExternal or even C# itself. Programming is not an exercise in copy and paste. It requires understanding of what you are doing, so that when things DON'T work you are able to debug and repair them.

I would suggest that you learn how to program before attempting to modify this Cruise application. You're trying to sprint before you know how to walk, which won't end well.

TL;DR

In order to program, one must learn how to program.

A shocking revelation I'm sure.

Not without seeing the file format first.

Quote from PoVo :

Nobody else but the end user (customer) has access to this file and I really doubt they would write anything malicious into the file when it's being used for their own website.

That's the point tho. Just because it's supposed to only be used by the program it's still an attack vector for someone to use if the file was writable on the server it could become an attack surface for something else. Whereas file_get_contents would be a much more appropriate use as it does not introduce this attack vector.

You can just echo file_get_contents(), there is no need for the variable.

It's a possible security risk.

To bad really, how awesome would it be to make "InTweak".

I can't load any of your images, Tim, so I don't know for sure what went wrong. But it looks like you got the answer from Dustin anyway.

[Edit]Never mind, they are loading for me now. The last image you posted with color is as much data as you can get out of the SMX files unfortunately. There is some sort of relationship between that and the texture files as well, I'm sure of it but I never really got so far as to check it out.

Last edited by Dygear, Fri, 24 May 2013 09:42.

Awesome, I'm glad it worked out! Keep it up!

The pth files have the racing line built into them. I'd love to see these items rebuilt to reflect the racing lines used by the WR holders for each track and car combination. You could then use this as a baseline for comparison as to how the algorithm is doing.

I still don't have access to an IPv6 address space on the Verizon FiOS (Fiber Optic) network. But once I do, I'll start checking it out!

Quote from szaboaz :

I'm thinking, what if the buffer receives more than one packet's bytes within the same cycle of the forever running loop. buffer.position() will never be equal to size then...

If that can happen, the next packet size reading would be in trouble (either missing whole packet or packets, or worse, reading an arbitrary byte from the middle of a packet)...

With TCP / UDP connections, there can be times where you only get a single byte of the packet. For this reason, the first byte of every InSim packet is the size, and all of the packets are less then 256 bytes. So as long as your not getting corrupted packets, you should always know when you have an whole packet to parse.

buttonRequsted(UCID); - For IS_BFN::BFN_REQUEST (Callback)
buttonDelete(UCID, ClickID) - For IS_BFN::BFN_DEL_BTN
buttonClear(UCID); - For IS_BFN::BFN_CLEAR
buttonCreate(UCID, L, T, W, H, Text, Inst = NULL, BStyle = NULL); - For IS_BTN with TypeIn = 0 (Returns ClickID).
buttonTextbox(UCID, L, T, W, H, Text, Inst = NULL, BStyle = NULL); - For IS_BTN with TypeIn > 0 (Returns ClickID).
buttonClick(UCID, ClickID, CFlags); - For IS_BTC (Callback)
buttonType(UCID, ClickID, Text); - For IS_BTT (Callback)

Something like this?


What it really comes down to, can you abstract away ClickID's and still have a meaningful relationship between the buttons?

I know we are gettting slightly off topic, but I just wanted to say that I also compile from source and never had any issues. I run through these commands every time I update.


This always seems to work better, faster then just adding modules at run time.

Quote from Requirements :

Requirements

You will need nothing if the system you are using is one of the recent POSIX-compliant systems because standard C libraries that are supplied in them must provide iconv facility. Otherwise, you have to get the » libiconv library installed in your system.

Quote from Installation :

Installation

This extension is enabled by default, although it may be disabled by compiling with --without-iconv.

After reading these two things, I feel a lot better about it requiring iconv.

It's kinda like a smaller version of the ECMA-48. It's kinda crazy, but in the grand scheme of things, it's a lot better implemented then some of the alternatives.

Also, I did not know about the bug. If you could backport / upstream the fix that would be awesome.

The original version was written by Victor in PHP as well, but in two different functions, I just placed them into a single function call. Also nice work.

Last edited by Dygear, Fri, 12 Apr 2013 05:23.

Quote from Whiskey :

Too obvious to miss this opportunity

So you see my point .