Girder 3.1.0 Beta 13

[Ron]

Pfew I made it, new stuff and changes include:

* fixes for all reported bugs
* Internet Event server ( replacement for the TCP/IP server )
* Internet Event Client / Console mode / php / action plugin
* Question OSD plugin ( replacement for the question action )
* probably more, can't think of it right now.

Please report only bugs about version 3.1.0beta13.


btw. The internet Event server is a pretty smart little thing, uses encryption and abuse protection et all. Sniffing the transfer will now no longer give you the password! And brute force attacking the server to get the password is also impossible. ( Increasing time between allowed logins )

<font size=-1>[ This Message was edited by: RonB on 2002-03-16 19:19 ]</font>

[Ron]

Ah, no that was a mistake with the SlinkE, I'll release the correct build later today.

About the question OSD check the help directory, it has an example.

[Ron]

Yes antirepeat moved around a little in the tree, sorry about that. This should have been the last change in the tree. The antirepeat settings should be in the eventstrings now.

[Ron]

Mitko, use the wait function.

The bug with the missing link :wink: has been fixed, it was not really a bug of the window exists but more a UI issue. For the next big release this will be overhauled, for now we'll have to live with it :sad:

[Ron]

Well pointing the goto at a eventstring isn't supposed to work. So that is good.

The antirepeat works only for Eventstring nodes. Sorry.

I'll add a function that loads a register with the time since the OS booted in milliseconds that way you can makes something yourself.

[Ron]

Carmero, well just too bad, live with it. I'm fixing the problem but this is the way it is gonna be. The old question OSD was a ugly hack and is not going back in. I'm in the process of cleaning things up, that means that there are going to be casualties.

About the other commands being blocked, you can do that too by disabling groups during the time that the OSD is on screen.

[Ron]

Mattwire, the inifite/stack overflow loop has been fixed. Girder now bails after 100 recursions. ( you'll hear a beep to indicate this )

[Ron]

Oh sorry that was unclear of me, Girder doesn't bail out of operation, the eventprocessing bails. So its not that bad, besides when do you ever get a command that went through 100 goto's ( or winexists ) or anthing apart from a mistake? So Girder continues living, only this event is dropped.

[Ron]

Hmm just found a flaw ( hehehe no, this isn't a bug :wink: ) in the pasting routines, also affects the import routines. For some reason the XDom parser is giving bugus data on empty tree nodes.... and girder is using this bogus data. hunting now....

[Ron]

:roll: Okay found it, I'm release a new version later today, this is a nasty 'flaw'

[Ron]

Ah but I didn't release the fix yet :smile: It will be there in an hour or so. Right after I updated the numbuilder plugin.

<font size=-1>[ This Message was edited by: RonB on 2002-03-17 18:17 ]</font>

[Ron]

Windtrader, don't know try it. :grin: Depends if you have a version where the anti repeat is set per command of per eventstring.

If you have a girder where the antirepeat sits in the eventstrings you are in luck otherwise, sorry.

[Ron]

Have you reentered them ? Or not yet, if not yet, I can help you.

[Carmero]

Similarly.
I made this already.
Dear Ron,
Concerning new OSD Question plugin. I didn't understand how it works. Can you give some help? Is it equivalent replacement for old question action? I didn't get an adequate behavior from it.

[Carmero]

Ron, I've tried your "Question example.GML". I'm afraid the Question OSD plugin cannot be equivalent replacement for old question action because of two moments:
1. It cannot block other commands assigned to the same keys durind "OK" or "Cancel" procedures.
2. When I assign the same keys for "Open OSD" and "Enter" actions, plugin freezes OSD window and makes strange "OSDQUESTIONCLASS" task on the taskbar.
I'm grieving for old question action. :sad:

[MMcM]

Actually, it's MFC42D.DLL, at least for me. This indicates that the SlinkE plugin is a debug build. Was that intentional?

I have this file, obviously, but not on the HTPC. I'll copy it over for further testing.

[mattwire]

Beta 13. There appears to be a bug with the 'Window Exists' function. If you have the first link setup, then select a target window, then click on a different command, then move back again, you find that link2 has been filled with itself (the command name).
This also means that stack overflows occur because it is calling itself - can you write a little bit of code to make sure commands cannot call themselves to prevent endless loops from occurring!

<font size=-1>[ This Message was edited by: mattwire on 2002-03-17 13:35 ]</font>

[mattwire]

Much better, perhaps you could get Girder to display a message as girder bails, such as 'Girder is closing since an infinite loop occurred with one of the commands!'

[mattwire]

That's what I thought you meant. Thing is in beta13a that is the behaviour I'm seeing:
Eg:
Create a command, set action to 'window exists', set links 1 & 2 to the same command to create loop.
Girder iterates through (100 times?), beeps and quits completely.

[mattwire]

Ah, I see! Sorry. I noticed 13a from 13 so I assumed this included the fix! :smile:

[Nikolai]

It appears that upgrading from 12b to 13 caused it to forget the antirepeat settings.

[mitko]

There is problem with the SlinkE.dll (I think). When I start Girder I get a message that MFC42.DLL was not found, then an error message with the SlinkE.dll full path and finally a message stating "Error code: 0".
I don't use this plugin so can I simply delete it?

[mitko]

Is it possible to make the antirepeat interval also available to the commands themself?
I'm asking this because I have commands without eventstrings and use them from a different places of in my .gir using GOTOs but want them not to function until a certain interval has passed.
I can fix part of the cases by setting the antirepeat intervall to all the eventstrings calling these GOTOs but not all.
In case you decide to forfill my request I think you should make this command antirepeat interval with priority over the eventstring's antirepeat. Or even better: compare them to see which is greater and use this interval.

If my request is too tough to forfill forget about it
:smile:

[mitko]

How am I supposed to use the wait function?
I want a certain command not to be processed for a prediod of time but others to work - this is exactly the antirepeat interval task. The only problem is that I can't set this interval to the command itself.

What should happen when I a point a Goto command to go to an eventstring? I tried using this method but it didn't work.

[mitko]

10x for the quick anwers
I'll try to find other solution

[windtrader]

Did you say that antirepeat time will be lost again if I go to the latest version?

[windtrader]

FYI - I was on beta 12b and went to 14 and lost my repeat wait times again. I had done this before and put the repeat time on the event string. They still got blown out.

[windtrader]

I started but I'm not one to turn down some help. :smile:

Don