Girder 3.1 Beta 11

[Ron]

This release fixes all reported bugs. Please report succes failure.

[Ron]

Yeah the fileformat changed. Sorry about that. Please test if it loads okay before you modify them all :smile:

I see what the problem is, the older betas wrote Enabled=false for the eventstring, the new Girder reads this now. So change it once and that should do it. ( maybe you can use some tool for this )

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

[Ron]

Could you check the number in the status bar, of the multigroup eventstring? This is the Identifier of the eventstring, if this is 0 there is a chance of an access violation. This has been corrected in my copy but not yet released. If you have no idea what I'm talking about send me the .gml file and mark the eventstring cleary so I can find it.


Every node in the tree must have a unique non zero identifier, if this is not the case things will go wrong, older copies of the betas didn't do this properly and I just saw that after copying/pasting the Eventstrings don't get new identifiers so you get duplicate IDs. :sad:


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

[Ron]

Beta 12

* fixes identifier mishaps
* add check tree. This checks for and corrects 'zero-identifiers' and checks and corrects duplicate identifiers.

Carmero please run the "check tree" in the edit menu on your tree, i have a feeling this is our problem.

[Ron]

Don,

Antirepeat saving fixed in beta12b.

Default antirepeat is not such a good idea. You might need this but someone else out there ( me for example ) doesn't want an antirepeat. I might consider this as a configuration option though.

[Ron]

You are mixing up anti repeat time and state settings.

Only event strings can have an antirepeat time.
-Antirepeat prevents an action from executing several times in a preset time, for example if your remote repeats really fast and you cannot let go of the remote fast enough to prevent it from triggering the command multiple times. You would set the antirepeat time to a realistic time that you can press and release the button.


Only commands and Multigroups can have state settings.
Explanation of states :
http://www.girder.nl/help/girderhelp/states.php


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

[Ron]

SouthyPar, what version are you using ? I tested this in beta12b and it worked just fine.
( People please also mention girder version when reporting bugs )

Goldserve, Global Antirepeat I really don't like this idea. I'll modify the convertor to correctly set the antirepeat.

Don, Looking into this.

[Ron]

Don I think I found the problem. When Girder loads the .gml file it doesn't set the currentstate correctly. Meaning that both groups are in the same currentstate. I'll correct the loading behavour.

[Ron]

Beta 12c and the convertor should fix all reported problems. Post bugs about beta12c in separate thread.

[Carmero]

When I make "Group Enable (Disable)" action for Multigroup EventString, Girder fails with "Accees Violation" message :sad:.
For ordinary command event strings all is OK.

<font size=-1>[ This Message was edited by: Carmero on 2002-03-14 21:22 ]</font>

[mattwire]

I just noticed all my eventstrings have become disabled. Is this because you've changed the fileformat slightly?
If so, fine. Otherwise, maybe it's a bug?

[GoldServe]

Just a suggestion...we should have a global antirepeat field that applies to all events unless there is a specific number that overrides the global value. Why? cuase i converted my gir file to gml and i have to put an antirepeat in all my event strings now!

[SouthyPar]

Hmmm, more event string trouble. If you accidentally link a certain command (such as Group DisableEnable, or WindowExists) to an EventString, Girder will start seriously fucking up. It will not let you fix your mistake -even after clearing the links on that command-, and you will have to delete the command and make it again to get around the bug.

[windtrader]

Repeat wait time does not stick and stays at 0. How about a default of 250?

Thanks,
Don

[windtrader]

Ron,

This how I use antirepeat. Anytime I use a multigroup with repeat wait time at 0, all the commands get executed. When I use repeat wait time, the commands execute one at a time. Even when I use a single command as a toggle, it does not seem to execute just once. With repeat time set at 250 I get a single "press".

Maybe I am using this paramter incorrectly to fix a different problem like not having the state settings properly set up in the first place.


<font size=-1>[ This Message was edited by: windtrader on 2002-03-14 23:45 ]</font>

[windtrader]

Ron,

Your explaination of antirepeat time is what I thought. I must have a really fast remote or really slow fingers because it sends commands so fast that it is really hard to get it to send just one command on a press. It made me wonder since you mentioned that you do not use antirepeat most of the time.

Since each command has its own state counter then having multiple commands in a multigroup allows each command to be controlled by its own state counter, right?

For example, if I have two commands in a multigroup, one with state (1,1) and the other with state (1,2), then the first will execute everytime and the second will execute every other time.

Thanks,
Don

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