MadCatX nailed the answer. Once you add D3DX9_43.dll and D3DCompiler_43.dll into the prefix everything works, without errors.

I'll write up a start to finish tutorial once I have the time.

The log file I produced for about 2 minutes of "game play" was 30kB from all of the errors. I condensed it down with this PHP script.

logFileParser.php (Works with PHP 5.5 and Up)
Terminal / Command Prompt

logFileCondensed.txt

Quote from Flame CZE :

Quote from Dygear :

Is there a way Scawen that I can have it save every text message in the top right corner of the screen saved too a log file? I'd like to give you some debug information, but I have no idea how to get this information too you in an efficient manner.

In data/script/autoexec.lfs you can put /log chatlog.txt and it will save all chat from the last LFS session.

Awesome, thank you!

Quote from MadCatX :

This looks like an issue caused by WINE's incomplete D3D9 support. Put D3DX9_43.dll and D3DCompiler_43.dll (you'll have to get them from DX9 redistributable package first) into your LFS directory and you should be OK.

That's interesting. Winebottler does have an option to add that into the prefix. I've give that a shot first, before I start downloading full on installers. Should that not work, I'll move onto the redistributable. Thanks for the tip, I'll get back to you on that.

So, the good news is that you _can_ ran LFS on a Mac with Wine Bottler, by going through the install process. The Part that is interesting too Scawen is that it seems that some resources are missing from the installer. I've tested this on a Late 2013 13 rMBP and a Early 2015 iMac 21.5" with Intel Iris Pro and I've had the same results with both computers. The result is a visible texture corruption on the cars in all cases, no matter the graphics settings employed. I can't quite pin this down too LFS as a programming fault, but there does seem to be another issue at hand.

It looks like LFS can't find AX_ADS1.jpg in any case. It tries multiple times during loading BL1. Is there a way Scawen that I can have it save every text message in the top right corner of the screen saved too a log file? I'd like to give you some debug information, but I have no idea how to get this information too you in an efficient manner.

Attached are two screen shots, both of them are in the same location with different graphics settings. During the swap between these two images I get more messages and warnings then I can count. (That's why I would need the debug log command.) I've take some screen shots of the errors and I've listed them below.


The list goes on.

Last edited by Dygear, Wed 8 Apr 2015, 08:54.

Perhaps we should move the GUI folder under the data directory, or config? It just hanging out there by it's self is freaking me out a little bit on the inside.

We also need a lang directory that should probably data directory, or config. Thoughts?

I don't disagree with you, regarding the best tool for the job.

I find that PHP is severely lacking in the WebSockets space and we can fill that void with something that doesn't suck.

I was thinking some thing along those lines, but I really don't have any idea where to start. To quote Steve Jobs, "Everything out there right now is shit." at least in PHP land. The require some odd choice to get Ratchet PHP to work and I really don't want that.

Anyway, I want to re-factor the PRISM code base so we can get too a point where it can be used with any protocol not just LFS connections from InSim, but also HTTP connections (already supported, thanks Vic), and Telnet connections (already supported, thanks Vic). I want to add WebSockets too that stack, and have all of these programs communicate through the PRISM.

Basically, the PSR-0 patch from T3 and Co would become the base for it, and we'd move all of the LFS / InSim stuff into the $PRISM/modules/lfs/ folder, and all of the HTTP, Telnet stuff into $PRISM/modules/HTTP & $PRISM/modules/Telnet. The last part would be the $PRISM/modules/WebSockets, that _might_ require the HTTP module to work, as it's an upgrade request.

From here plugins would be allowed to communicate on any protocol there was a module for. So you could have a plugin that would use the WebSocket connections and the LFS connection modules.

Note: Importing rules are per file basis, meaning included files will NOT inherit the parent file's importing rules.

I honestly, don't even know where to start with that one. Because, I should really allow for multiple WebSocket connections. But I guess, that would be handled like multiple InSim connections, where it's agnostic too the plugin, and is a configuration setting.

Quote from T3charmy :


if (Index >= AXO_CONCRETE_SLAB && Index <= AXO_CONCRETE_RAMP_WALL)
{
// Concrete objects - always floating regardless of 0x80 bit
// Flags byte contains various attributes depending on the object
// Each concrete object has three attributes

Attributes:

name bits values

Width : 0x03 >> 0 : 2, 4, 8, 16
Length : 0x0c >> 2 : 2, 4, 8, 16
Size X : 0x03 >> 0 : 0.25, 0.5, 0.75, 1
Size Y : 0x0c >> 2 : 0.25, 0.5, 0.75, 1
Height : 0xf0 >> 4 : 0.25 to 4 in steps of 0.25
Pitch : 0xf0 >> 4 : 0 to 90 in steps of 6 degrees
Colour : 0x03 >> 0 : grey / red / blue / yellow

Attributes used by each object:

AXO_CONCRETE_SLAB : Width / Length / Pitch
AXO_CONCRETE_RAMP : Width / Length / Height
AXO_CONCRETE_WALL : Colour / Length / Height
AXO_CONCRETE_PILLAR : Size X / Size Y / Height
AXO_CONCRETE_SLAB_WALL : Colour / Length / Pitch
AXO_CONCRETE_RAMP_WALL : Colour / Length / Height
}


That's gonna be a bitch. Put simply, there are 6 different ways to read that struct now based off the Index . Meaning the the UNPACK and PACK functions have to change slightly for it.

Where is AXO_CONCRETE_SLAB, ect defined? I'm not seeing them in my InSim.txt file for 0.6G18.

Base on the information I have, these helper functions should work for you. But I have no idea where these functions belong, because I don't know where the new defines are.

Quote from T3charmy :

Dygear, You'd probably know where should I put the NCI in the state handler? should I put it where NCI is or should I just make a new function. Could you possibly take care of that? haha.

I think I would stick it in with the onClientPacket. It adds too that information about the client, so for me that seems like the most apporiate area for it.

Don't forget to add NCI's definition too the ClientHandler class, as it falls in to that area as well.

Excellent job T3!

I'd like to add WebSocket support as a module too PRISM.

The idea being that PRISM would be a WebSocket server and it's connections would be handled by the plugins as if they where packets from InSim. You'd do this by registering an endpoint, you can then give that end point to any plugin that wants to take part in that communication or sub-protocol. From there, parsing the packet down, it can be given too the plugin already part procssed by a module or raw as the prism_packets module would get an InSim packet.

These are some rough ideas, and I want to know what you guys would think would make this a robust but easy solution to use. I'd also love to take a peek at Victor's implementation for LFSWorld so I have some idea what I'm talking about.

Please let us use our LFS accounts elsewhere on other forms, or to confirm our identity with the authoritative servers here at lfs.net.

(It would be massive for PRISM and everywhere else too!)

I'd like the open to merge multiple posts into one, so long as the posts are from the same author. You should be able to check muliple posts from the same person, and in the drop down for the dev tools, merge them, in much the same way that one could delete.

Quote from SsaintLTU :

Notice: Undefined index: in C:\xampp\cruise\modules\prism_hosts.php on line 589

Fatal error: Call to a member function isRelay() on null in C:\xampp\cruise\modules\prism_hosts.php on line 591

Post your hosts.ini file, or send it too me via PM. The part here Invalid socket type set for 127.0.0.1:29999 is your issue. PRISM should of gracefully shut down when it had no hosts to connect too because they were all invalid. The error is a bug, and one that we should handle, but the error started from an malformed hosts.ini file, or a miss-configured one.

The error starts here in PRISM's core and is not handled outside of that functions scope when there is no hosts too connect too.

Last edited by Dygear, Sun 29 Mar 2015, 08:57.

LMAO, there is an epicly small bug in 0.4.6.0. When you start the welcome plugin it fails to start the server because there is no ; at the end of line 33. Quick fix has been posted too github. No need for a dot release for something as simple as that.

Quote from T3charmy :

I'm gonna try an add instructions on how to do alternating text & more information on GUI clusters(wasn't in LFSLapper, but It's a nice features to have), I've thought about coding something in the ButtonManager to allow plugin devs to add ability to move GUIs without having to code their own methods that interface with the built-in betterButtonManagerFunctions(MoveGUIClusterV[ertically],MoveGUIClusterH[orizontally],MoveGUIClusterD[iagonally]). Once I have more time I'll probably add that functionality somehow.

You can do that with delta. You define the group as starting at 0, 0 and built the .ini file to match that, then from there, you can move the cluster around the screen by moving the starting point simply by adding to each buttons Top and Left values. I guess the .ini files should have a default top and left value that should be over ridden when the user needs, or can be set on a per client basis from within PRISM's instance. And if the PRISM server is running across multiple instances then those settings can be remembered on multiple servers.

Quote from T3charmy :

Edit: Dygear when you get a chance can you verify I changed the right stuff for the latest test patch? feel free to reverse the commit.

I think you nailed it from the diff that I could see. When I try to read the whole file as a diff on github the request fails. I think github is still getting DDoSed. But everything looks good right now too me.

Last edited by Dygear, Sun 29 Mar 2015, 08:09.

Quote from cargame.nl :

Like Troy already mentioned LFS for some reason now can get the GPU into power saving mode (especially on laptops I think?). If you want good performance you now need to go to Nvidea's configuration panel, add/select LFS.exe and force the GPU to run into running at optimum performance. If you are having a Nvidea chipset of course, no idea how it's working on Intel/ATI platforms.

Not having that issue myself and I'm rocking a 660 Ti.

Scawen, is there any chance that you can make the draw distance infinite? I'd like to be able to go too Shift+U mode and see every car on track. I've attached the screen shot below that blew my mind ... (I took the screen shot at UHD res, and it's insane.)

I'm hoping that Vic will pickup the WebSockets module for 0.5.0. *Hint, Hint, Nudge, Nudge*

I'll look over the changes tonight when I get home.

You're my hero. Nice job man!

Quote from Scawen :

Yes, Test Patch this month.

Not today though.

have you learned nothing from the past years!

Quote from aroX123 :

https://www.youtube.com/watch?v=W01TJ6Mhsgg
hmm..

Holy shit!

Vic, any chance of adding WebSocket support as a module to PRISM and making it available too the Plugins in the same way we offer the InSim Packets?

Quote from Victor :

Quote from three_jump :

Quote from Victor :

[...] and I'm aiming to introduce the first version very soon.

(I'm very sorry Vic, but I just couldn't resist )

I realised it when i wrote it, but as i've taken some time off of other work to work on this stuff, I dared saying it

I'll keep the pitch forks handy, UNLESS you want to take a stab at adding WebSockets support to PRISM. I understand that you have a solution that's awesome that you use here on this site.

You are never going to get help if you're going to be a dick.

Looking at the qualifying session for F1 this year, and it looks like the F1 overlays should be quite easy to recreate 1 for 1 in LFS using the InSim button system we already have. The F1 website has also done a pretty good job of making this information accessible in a HTML5 format, making it much more accessible then their previous Java effort.

Now that we are waiting for an incompatible patch, is there any chance we can get some InSim Changes implemented?

[RFC] InSim Language Information
[RFC] Insim - variable size IS_MSO
[RFC] Make IS_PLC Two Way
[RFC] IP Address Information In InSim