If this has already been done, I missed it.

I am curious as to the stats on scripters. Personally, I script primarily in Java using SWATH and use mostly my own stuff and a few of the public ones from the SWATH library.

It appears that I am in the minority as far as scripters go in the TW community. It seems like most people feel that twxproxy and rexx/zoc are faster and better than Java. I think this is a myth that will be debunked as more java programmers release scripts for SWATH. Do I think Java is better? No, but IMHO it is much more versatile overall. Is there more overhead with Java? - usually - but there are ways to get around almost anything if you know what you are doing. Now I am off topic...

My original reason for this post was to be about suggesting that EISOnline run a poll as to see stats on scripters and what tools they use and maybe how often they script, etc. I am just curious to see the numbers.

Personally I hope to learn more about TWXProxy, and Rexx/ZOC scripting if I can just find the time to do it. That way, maybe I can put together some "like" scripts to really compare the speed of each method. (Guess I need to stop playing for a while).

Anyone have any thoughts on this? Expecially from anyone that is experienced in scripting in more than one tool?

I haven't scripted in a year, but to my knowledge some of the very best Java scripts, were usually beat out by the same caliber TWX scripts.

I way prefer TWX world SSM to the Swath version. And no I don't write, just now getting into looking at it.

twx > swath, no question

Thats rather broad slim. I am asking the question - why? What leads you to this choice/conclusion? What makes it greater?

quote:Originally posted by rgorion

Thats rather broad slim. I am asking the question - why? What leads you to this choice/conclusion? What makes it greater?


TWX is designed for use in Tradewars and as such its database makes writing scripts a lot easier and possibly more efficient from the scripting aspect. I don't know anything about Java, but I know the learning curve in TWX is very short.

A simple, what is the most commonly used scripting language question would result in TWX being the answer.

The photon script I used to hit you in game R, was a simple script written in TWX.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

Does anybody see what I mean? So far the examples mostly just state that TWX is better just because people are more familiar with it and it has less learning curve. Knowing Java first and coming from a different vantage point I would argue that there is just as much learning curve scripting wise with TWXProxy. Java is a pain in rear to setup properly for a novice (SDK install, classpath, etc) so I will give TWXProxy the definite advantage there.

Promethius - your example of a photon script is a good one for me in that the same script is just a few lines using the SWATH API.

I am not trying to be argumentative here (although this does sound that way). I guess I am just trying to challenge the status quo and get some of the expert TWX scripters out there to give Java and SWATH a long hard look as opposed to saying TWX is better based on familiarity. If this community put its collective brains behind java scripting as well we could see the next evolution in TW play.

Because we are talking about JAVA - it opens up a huge realm of possibilities.

As an example of some of the fun things I have been able to do with my Java scripts...I created a WAP servlet that runs on Apache Tomcat and interfaces with a socket listener on my home machine. My home machine runs a defense script that also interfaces with the listener. Someone attacks my base and it messages my cell phone to let me know. I then access the WAP servlet (I pay the minimum fee for internet on my cell and this uses only a few kilobytes a month) and I can tell my ship to switch between different defense modes (ie. photonwatch from the citadel vs lift and attack when someone gets in, etc). I can also issue an escape command to say get the heck outta dodge and planet warp my money planet out of there.

Now I would never expect a novice to try anything like this, but it is an example of the possibilities Java gives you.

Again no offense meant - your photon script was very quick as expected, although it was my fault for being careless and bumping your fighter while I was moving around in my pathetic little ship (I joined that game a week late just to have some fun).

Java is slower, TWX proxy is faster. I can write a photon script in under 100 lines now using sector parms. Quite trivial. I can write a pdrop in under 30, or an adj-direct pdrop in under 100 w/ sector parms. The swath API is very very slow compared to TWX proxy, the daemon implementation is faulty and the events handling is not nearly flexible enough. Even with a good daemon you would have to resort to sendstrings to macro everything to the server just to compete.

The benefit of TWX is that it's written specifically for tradewars, java is not. The constructs in TWX scripting are quite basic and instinctual. There is no object orientation to get in the way of what is otherwise a straight-forward interpreted language. Even WITH a background in java, TWX is still easier. Talk to Mind Dagger, I helped to convert him to TWX and now he writes exclusively in it. Why? Because to implement, say, a twarp gridding script in java it would take an elaborate mix of approaches that would end up being too complex to be effective. I can, however, implement a basic single-hop twarp gridder in under 200 lines with no complex function mapping, flowcharts or anything other than just sitting down and crunching it out.

TWX proxy scripting is rapid app development for tradewars, it makes your time much more efficient. Even with a background in java. A photon script is definately not "a few lines" in swath-java. By the time you setup fig monitoring, handling spoof detection, finding the adj, pwarping, firing and returning back to the home sector (which isn't always updated correctly even). By the time you have all of that done you'll be looking at more lines of code and a more complex implementation than I am. Heck, half the time swath doesn't even correctly store the fig list, let alone detect all of the fig hits.

While your approach is tech-nifty, it's really complex. A lot of points in it could fail, and a lot of ways you could get stuck in a bad spot. Not sure how you'd even get your swath to listen like that, considering how limited that API is. I'd have to see that to believe it was even possible.

In theory I could create a local proxy to do all of above, but... well, I never will. That approach will get you killed if you ever play in a competitive game. You can't expect a citkilla to work on advanced players. Tech skills don't equate to key time. Please run a photon script afk... I love those. Easiest way to lose that planet.

For speed TWX is much, much better, as speed obviously plays an extremely large factor in-game. TWX also has many readymade (on-fly) game handlers, which is also of a great convenience to its users. As a script language TWX is easy to pickup on and understand, additionally TWX serves to teach it’s users the basic platform/framework to fluid software development should they decide to take that next step.

For Java, it affords the ability to write fully bored objects, functions, and rules that can be reused and modified as needed, (whereas TWX is limited in these respects.) Though Java is very slow, very unkind to undefined error/bugs/environmental hick-ups, and is a very complex language to learn. Personally if I were to invest my time in learning a fledging language, Java would be one of the last on my list.

For the purposes of enjoying TW, TWX can’t be beat. For the purposes of modifying game play through auxiliary applications, Java is surely a consideration, though there are much better languages that Java can’t begin to compare with for overall functionally, speed, versatility, and wide-out compatibility, (namely the .NET Framework.)

Singularity and RexxCrow - now those are the type of answers I was looking for. Thank you both.

quote:Originally posted by Singularity

Java is slower, TWX proxy is faster. I can write a photon script in under 100 lines now using sector parms. Quite trivial. I can write a pdrop in under 30, or an adj-direct pdrop in under 100 w/ sector parms. The swath API is very very slow compared to TWX proxy,

I will take your word for the slowness - as for the lines of code - I agree that it would take about 100 lines total, but most of those lines of code should be in external classes that you call in the main program - thus the main program could be about 30 lines - but lines of code executed would definitely be about 100. As I build my own componentized code to handle simple tasks it does get easier - but yes it is still a lot of code.

quote:the daemon implementation is faulty and the events handling is not nearly flexible enough. Even with a good daemon you would have to resort to sendstrings to macro everything to the server just to compete.

Very true, a co-worker of mine kept getting on Stein's case about the event handling and daemon implementation. He got into running daemons way more than I have.

quote: I can, however, implement a basic single-hop twarp gridder in under 200 lines with no complex function mapping, flowcharts or anything other than just sitting down and crunching it out.

The more I read - the more I see that using a SWATH and TWXproxy combo is probably the way I will want to go.

quote:
TWX proxy scripting is rapid app development for tradewars, it makes your time much more efficient. Even with a background in java. A photon script is definately not "a few lines" in swath-java. By the time you setup fig monitoring, handling spoof detection, finding the adj, pwarping, firing and returning back to the home sector (which isn't always updated correctly even). By the time you have all of that done you'll be looking at more lines of code and a more complex implementation than I am. Heck, half the time swath doesn't even correctly store the fig list, let alone detect all of the fig hits.


My AFK scripts are strictly defense only - no go after the enemy movement. The planet photon watch I mentioned was just sitting on that planet and firing once an enemy hit the adjacent sector - it mainly delays the inevitable, especially because once he wipes out those figs I can't tell if he is moving in and of the adjacent sector unless I am in orbit scanning.


quote:
While your approach is tech-nifty, it's really complex. A lot of points in it could fail, and a lot of ways you could get stuck in a bad spot.

True, but I have had generally good luck with it and have refined it whenever a weakness was found. As I said - this is impractical for most players and probably even unnecessary. I did it mainly because my actual keyboard time was so limited - between work and having 2 toddlers at home. Plus there is the fun of making an idea like this work just for the sake of doing it.

quote:
Not sure how you'd even get your swath to listen like that, considering how limited that API is. I'd have to see that to believe it was even possible.

My post was confusing in that I was not using the SWATH Event Listener for the socket connection. None of that code was from the SWATH API - it is from the Java SDK. Essentially - I had to put a timer in to breakout of the SWATH Event listener that was listening for ShipEnteredSector and other events. For a split second, it checks the dataInputStream of my "CommsRelay" class for any new command messages that it had received. The comms relay is an external java process (external from SWATH) that can run as a Windows Service in the background (but I normally execute it by hand in a command window so I can easily look at the output messages). The comms relay uses the Java classes DataInputStream and DataOutputStream to receive and queue up/pass along data to anything that connects to it. Here is a snippet of my code to show the general idea:



It's that split second of not listening for SWATH events that stinks. I don't really have a way around that at this point. But yes, I have built this and it does work, even with the minor flaws.

quote:In theory I could create a local proxy to do all of above, but... well, I never will. That approach will get you killed if you ever play in a competitive game. You can't expect a citkilla to work on advanced players.

It has - just ask Psion (well at least at first it did). Again, I was mainly looking to frustrate the opposition and keep them at bay at least until I could get to the keys.

quote:
Tech skills don't equate to key time. Please run a photon script afk... I love those. Easiest way to lose that planet.


As I said above it wasn't that type of photon script - I actually dislike that tactic and don't use it unless someone keeps doing it to me.

I wasn't posting to try and brag about tech skills - I just wanted to get some discussion going about Java to go along with TWXProxy talk, and we have a good start here. (ok so I threw some bragging in there - I worked hard on this stuff!)

[RG]Orion < pats self on back..

Rexxcrow - you must be joking about .NET - Talk about adding complexity! Versatile yes - better than Java outside of TW - I say bah!

I should mention that my company was just bought out by another company who uses primarily .NET - so perhaps I will be posting here to agree with you in about 6 months. My department will still be on Oracle and Weblogic for quite a long time, but I need to get up to speed on .NET too. I have done some web services with Weblogic Workshop and I know .NET takes that concept to the Nth degree. It should be fun. I hope.

Java handles errors pretty well, it uses a general error handling method that is very effective. TWX proxy can easily re-use functions and code, altho objects are non-existant (objects are for OOP, twx proxy script is not an OOP language).

If I was to make an application for TW it wouldn't be in java, certainly wouldn't be based on top of a helper. Java is just as fast as the .NET framework on most benchmarks, they are both "high level" languages that compile to runtime bytecode (so are twx scripts, really). The biggest issue in that conflict is what platform you use. If you're on Linux... It's Mono versus Sun's Java. 2 proprietary systems... not an appetizing prospect. There are of course elements in each language that inherently perform better (saw an interesting article on garbage collection a while back).

quote:I will take your word for the slowness - as for the lines of code - I agree that it would take about 100 lines total, but most of those lines of code should be in external classes that you call in the main program - thus the main program could be about 30 lines - but lines of code executed would definitely be about 100. As I build my own componentized code to handle simple tasks it does get easier - but yes it is still a lot of code.

I challenge you to actually write this. What you will find, as I've found in the past, is that it's a lot easier to think about than it is to actually make. I couldn't get a complete (and fast) ptorp done the swath way for 100 lines. For TWX it's as simple as (psuedocode):

:reset_trigger
settexttrigger figs :gothit "Deployed Sector Fighters Report"
pause

:gothit
if first_word != "Deployed" then goto :reset_trigger

loop(x=1->warpincount[hitsec]) {
if warpin[hitsec](x) = figged goto :firetorp
}
goto :reset

:firetorp
send " p " & $adj_sector & " * y c p y " & $hit_sector & " * * q p " & $home_sec & " * y s* "
goto :reset_trigger

....

Not too difficult. Let me know if you want to test that in detail, I can whip up a limpet and fig foton pretty quickly using 2.04's figlist parsing.

quote:Very true, a co-worker of mine kept getting on Stein's case about the event handling and daemon implementation. He got into running daemons way more than I have.

This is one of the biggest headaches in Swath. If it ever does get fixed and some additional flexibility added... it could turn out to be quite decent.

quote:The comms relay is an external java process (external from SWATH) that can run as a Windows Service in the background (but I normally execute it by hand in a command window so I can easily look at the output messages). The comms relay uses the Java classes DataInputStream and DataOutputStream to receive and queue up/pass along data to anything that connects to it. Here is a snippet of my code to show the general idea:

Thanks, now I understand what you're doing there. Is it stable to leave that going for long durations? One of my biggest balks about java has always been the interpreter footprint. 1gb of ram and I still get serious memory leakage every time I run a java app. Ugh.

As for the ShipEnteredSector event... I've had problems with that not detecting the right ship type. I suppose you could code around this, but that's another one of my issues with swath's java. I had that triggering every time a corpie would enter my sector... originally I was using this to play a wav file, but it didn't distinguish between allied, hostile, etc. So then I get someone that wants to colonize at 6am before work and I wake up freaked out thinking I'm getting gridded to death.

In order to get all of the events and functions to operate the way they should you have to spend a great deal of time coding around their particulars.

In TWX proxy this is literally as easy as setting a text trigger. You get the string you want and set a trigger on it. After it's executed all you need to do is run a spoof check to make sure it's not something someone typed on fed (or as a planet name, etc). As a sidenote, Swath has some reported problems w/ spoof detection. I had a chance to see a few of these first hand, and even find a new one. To be safe you have to do this checking on Java too.

quote:It has - just ask Psion (well at least at first it did). Again, I was mainly looking to frustrate the opposition and keep them at bay at least until I could get to the keys.

Last game someone tried that on me it ended up costing them 10m figs. Lucky for him he got back to keys before his planet was completely out and managed to save himself. But it doesn't always work out so well... Normally we end up with the planet and a kill if someone runs citkilla AFK. Even when there's no gbonus you can still find a ship with decent def odds and run that puppy down.

While Java is obviously a better application platform than twx scripting (since TWX scripting wasn't built for general apps) it has a lot more flexibility. But if you just want to crank out a script that can anticipate your enemy's next fig hit and drop on it or wait @ dock for a red to show up and try to kill... well, TWX proxy scripts can't be beat. The amount of data you can collect is limited only to your imagination. You don't need to rely on swath's handlers or go thru the messy process of trying to set one up yourself. You can have a background script running to collect all activity @ the server and seamlessly pass it back and forth between other active scripts.

As for .NET versus Java... 6, half-dozen... same diff. MS improved some details but they're both fairly closed systems. I hate closed programming languages.

Java is good for everything but speed. Please feel free to use all the Java you want. Then let me know where you play at.

[:D]

quote:Originally posted by rgorion

Rexxcrow - you must be joking about .NET - Talk about adding complexity! Versatile yes - better than Java outside of TW - I say bah!



LOL, your just blinded by Java love, watch in 6-months you will definitely be singing a different tune... literally, you will be singing that C# high and proud! Smokin’ But, you of course already knew that, hehe. [^]