Fusilli Client (Alternative C4A Client)


I use something like this (inside pnd, the fusilli client is in fusilli subdirectory):

which fusilli
RESULT=$?
if [ $RESULT -ne 0 ]
then
export PATH=`pwd`/fusilli:$PATH
fi
...
fusilli some args here
This way I don't care where fusilli client is located in the firmware (as long as it's in PATH).And I only do the check once and subsequent uses are the same whether in the script or in my executable.
 
New version of fusilli-client, which fixes a bug, which occurs if the cache is too full to be emptied in the given timeout. In that case only the first score per game in the score was kept and rewritten to the cache.
 
New version of fusilli-client, which fixes a bug, which occurs if the cache is too full to be emptied in the given timeout. In that case only the first score per game in the score was kept and rewritten to the cache.
For all these bug fixes, does that mean everyone has to update their fusilli client in their PNDs or expect users to all use the latest firmware ? We should have a clear policy as to what to use, firmware or PND-side client as this client keeps getting updates.
 
New version of fusilli-client, which fixes a bug, which occurs if the cache is too full to be emptied in the given timeout. In that case only the first score per game in the score was kept and rewritten to the cache.
For all these bug fixes, does that mean everyone has to update their fusilli client in their PNDs or expect users to all use the latest firmware ? We should have a clear policy as to what to use, firmware or PND-side client as this client keeps getting updates.
For now (for my PND at least), I still use PND version of fusilli. Because Firmware is still "RC" I didn't enforce use of firmware version. I intend to do that (putting a message at 1st start of the PND mentioning no updated firmware, no C4A), but I waited the end of RC cycle for the firmware, and may be give a grace period of a few month, when still embending fusilli in the PND (and still warn user maybe), to avoid complains (and bad rating because of broken function  ;) )
 
New version of fusilli-client, which fixes a bug, which occurs if the cache is too full to be emptied in the given timeout. In that case only the first score per game in the score was kept and rewritten to the cache.
 For all these bug fixes, does that mean everyone has to update their fusilli client in their PNDs or expect users to all use the latest firmware ? We should have a clear policy as to what to use, firmware or PND-side client as this client keeps getting updates.
Imho it would be best to check the version of the fusilli-client, e.g. with
./fusilli | head -n 1 | awk '{print $4}'which returns "1.3.0.1".So the best would be if someone would make a script, which

a) tests whether the internal fusilli-client is available.

B) if it is available, it tests, which version is more recent.

Greetings,

Ziz
 
Mmmm, yeah and check if it meet at list 1.3 version (for example). That can be interesting.
I think it should just use the most recent one. Someday hopefully the one in the firmware. :)
 
Typo, I meant "at least"...

Minimal version can be important... I use functions not available in earlier version, so I should ensure the version is at least what I expect, and than I take the newest.
 
Last edited by a moderator:
Typo, I meant "at least"...

Minimal version can be important... I use functions not available in earlier version, so I should ensure the version is at least what I expect, and than I take the newest.
But one version you ship yourself. Why would you ship an too old version for your purpose? ;) So at least one version is recent enough. And the most recent version is chosen anyway. :)
 
Mmmm, yeah and check if it meet at list 1.3 version (for example). That can be interesting.
I think it should just use the most recent one. Someday hopefully the one in the firmware. :)
But please make sure the version that will be included in the firmware is bug-free as much as possible because we don't get firmware updates every 2 days :)
 
Mmmm, yeah and check if it meet at list 1.3 version (for example). That can be interesting.
I think it should just use the most recent one. Someday hopefully the one in the firmware. :)
 But please make sure the version that will be included in the firmware is bug-free as much as possible because we don't get firmware updates every 2 days :)
You know, I make these bugs on purpose. But I will stop for you now. ;)
 
Mmmm, yeah and check if it meet at list 1.3 version (for example). That can be interesting.
I think it should just use the most recent one. Someday hopefully the one in the firmware. :)
 But please make sure the version that will be included in the firmware is bug-free as much as possible because we don't get firmware updates every 2 days :)
You know, I make these bugs on purpose. But I will stop for you now. ;)
And besides, yes we do get firmware updates every 2 days if needed, that's the nice thing about those things called package/update managers.
 
Well, I'm paid for that, but I find release management to be nontrivial and often unrewarding work (I prefer creating the bugs myself:)

And - if I'm not mistaken - in the case of the Pandora there is no incentive besides honor at all.
 
Well, I'm paid for that, but I find release management to be nontrivial and often unrewarding work (I prefer creating the bugs myself:) And - if I'm not mistaken - in the case of the Pandora there is no incentive besides honor at all.
It is hard to find such bugs without testing it on many pandoras with different use cases. Asmo is perfect for high-load testing. It may be a good idea to give him new versions 2 weeks ahead to find bugs. ;) However as you mentioned: I don't get paid. Asmo don't get paid and we can't force him to test a game... As much as you can't except, that my code - made in my spare time - is bugfree or well tested.

Debian has whole repositories with a large user base for such things. First an application is in unstable. If no critical bugs occur for 2 weeks, it goes to testing. And after a long time it goes to stable.

We don't have such a big user base. So we have unstable, testing and stable in one repository. ^^'

However: Even if this bug is not fixed soon in the firmware, Version 1.3.0.0 is preinstalled atm and the bug did only occur, because Gandhi did still use Version 1.2.x.x without support for "only the best"-caching. If he would use 1.3.0.0 (the second recent) it would be very unlikely for the bug to show up again anyway.

(I am glad he didn't update yet, otherwise I would never have found this bug)

Greetings,

Ziz
 
The version in firmware updated. As usual, would be great if someone confirmed it's ok.

Typo, I meant "at least"...

Minimal version can be important... I use functions not available in earlier version, so I should ensure the version is at least what I expect, and than I take the newest.
I think it's reasonable to assume that if you find something in firmware, it's at least 1.3 or later.
 
Hey @Ziz, does fusilli support float score? I have a game that has a score in seconds, and I want to submit 10.51 for example, but I'm not sure the ".51" is indeed submitted (and I'm too lazy to check the code).
 
Last edited by a moderator:
Hey @Ziz, does fusilli support float score? I have a game that has a score in seconds, and I want to submit 10.51 for example, but I'm not sure the ".51" is indeed submitted (and I'm too lazy to check the code).
No. Does the spaghetti client support it?
 
I guess so, but didn't tried. There are some games with decimal score in C4A.
No. E.g. Boson X seems to have float score, but in fact the scores are saved as integer numbers as seen with Sparrow C4A Manager: Bildschirmfoto - 17.05.2015 - 12:21:51.png.

So you have to submit integers, but to tell Milkshake to which number to divide.
 
I know Boson-X is sending integer, I was wondering how hexxagon was sending it's time info.

But, like for Boson-X, I will send integer and ask skeezix/milkshake to change display.
 
Back
Top