On Tue, Jul 24, 2012 at 11:22 AM, Jeff Hardy wrote:
> On Tue, Jul 24, 2012 at 5:54 AM, Jesper Taxbøl wrote:
>> Agreed that could work :), but would still hang if a kid writes an infinite
>> loop without actions inside.
>>
>> I am really into making something robust for kids to play with.
>>
>
> s
On Tue, Jul 24, 2012 at 5:48 AM, Markus Schaber
wrote:
> Another idea is that you could use the “yield return” with yield parameters
> – the script yields the actions, and gets the next snapshot in return. Here,
> you still can synchronize internally.
IIRC, this is how UnrealScript works. It's a
That seems to be a good idea. I actually researched it a bit last night. It
still has some issues, but seems to be easier than finding an abstract
machine.
As I see it. Threads will still affect eachother depending on how much cpu
they consume and it will be non deterministic. But besides that it
Hi, Jesper,
Let me suggest some different design: Do not use variables, but offer an
"Action" function / delegate which is provided by the hosting code, and called
by the player scripts. It gets the possible actions (left_wheel_speed,
right_wheel_speed and fire) as Parameters. Inside this Actio
Hi, Tax,
If you run each of those scripts in its own thread, possibly encapsulated into
its own app domain, then only the player script "hangs", and not the whole
application.
You could also use rather strong methods like "Thread.Abort()" or
"AppDomain.Unload()" to clean up player scripts whic
Agreed that could work :), but would still hang if a kid writes an infinite
loop without actions inside.
I am really into making something robust for kids to play with.
Tax
2012/7/24 Markus Schaber
> Hi, Jesper,
>
> ** **
>
> Let me suggest some different design: Do not use variables, bu
