Last edited by Dygear, Wed 29 Jun 2011, 14:47.

@Victor, Yeah, he does that ...

@misiek08, Strong arming someone who has what you need is never a good idea. Get a better attitude and try again, I can't see anyone helping you on any subject anymore if you keep acting like this.

Rule #1 of getting help online: Don't be a dick.

Last edited by Dygear, Fri 24 Jun 2011, 11:51.

Quote from morpha :

Or maybe he's referring to the over 360 markup errors, quite pathetic with the already loose transitional standard

96 Errors, 3 warning(s), wow.

Don't forget that you can put very high pressures in your tires and that will cause less rolling resistance allowing you to get a better top speed.

Well, how to hell are we meant to know if a another InSim Client is using that ClickID? This is a terrible idea and a massive oversight!

There are a few things that we can do, but none of them are great.

• We could like GeForz said, limit the ClickID number available to the client by a configuration file option.
  
• Ask Scawen to give us a packet once a InSim Instance uses a ClickID, and allow us to reserve a set of ClickIDs when we want to present a interface object to the client.
  
• We could ask the Scawen fix this, so that each InSim client get's in own button space.
  
  
• We ourselves make a Meta InSim client, that acts as an intermediary to the other InSim instances. So "MetaSim" will connect to LFS's InSim. From there, all of the conventional InSim client's connect to MetaSim, and it acts as a pass-trough. But we ourselfs add some packets to the InSim interface so we know when another InSim instance uses a ClickID as the information will be reported back to each InSim Instance that is connected to MetaSim. Basically, it's MetaMod for LFS.
  

Last edited by Dygear, Thu 23 Jun 2011, 03:13.

Yeah, but the fact that the log system does not work is slightly embarrassing considering the amount of time the code and configuration opens have been there. But your right, I should work on LVS as well.

I don't know if anyone else has tested what GeForz has made with the pylons plugin, but that was cool. I just did like a lap with it, and it's basically the arrow marks the follow you around the track, but even cooler then that, it also shows your angle of attack into the corner, so the front of the arrow might be pointing into the corner even if your going straight. It's very cool. Great for visualizer what your doing on the track with the car.

Ok, I have a 0.4.1 build that is a simple merge of what GeForz has done. Is there anything that anyone would like to see in 0.4.1 outside of the scope of buttons?

Last edited by Dygear, Fri 1 Jul 2011, 10:07.

I was reading today's coding horror article about Performance is a Feature, of any web site. At point three he talks about making performance a point of (public) pride, and using the MVC Mini Profiler to profile his .NET stack. I am so freaking jelous of .NET web programmers right now. Mind you not enough to switch to .NET just yet, but still ... Pretty awesome stuff.

With GeForz working on the Button Manager, and Morpha working on the LFS String class, I'll work on the not so sexy stuff. I'm going to work on the loging functions of PRISM so that the console function logs to a file, like it should. This should help with some debugging later down the road. .

Anyone have any information on the Mitsubishi 23 Inch 120Hz Display?

Quote from PoVo :

Also, would I need the NLP packets to for the Streets, or would MCI suit?

MCI, you need to know the cars X & Y position on the track. Node positions won't help you on the open configs.

Should not make a difference, unless there is a bug within LFS.

So, then iconv if available, then PRISM's native PHP implementation otherwise.

Quote from morpha :

I've encountered a few back in DriftWars's prime, ISOs instead of MSCPs messed up a few of the exotic names, but nothing major. I genuinely meant the "reasonably accurate", that wasn't sarcastic


CP932 and CP936 are now 100% complete and produce identical results to mb_convert_encoding() and iconv(). Unfortunately, being pure PHP, it's quite slow, about 50 times slower than iconv()/mb actually. As such, I don't think it's worth finishing, except maybe as a fall-back solution for systems where neither mbstring nor iconv are available. I've attached it though, if anyone wants to have a look.

That's fantastic then. When loading up PRISM, I'll check to see if the mulibyte module is loaded in PHP, and if it's not use this. Thanks!

You could use path from the other tracks based off the map to make the track names. It would provide a pretty high level of accuracy as well.

That looks good to me.

Quote from morpha :

If all goes according to plan, I'll also be able to provide conversion mappings for PRISM, though obviously not to and from Unicode but rather UTF-8 directly, since PHP doesn't have native Unicode support (yet).

That's great! I'm happy if you're willing to do the work. I wonder why Victor has not chimed in yet, seeing as he deals with this on the LFSWorld site, with hostnames, and usernames.

Quote from boothy :

At least it's not like iRacing, where despite apparently using UTF-8 internally, they can't seem to get UTF-8 characters to display on their website, nor on the sim due to the fact "The sim uses pre-rendered fonts, and we include only the first 255 characters." :doh:

This might give me nightmares.

Quote from boothy :

It seems to have a HTML4 doctype as well :rolleyes:

Yeah, I noticed that too.

Quote from GeForz :

Actually... it's not even html 5 as there is no canvas element involved
It's some wtf-html generation that creates a triangle by creating a div for each pixel-line with differing width's...

Huh, I really should fix that.

That's not flash, that's pure JavaScript and HTML ... Also known as HTML5.

Quote from DarkKostas :

I was testing insim locally so yes, both insim and server were on the same computer(mine) and connecting locally(127.0.0.1).

I never noticed this problem, but I'll see if I can reproduce it.

Might be more of a latency thing then any thing else. Is the InSim client on the same computer as the LFS host? Are they connected via the lookback IP? If both cases are true, then I would say that you might be right, otherwise it's almost sure to be a latency issue.

We should really have a paging mechanism, where buttions that go past the 240 are displayed once a the require number of ClickIDs are available for that element. This becomes important when the client is given a interface where multiple elements are presented to them in a single context. These single context relationships will have to be known to PRISM so that it may intelligently display these buttions to the client when the ClickIDs do become available to it. But it has a caveat, where even tho the elements are within the same context, it might not be assigned sequential ClickID's as the ClickID's could open at random.

The whole counter is off by one or two seconds because of the delay? Does this save to the reply state?

I want access to every engine event. I want what AMX Mod had in 2002, I want what AMX Mod X had in 2004, I want what Source Mod had in 2006 and that is access to the engine. I will learn C++ just to take proper advantage of it too!