Welcome to the debute of TWX Proxy Pro v2.10.

This release has gone through testing by the eight(8) testers of TWX Proxy Group. To put it in their own words. They have found that it is a stable build with no none problems.

There are a few fixes, and many changes and additions to this release. You can read about all the release, and also download the release from the TWX Proxy Group's website.

http://twxproxy.sourceforge.net





You can find out who the testers are, by visiting the TWX Proxy Group's website and clicking on the About Us button.



edit: fixed link

edit: above link works now.

quote:The STARDOCK System value is now updated by visiting the sector it is in, as well as from the V screen if it is shown.

NOTE: There is one draw back to this. If any script is running when the StarDock location is updated by the V Screen. Then that updated information is not available to any script(s) that are currently running.

Unless I am able to come up with a work-around that does not require the complete re-write of the Database code. You must update the Stardock location by the V screen. Before any script, that uses the STARDOCK value, is loaded for use. This includes scripts that include sub-scripts that use the STARDOCK value.

Ok,
Does this mean that the STARDOCK variable is getting blown away when you visit the sector, and you have to press V to get it restored?

quote:
I believed that the displaying of local, i.ee the same computer, client connections and disconnects are not necessary. So the default selected state of the 'Broadcast a message when a client connects' in the setup menu has changed to the following:

You are unable to change the setting of this option, unless you have selected Accept external connections.

When not accepting external connections, the default is to not display messages when a local client is connecting.

You may think it's not necessary, but there were reasons it was there. I routinely have multiple things connected (zoc and swath) to my twx session, sometimes even a 2nd copy of twx connected to the first.

quote:
Added ALPHACENTAURI System Value. If you have visited the sector that Alpha Centauri Class 0 port is in. Then this System value will return the sector number that AC is located in, otherwise it will return 0.

Added RYLOS System Value. If you have visited the sector that Rylos Class 0 port is in. Then this System value will return the sector number that Rylos is located in, otherwise it will return 0.

good.

quote:Originally posted by Traitor
quote:The STARDOCK System value is now updated by visiting the sector it is in, as well as from the V screen if it is shown.

NOTE: There is one draw back to this. If any script is running when the StarDock location is updated by the V Screen. Then that updated information is not available to any script(s) that are currently running.

Unless I am able to come up with a work-around that does not require the complete re-write of the Database code. You must update the Stardock location by the V screen. Before any script, that uses the STARDOCK value, is loaded for use. This includes scripts that include sub-scripts that use the STARDOCK value.

Ok,
Does this mean that the STARDOCK variable is getting blown away when you visit the sector, and you have to press V to get it restored?


No, this will not blow away the SD location when you visit the sector it is in.

The draw back I have mentioned is caused by the original database code. I am calling the same code to update the SD location for the SD system variable. As was already being used when visiting the sector it is in.

The only code added for the V screen update, is code needed to extract the SD sector from the V Screen. And then to call a new method in the database module. Which in turn calls the original code used to save the SD sector number in the db, for the use by the SD variable, when visiting the sector that it is in.

I have been testing this for over 5 weeks. And the only ways I have been able to use the SD variable, after a V screen update, while a script was running. Was to do any one of the following:

1) Perform a manual V screen listing, then run any script.
2) Have the script perform the V screen listing. Then have it load another script that uses the SD variable.
3) Have the script perform the V screen listing, then perform a redisplay of the current sector. Before continuing with the rest of the script. (yes, I know I need to update the information to include this.)

If you do not do any of the above, it does not matter how many times you query the SD variable. Or how long you wait between each query. It will always return a value of 0.

quote:Originally posted by Traitor
quote:
I believed that the displaying of local, i.ee the same computer, client connections and disconnects are not necessary. So the default selected state of the 'Broadcast a message when a client connects' in the setup menu has changed to the following:

You are unable to change the setting of this option, unless you have selected Accept external connections.

When not accepting external connections, the default is to not display messages when a local client is connecting.

You may think it's not necessary, but there were reasons it was there. I routinely have multiple things connected (zoc and swath) to my twx session, sometimes even a 2nd copy of twx connected to the first.


I also routinely use multiple client connections from Zoc, SWATH and TWX from the same machine. And in every case I know that I have made the connection to the one TWX from those clients. And for the most part, I also remember which client(s) are still connected to that same TWX.

Since you are loading the client(s), and making it/them connect to the twx running on the same machine. There is no need to display the connections/disconnects from clients running on that machine. But, it does still display the number of clients connected to it.

The only reason for the displaying of client connections/disconnects. Is if it is for a client that is not on the same system as the twx it is connecting to, or disconnecting from.

I have just updated the TWX Pro feature page and the changes.txt file in all distribution files. To reflect the information provided above for the STARDOCK system value.

I have also added a test script, testmenu.ts, to show the use of dynamic menus, and labels in menus.

quote:Originally posted by The WABBIT

quote:Originally posted by Traitor
quote:The STARDOCK System value is now updated by visiting the sector it is in, as well as from the V screen if it is shown.

NOTE: There is one draw back to this. If any script is running when the StarDock location is updated by the V Screen. Then that updated information is not available to any script(s) that are currently running.

Unless I am able to come up with a work-around that does not require the complete re-write of the Database code. You must update the Stardock location by the V screen. Before any script, that uses the STARDOCK value, is loaded for use. This includes scripts that include sub-scripts that use the STARDOCK value.

Ok,
Does this mean that the STARDOCK variable is getting blown away when you visit the sector, and you have to press V to get it restored?


No, this will not blow away the SD location when you visit the sector it is in.

I have been testing this for over 5 weeks. And the only ways I have been able to use the SD variable, after a V screen update, while a script was running. Was to do any one of the following:

1) Perform a manual V screen listing, then run any script.
2) Have the script perform the V screen listing. Then have it load another script that uses the SD variable.
3) Have the script perform the V screen listing, then perform a redisplay of the current sector. Before continuing with the rest of the script. (yes, I know I need to update the information to include this.)

If you do not do any of the above, it does not matter how many times you query the SD variable. Or how long you wait between each query. It will always return a value of 0.

Hmmmmm. trying to figure out your post.

So, say I have a script running in the background. Say that it occasionally needs to lookup STARDOCK for whatever reason. (like my fig-hit-watcher, that shows me how close an enemy fig hit was to dock, among other things...) If I happen to hit V while that script is running (to check Cit counts or whatever), then the next time that the script tries to use the STARDOCK variable, it will get a 0 when it tries to query the database for the StarDock sector?

quote:
quote:Originally posted by Traitor
quote:
I believed that the displaying of local, i.ee the same computer, client connections and disconnects are not necessary. So the default selected state of the 'Broadcast a message when a client connects' in the setup menu has changed to the following:

You are unable to change the setting of this option, unless you have selected Accept external connections.

When not accepting external connections, the default is to not display messages when a local client is connecting.

You may think it's not necessary, but there were reasons it was there. I routinely have multiple things connected (zoc and swath) to my twx session, sometimes even a 2nd copy of twx connected to the first.


I also routinely use multiple client connections from Zoc, SWATH and TWX from the same machine. And in every case I know that I have made the connection to the one TWX from those clients. And for the most part, I also remember which client(s) are still connected to that same TWX.

Since you are loading the client(s), and making it/them connect to the twx running on the same machine. There is no need to display the connections/disconnects from clients running on that machine. But, it does still display the number of clients connected to it.

The only reason for the displaying of client connections/disconnects. Is if it is for a client that is not on the same system as the twx it is connecting to, or disconnecting from.



Whatever wabbit. If it's not obvious to you, I doubt I could explain it to you. I assure you that I have absolutely no memory problems, however.

quote:Originally posted by Traitor
Hmmmmm. trying to figure out your post.

So, say I have a script running in the background. Say that it occasionally needs to lookup STARDOCK for whatever reason. (like my fig-hit-watcher, that shows me how close an enemy fig hit was to dock, among other things...) If I happen to hit V while that script is running (to check Cit counts or whatever), then the next time that the script tries to use the STARDOCK variable, it will get a 0 when it tries to query the database for the StarDock sector?

If the script is not performing any thing after the V screen listing. That would cause TWX Pro, or any version of TWX, to perform an actual update of the game database. Then that is true. In TWX Pro I have attempted to have it to only update the information if the SD location is not already known.

As I have already stated, eight people have tested this release. (The eight people do not include myself.) And all have stated that they have not experienced any problems with the outlined changes/fixes/additions.

But, if you find that the SD location is continuially being update every time the V Screen is listed. Then just tell me and I'll fix it.



quote:Originally posted by Traitor
Whatever wabbit. If it's not obvious to you, I doubt I could explain it to you. I assure you that I have absolutely no memory problems, however.


The only legitimate use for the information of clients connecting/disconnecting, is for the monitoring of the connections/disconnections of remote clients. Whether it is done by a script or by your watching the display.

Otherwise, all local client connections are performed by yourself. Or by an application that you have setup, or have allowed, to perform the operation of loading a client and getting it to connect to a twx session. In either case you know that the client has been loaded and has connected to twx.

Now there are two other possible ideas for the use of local client information.

1) You have a publically available bot that requires the use of multiple local clients to be connected to a single local twx session. And that it has no other option but to monitor for the client connection and disconnection messages. To know if those local clients have connected or disconnected.

If that is the case. Then show me the actual source for this publically available bot. That has been available to all tradewars players, with this feature, for atleast 6 months. And I will then concide to you, and change the behavior back.

2) To monitor the possible use of twx by a virii/trojan/etc.. If that is the case, then I suggest that you look to yourself for not making sure that you system's security measures are good enough, or up todate.

But, if you insist this is something that must be addressed. Then the best course of action would be to only allow a single local client to connect to a single twx session. Or to change twx into a typical gui tw helper. (I'm not about to do that to twx.)

Ok, on the first point, I can test with my stuff and see if it's an issue. I have several background monitoring scripts, and if necessary, I can impliment a work around.

On the second point.
quote:
If that is the case. Then show me the actual source for this publically available bot. That has been available to all tradewars players, with this feature, for atleast 6 months. And I will then concide to you, and change the behavior back.

You just don't get it at all. I mean you really don't get it, you clearly NEVER will get it, and that's because you don't think big. It would be one thing if you said "it saves 2 cpu cycles per second, so was removed for speed." That I could understand.

It's not about the connections. It's about being notified that there was a disconnect. I'm not going to go into too much detail of WHY I like to be notified, because I run scripts that I don't talk about to other people. Private stuff that is probably so far over your head you wouldn't understand it anyway. But one thing I will mention is that I play on a laptop, with a small screen. I can't have all windows open at once, side by side. So it's important to me to know if one of my "processes" abends in another window before I alt-tab over to it and find out that it's not working when I really need it. I will grant you that 99% of the people out there won't care, and even I don't care 75% of the time. But you should not remove features just because you lack the capacity for seeing a use or need for them.

Change it back or not. It's clearly "YOUR" project now, not open source. I gave you input, you refused to listen.

You are now starting to sound exactly like the kind of narrow-minded person you originally didn't want to "control" the development of TWXProxy.

But that's about what I expected from you when you first announced that you wanted ownership of this project. We're done. I will use or not use your product as it suits me. I will follow it along with baited breath, looking for when you do something to improve the core of TWX, rather than simple cosmetic changes that *I* could have done with the code and the same amonunt of time, and with less bloat.

Wabbit; As much as I admire you for picking up the ball and "fixing" things here and there. You are working "alone" here w/o any feedback from your users. I only know traitor from reputation but I will say this he has done more for this community than you will ever think about doing. Not meant to be a flame but listen to what he says.

As a new question from looking at the database format how can you set the
Rob/Steal factor that is located in the TWXHeader?

Another question/request please keep backwards compatablility or announce that this version cannot/will not be compatable.
Currently the database version number has been incremented to 8 and any other versions will simply fail to load. The only work around I have found is to fire up the old version, export the warpdata quit and import the warpspec file in the new version.
From seeing what changes have been made this shouldn't be hard. If my memory serves me right you changed the DataBase Name field length and incremented the version #.
for example
DBHeader.ProgramName <> 'TWX PRO DATABASE' should not just fail and send a client message it should fall back to converting the old database format to the new format, or let the user decide.
I have just played around with the new source and am not sure about my system/settings but I cannot get the setup screen to show I have to use the '$' functions to create,delete,edit and select databases.

I would like to converse with you further if I haven't pi**ed you off too much but if I have I just want to say FAQueue.

One good thing about open source if you don't like the direction a project is going you can always fork it.

quote:Originally posted by The WABBIT

quote:Originally posted by Traitor
Hmmmmm. trying to figure out your post.

So, say I have a script running in the background. Say that it occasionally needs to lookup STARDOCK for whatever reason. (like my fig-hit-watcher, that shows me how close an enemy fig hit was to dock, among other things...) If I happen to hit V while that script is running (to check Cit counts or whatever), then the next time that the script tries to use the STARDOCK variable, it will get a 0 when it tries to query the database for the StarDock sector?

If the script is not performing any thing after the V screen listing. That would cause TWX Pro, or any version of TWX, to perform an actual update of the game database. Then that is true. In TWX Pro I have attempted to have it to only update the information if the SD location is not already known.

As I have already stated, eight people have tested this release. (The eight people do not include myself.) And all have stated that they have not experienced any problems with the outlined changes/fixes/additions.

But, if you find that the SD location is continuially being update every time the V Screen is listed. Then just tell me and I'll fix it.



Traitor, I just got done having Vid Kid do quite a bit of testing for the possible issue you think it there.

He states that it is not present in the current release. And he does not believe it to be possible. You do not have to take my word for it, go ahead and ask yourself. Zentock is going to be testing it as well later tonite. So, I'll have his input on this.


But, this mute now as I have found the cause of the issue. Well, the cause based on test scripts.

In all of my test scripts, I was using a waitFor statement after performing the send "V" statement. And it seems that the waitFor statement is fired, and cleared, prior to the db cache in memory is updated. And with that it seems that TWX will not update the memory cache until something causes the next game db update. Such as performing a sector redisplay.

If I had used a proper waitOn or a setTextTrigger/setTextLineTrigger w/ a pause statements set. This allows TWX to update the db cache in memory. Which means the issue mentioned by myself does not appear, unless you use a waitFor statement. And the SD sector number is available to all scripts running.


I will be updating the TWX Proxy Groups website, and the distributions changes.txt files.

Why take out client connection messages?

It doesn't make any sense in the first place. It just sounds like you are changing things to change things.

The client connect message may be helpful to a minority, but it is a hinderance to no one. It doesn't negatively effect the program in any way, yet it might positively effect someone's experience while using the program.

I guess it don't matter much to me, if I play anymore, I'm sticking with the bug-laden 2.03 simply because I'm not appreciative of the arrogance displayed by the 'leader' of this project. Xide was a stand-up guy, I haven't yet found that with the current leadership.

SupG

I personally have to wonder about the test group for the project. Perhaps no one else was interested, but you have a bunch of non-scripters testing a helper that is founded around the idea of user scripting. How much useful feedback are you really going to get from them?

xide = kick Butt
twx = kick Butt
2.02 = i'll prolly use till i die

Slim,

The problem with sticking with 2.02 is that eventually the authorization servers will go off line and you wont be able to use the pack 2 scripts and some of CK's stuff. you should at least upgrade to 2.03.

what is this? bash wabbit week? i dont see anyone else doin a *** **** thing with twx.. how bout some props to him?

Hmmm.. u ppl lost me awhile back. Must be nice to know everything about everything.