desperate HELP needed for a chess gui

[hgm]

If you consider it 'unpleasant' when someone tries to help you, that seems to be your problem. (And a pretty big one, at that...)

Get this into your head, though:
1) I read what I want
2) I write what I want
3) I accuse you freely of whatever you are guilty of.

If you rather want to wait a few years than be reasonable, by all means wait as long as you want.... But rest assured that it is no coincidence that no one will help you here, with the attitude you are showing.

[Michele Tumbarello]

Anyone is reading the whole topic understands perfectly...
I have nothing to add...

[hgm]

Well, good that it gave you exactly the feedback you needed, then!

[lucasart]

Hy all.
I am a computer chess enthusiast and decent player from italy, my name michele.
Since some month i am collaborating with a spanish programmer to improve its software, LUCASCHESS.
LC is cute gui, with many features, some of them not available even in commercial ones (LC is completely free); and many other new features are already coming soon.
My "job" is to make some tests, discover bugs, propose improvements while he is the one to put these ideas in practice (into code, actually).
What i do is completely for free, just for love of chess; i believe i am not the only one to do this, among talkchessers.
I have had a cute idea but to carry it on i need that somebody of you, able to write and modify engines, help me!!!
My target is to create, using an engine, a lot of simulations of great champions of the present and the past and also many imaginary virtual players: the more configurable is the engine, the more precise result i can get (i studied over 15000 games, so i have a very precise idea about champions' styles).
I am officially kindly asking to some of the most famous chess programmers to help me, but any "other" help is very welcome: it is a bit rude to call a specific name, but i have recognized most of the big names...
From the very start of its appearance, LUCASCHESS has had as main target to be a superlight gui, both in terms of ram used and cpu load.
And here is what i need exactly: modern good engines when running at full power are already stronger than any existing human player, so actually i dont need simply a permission to include that x engine inside LC (and after all LC is designed mainly for beginners and club players, to improve).
A beginner, a club player, even a master doesnt need to play vs a software that is stronger than 2300-2400.
So this is my idea: might you add a nodes-per-second limitation (and the proper parameter to set via uci panel), in order to weaken an engine?
For example, if i set 10000 nodes per second, most engines will still play very well (about like a strong fide master), but at this speed any modern cpu will not even used at 2 or 3%.
If i set 500 nodes per second, most engines will likely play like a strong club player, and naturally the load over cpu is almost undetectable...
Vladmir medvedev, author of greko, and Pawel Koziol and Edmund Moshammer, authors of glass, already did it for me but i need the maximum variety.
This idea has two big advantages compared to other systems: not only it saves old hardwares from overheating, but also any imaginary playing personality will have the same strength in different hardwares (users) as...say 1000 nodes per second are always 1000!
I dont think this is difficult: just a system that limits the number of nodes that the engine calculates every second, then for the majority of the time actually the engine will do nothing but remain idle, waiting for the next cicle of calcs in order to respect to value set.
I dont think this is difficult, for you at least.
Not only: if you decide to help me and LC, we have a further request; personally we think that the idea to recall style parameters from ini files is not that comfortable for users and it would be much better if all parameters were available in the uci window (though this is a minor problem).
If you decide to help us, it's useless to say that you will named as a contributor both in the site and in some menù of LC.
You are invited to dowload last release of LC, and see what i am talking about.
I think i explained all stuff decently, but if anyway you wish more details, any of you are welcome to mail me.
Aloha.

A very long read, after which I'm not even sure I understand what your question is...
If it's the NPS limitation, then I think it's not a very smart idea, certainly not a new one anyway. Have a look at the source code of StockFish, and see how they implement playing levels, it's truely beautiful
Besides, the UCI protocol specifies a nodes limit if needed. So if you set a time per move and a "level" (corresponding to nps limit internally) you can deduce the number of nodes and send a "go nodes xxx" to the engines.

[Michele Tumbarello]

Basically, Lucas, what i really need is not the best system (at least in theory...) to dumb down an engine, but a system that reduces the cpu usage at zero or almost zero, as this is one of the "cardinal" points of this gui.
And also, Lucas, let me say that i have played all engines with a kind a dumbing system, and i must say that the one that really come close to the human play is hiarcs, that basically has an algorythm that translate the elo you set into a specific number of nodes per second (and also hiarcs has a huge chess knowledge, so it plays reasonable moves even at low depth).
That's why i think than nps limitation is the best system: like a human player that cannot see beyond a certain horizon; naturally the longer is the game, the more the player can see.
Also with this system, the engine will play the same identical moves in different hardware: another cardinal point of my idea.
In second order, i have also considered the idea of using (when somebody will release an engine with these features) an engine with a cpu usage limiter and and a randomness parameter: at a certain high depth the best moves are rather stable (and therefore not depending by hardware) and also the randomness is a levelling factor; this is not as good as nps limitation but quite a decent approximation.
Again there is no free or open source engine that combines randomness parameter and cpu usage setting.
An alternative to cpu usage might be time allocation: but again there is no engine that features these things.
Just few hours ago i surfed my engines' folder: there are more than 400...
I read carefully some sources; expecially of fruit and toga derivatives: ok i almost a layman, but it doesnt seem to me a difficult thing at all.
Maybe half an hour of work...
But now will arrive somebody like HG or a friend of his to tell me that their time is too precious and i must get it by myself, not remembering the title of the topic: i am begging HELP cause i cant do it by myself (after all i am a chemist, not an engineer or a programmer).
And i repeat: i will not offend or blame who will not help me, but at least i would like to receive the same treatment...

[hgm]

What makes you think I have any friends?

btw, reading back confirms that it was actually you that suggested people could not be bothered even to do what was logically their task because they already had 'too many things to do'...

And I see the target now has shifted again, to randomness. (While before it was presented as an advantage the engine would move always the same even on different hardware...) Nice going!

[Michele Tumbarello]

In a certain sense, HG, you are getting cooler and cooler to my eyes
Your humour is really subtle and it takes a clever mind to understand it: that's why most times i cannot.
Btw i'll try to explain the whole stuff, at the best of my knowledge and my verbal abilities, in order to make you understand that actually the randomness is a levelling factor for hardwares.
Or at least this is my empirical experience.
Let's imagine to run some glaurung or some fruit with uci randomness parameter, inside LUCASCHESS, using two different notebooks; one, mine, less powerful and yours more powerful.
Let' set the same identical position, then we force the engine to think say 60 sec§; at the end the engine will send its move to the gui.
In my notebook i'll reach say depth 14, in your one likely 15 or 16.
In most positions, the two programs will make the same move expecially if the 1st choice is much better than all others.
In some occasions (<10%), it might happen that my program makes one move and your another one (but surely they are very close in terms of evaluation).
BUT if the two engines might add a kind of randomness, for simple statistics reasons, the two engines will start making mistakes that in a long term will level their strength even in different hardwares.
That is because in almost all positions, there are two or three "reasonable moves", while from 4th or 5th the evaluation would drop too much and unless you set a very high randomness the engine will never consider a move worse say 75 centipawns from the best.
This means, basically, that the two engines will pick up moves laying in the same range from the best (at least the best for the stronger hardware/software).
Actually the two engines will sum, at the of the game, almost the same number of centipawns "lost" compared to the best moves.
This should lead, with good approximation, to a practical identical playing strength.
I still believe that a simple nps limitation is the best system, but this alternative is quite reasonable as well; though inferior.
Satisfied?

[Houdini]

Why don't you use the UCI parameters UCI_LimitStrength and UCI_Elo for setting the Strength of the engine?

For example Houdini 2 and Stockfish implement this in a hardware-independent way. If you set UCI_Elo to 1800 in Houdini 2 it will produce the same moves on an old laptop or on a fast quad-core.

[lucasart]

Basically, Lucas, what i really need is not the best system (at least in theory...) to dumb down an engine, but a system that reduces the cpu usage at zero or almost zero, as this is one of the "cardinal" points of this gui.

This is not the job of a GUI. The job of a GUI is to comply with the protocol (UCI and/or Xboard), and nothing more.

And also, Lucas, let me say that i have played all engines with a kind a dumbing system, and i must say that the one that really come close to the human play is hiarcs, that basically has an algorythm that translate the elo you set into a specific number of nodes per second (and also hiarcs has a huge chess knowledge, so it plays reasonable moves even at low depth).
That's why i think than nps limitation is the best system: like a human player that cannot see beyond a certain horizon; naturally the longer is the game, the more the player can see.

I have also played tons of games against computers, from ancient crappy bugware with levels based on fixed depth search, to state of the art programs like stockfish. And I think a fixed node or fixed depth strategy are very poor, although fixed nodes is better than fixed depth.
The state of the art method involves running multi-pv in the background, and selecting with a varying randomness amongst the best moves (with blunder limits). And this can only be done in the engine, not by the GUI. I strongly recommend you educate yourself by reading about it, before pursuing this pointless thread...

[Michele Tumbarello]

Tell me, Lucas, where i have written about modifications for the gui.
I have always talked about engines.
It wasnt me to propose that approach.
It is very true that i need to read a lot, while somebody else should read less but more carefully.
By the way, i listen to all and i try to learn and understand (i have pointed out that i am a true beginner in computer chess many times, and i dont need that you underline it with such emphasis).
Frankly speaking i didnt expect such kind of replies.
If i had known that i will never start such a topic, actually i'll never post anything here.
By the way i get out of the way, and i apologize if i disturbed this golden heaven that is talkchess.
Replies are useless cause i'll not answer anymore, this is my last post.