OK. Can you explain why you closed my latest bug report with 'an easy bug fix' but no change appears on GIT after that?

Did you forget something or is this the way it works?

I've already fixed the bug in my release, I've just not committed it yet.

OK, just wanted to make sure I understand how it works

LFS Likes Linux,
Wine Works Well,
PRISM Programming Proceeding.

(There is something wrong with me, LAMO)

Wrong?

You are talking perfectly sense to me

FYI: I started to work with PRISM and getting to understand how this InSim stuff works. I'm pretty pleased with it, good job

Managed to work around the bugs too so no worries



roflol

The onPitGarage command is not implemented yet and sure I'll remove MCI for the default packet list.

If any one wish to check out the most current version of prism it includes some bug fixes that I wish to make sure are stable before I release them as 0.3.4. I have one more bug that I need to squish before I can release 0.3.4. You can compare what I have now too the 0.3.3 here.

Nice, did a copy/paste

Few remarks;
That database thing never was in an official release as far as I can see so didn't have to remove that

Problems considering theTime where of a different nature. The plugin is working but the command structure is just not the same because !prism is missing at the start (I didn't noticed that earlier ). Maybe you want the same analogy on this, opened a bug ticket for free.

I opened an extra bug ticket as bonus. I get a parse error on prism_file.php. Something which isn't in use yet I think but it's still a parse error.

Quote from Dygear :

The onPitGarage command is not implemented yet

And don't forget this one because it crashes PRISM

// also made bug ticket as reminder

And I want to report another major issue.

Well for me..

The timer interval... An interval of 1.0 is supposed to be a second?

Because it isn't

Its more like.. Hmm 0.8 = 1 second or something

//edit
A few hours later its wwwaayy to fast. Wtf.

The timer issue is interesting, something that I will have to profile myself to find out what is causing it to go to fast or to slow. As for the files that are not used by the PRISM core, I won't fix them until PRISM needs them. They are just placeholders right now until I'm ready to implement them. TheTime command structure is such because I was just making a plugin. It was not really meant to be a PRISM core function, just an addon that I made or anyone else could of made. I think back in the day (yeah, I think I can use that term now) I made that plugin only as a proof of concept that's kinda stuck it out between all of the builds.

Are you still getting onPitGarage crashes? I was sure I fixed that, I did both a real pitstop, and then I did a spectate from race and they both worked. How are you getting the crash so I can reproduce it on my end and trace it back.

Nono I didnt see it in the https://github.com/Dygear/PRISM/compare/master...current

So I thought you maybe forgot about it

Quote from cargame.nl :

Nono I didnt see it in the https://github.com/Dygear/PRISM/compare/master...current

So I thought you maybe forgot about it

Check it for me please, I'm pretty sure I fixed this problem as it does not crash in my build.

Well.. I'd would love too..

But...

https://github.com/Dygear/PRISM/tree/current/modules
prism_statehandler.php October 03, 2010

Where can I find the changes?

Ok I think it's time to start refactoring some code. This project has become quite large and it's hard to keep track of changes.

How would i turn on the MCI packet on again? the MCI packet is nolonger sent, so now my Cruise plugin is useless :/

https://github.com/Dygear/PRIS ... e/master...current#diff-5


Still a code change compared to 0.3.3 but this sets MCI default to on instead of off.

If I'm correct.

In the hosts.ini file you can define hosts Flags. Dygear said in 0.3.4 Flags= setting will work.

Quote from T3charmy :

How would i turn on the MCI packet on again? the MCI packet is nolonger sent, so now my Cruise plugin is useless :/

Within the config file, turn the flags on to include the MCI packets. I'm going to have to start making documentation on how to do this, as this part is locked down and is not going to be changed from this to 1.0.0.

Quote from cargame.nl :

If I'm correct.

You are. Although, like I said, the best route is through the config file for that host.

nvm found it :P

T3, is the www stuff ready to be merged?

Quote from Dygear :

T3, is the www stuff ready to be merged?

Ye, I will send you a zip because i have yet to find out how to upload files to git

I want to talk a little bit more about the timer issue.

This is on my machine. Interval set to 0.72!

Quote :

Race points - ^7Johnnie^7 : ^31 ^7(94)
welcome::tmrCallbackFIN12 time: 02.353640
welcome::tmrCallbackFIN13 time: 03.353636
welcome::tmrCallbackFIN14 time: 04.354547
welcome::tmrCallbackFIN15 time: 05.354602
welcome::tmrCallbackFIN16 time: 06.354624
welcome::tmrCallbackFIN17 time: 07.354742
welcome::tmrCallbackFIN18 time: 08.354573
welcome::tmrCallbackFIN19 time: 09.354573
welcome::tmrCallbackFIN20 time: 10.354551
welcome::tmrCallbackFIN21 time: 11.355498
IS_MSO Packet from gtr.
^3no GT2^7 when its too busy. Always want GTx? goto our GTR server!
welcome::tmrCallbackFIN22 time: 12.750500
welcome::tmrCallbackFIN23 time: 13.751482
welcome::tmrCallbackFIN24 time: 14.752367
IS_SPX Packet from gtr.
welcome::tmrCallbackFIN25 time: 15.610873
welcome::tmrCallbackFIN26 time: 16.611291
welcome::tmrCallbackFIN27 time: 17.611248
welcome::tmrCallbackFIN28 time: 18.611298
welcome::tmrCallbackFIN29 time: 19.611340
welcome::tmrCallbackFIN30 time: 20.612301
TINY_NONE Packet from gtr.
welcome::tmrCallbackFIN31 time: 22.184211
welcome::tmrCallbackFIN32 time: 23.184263
welcome::tmrCallbackFIN33 time: 24.184150
welcome::tmrCallbackFIN34 time: 25.184233
welcome::tmrCallbackFIN35 time: 26.185206
welcome::tmrCallbackFIN36 time: 27.186207
welcome::tmrCallbackFIN37 time: 28.187055
welcome::tmrCallbackFIN38 time: 29.187076
IS_SPX Packet from gtr.
welcome::tmrCallbackFIN39 time: 30.023916
IS_SPX Packet from gtr.
welcome::tmrCallbackFIN40 time: 31.505106
welcome::tmrCallbackFIN41 time: 32.506067
welcome::tmrCallbackFIN42 time: 33.506963
welcome::tmrCallbackFIN43 time: 34.507884
welcome::tmrCallbackFIN44 time: 35.507860
welcome::tmrCallbackFIN45 time: 36.507842
welcome::tmrCallbackFIN46 time: 37.507816
welcome::tmrCallbackFIN47 time: 38.507754
welcome::tmrCallbackFIN48 time: 39.507843
welcome::tmrCallbackFIN49 time: 40.507831
welcome::tmrCallbackFIN50 time: 41.508764
welcome::tmrCallbackFIN51 time: 42.509742
welcome::tmrCallbackFIN52 time: 43.509758
welcome::tmrCallbackFIN53 time: 44.510696
welcome::tmrCallbackFIN54 time: 45.510708
welcome::tmrCallbackFIN55 time: 46.511564
IS_PLA Packet from gtr.
welcome::tmrCallbackFIN56 time: 48.227597
welcome::tmrCallbackFIN57 time: 49.227663
welcome::tmrCallbackFIN58 time: 50.227624
TINY_NONE Packet from gtr.
welcome::tmrCallbackFIN59 time: 51.189835
welcome::tmrCallbackFIN60 time: 52.190570
welcome::tmrCallbackFIN61 time: 53.191569
welcome::tmrCallbackFIN62 time: 54.192493
welcome::tmrCallbackFIN63 time: 55.192367
welcome::tmrCallbackFIN64 time: 56.192363
welcome::tmrCallbackFIN65 time: 57.193445
welcome::tmrCallbackFIN66 time: 58.193363
welcome::tmrCallbackFIN67 time: 59.193285
welcome::tmrCallbackFIN68 time: 00.194236

Time is in seconds.microseconds

The time drifts, but it drifts even more when it has to take care of an InSim packet.

Quote from cargame.nl :

The time drifts, but it drifts even more when it has to take care of an InSim packet.

To be quite honest I don't know if I can fix that. PHP just might be too slow. It just might not be possible with PHP. But I'll keep on trying.

Will you be adding the new packets? (Collision ones coming in new test patch?)