The macros aren't in swath's game file, it's in swath.cfg. That's an XML file, you can edit it however you want.



LOL. This kind of stuff cracks me up. Oz writes a pdrop, LS revises it, you decide to take that revision and add it to the bot. At that point there's so many layers of cruft you'd be better off writing your own.

Zoc menus work fine, but most good scripts hold the settings from run to run anyway. Those would be located in twxproxy's .cfg file for the game. That's also just plaintext.



Well, here's what I'm talking about:



That's TWXproxy's .CFG file for a particular game. This is not a complex file format. Read each in, split at the =, create a key->value pair array, done and done. Using that you could interface SaveVar and LoadVar with Zoc and never look back. Of course that's computationally expensive, so if you're working with just a very simple script and a single variable, then why bother? Like I was saying, you could easily write to an external config file for something like that.

But if all you need to do is handle menu settings for a script, all of that is way overkill. When you load a script it says "Loading script" ... you can auto-trigger off that and have it run a zoc script that automatically spits out the required settings for you. Delay a little, send, delay, send, delay, send, blah.

Now if you want to automatically set settings like figwave, well you have options there. The easiest is to modify the twxproxy script to do a c;q and just get that at start so you never need to input it. I mean why make it more complex than it has to be?

Failing that, you could have an autotrigger that gets the c;q everytime it sees it and stores it as a file as part of a little mini helper. If that fails, then you could have twxproxy pass that data back somewhere a long the line and trigger off that.

The macro _strings_ ?

I'm not sure what you're referring to...

C:\Documents and Settings\All Users\Application Data\SWATH

Swath.cfg

Look under <macros> and see if that's what you're talking about.

Not the way I see it... It's a lot easier to write zoc scripts that call menus.. here's an example:



I could just write my own pdrop script as you suggest.... but how long would that take me? The above took less than 10 minutes.



I know, but what about multi-line values? You don't have any of those in your example. Plus, that file might not have everything I want.

But anyway, I agree with you I could read the twx .cfg file. And save to my own format.

I'm pretty sure you're thinking of the macros themselves, not the 'macro strings' used as variables.

In Swath, go to Edit -> Game Options -> Macro strings

Hehe. The amount of time spent writing a torper or a pdropper is very small. You've already done more work than that here. This is a fun challenge, but it's not efficient.



About a half hour. Factoring in the work done to-date...

Then there's the whole "WTF did the script do that for?!" thing that comes up in play. You can't debug someone else's .cts script the way you can your own. You'll always be limited by that. Obviously you have the skills to write your own.



Well, the twxproxy .CFG file has no multi-line values except arrays, and they're stored a bit differently, but you could still parse them easily enough. Anything saved via saveVar will be in there. If it doesn't have what you want, write a script to save the appropriate data via saveVar. That's a problem you're going to have regardless, ex: how do you get the source data you're looking for?



Ugh. Swath, so... slow. Yah, I've never really used those before. Turns out it's in the game-specific CFG file tho. lets say you save the game blah.swt to c:\, when you save a macro string it writes blah.cfg and the bottom has...



So yes, you could write to that file. Not sure what it would take to force swath to re-read it tho, but it'd work great for 1-way read-only exchange.

I still disagree, for the most part. I've never written a torper or pdropper but i guarantee (edit: well... almost... maybe these are bad examples) it would take me a lot longer than a half hour to re-write Oz' improved pdrop or ptorp with the options I wanted, even if I had the .ts. Clearly, my zoc solution was a much quicker means to the desired end (edit: even if we assume it only takes a half hour to edit a ts to do the same thing as my zoc script is doing, still at 10 minutes that's a third of the time the zoc way... I've edited other scripts, granted probably more complex than pdrop / ptorp, and it takes a while to sift through, especially if the writer used nearly meaningless variable names as is often the case).

I just had a long discussion with Vid on ICQ; he had a lot of the same questions and comments you have. What it comes down to is that this is an easier way to do some of the things I want to do. If someone hasn't already written a script that does exactly what I want, then yes I can write my own twx, but if it's already there even as cts, it takes 10 minutes to set it up using zoc.



You found it!... I looked at mine and I coulda sworn it was all hexed up or something.. i'll have to look again.

I take the complete opposite view: it's not challenging in the least, which is part of why it's more efficient.

My zoc script has lots of lines, but that's for clarity, to make it easy to edit if i want to add another menu item using different options of the script. The thing could be written in a couple lines, I think. Actually, if I rewrote it I might include more comments for all the other options (if I expected to want to use them) so I don't actually have to look at the menu to code different options.

Your time, not mine. Spend it as you wish, you don't exactly have to justify it w/ me. We'll see in a year from now if you still feel that way

Good luck

A year from now, I'll probably know trade wars and twx better, and will have written many of my own twx scripts, and yeah i will probably gradually revisit certain scripts I'm using and replace them with my own scripts. But that all takes time - at the moment this is a really quick solution.

I don't have to justify how I spend my time, but I find it hard to believe that you think it's easier/faster to reinvent the wheel... one of us must be missing something.

Shrug. I wrote my initial quickfot in like 20 minutes.

Since then I've probably added 10 hours into it over the course of like a year and a half. Version 2.2, or whatever I've got, rocks. It does full holoscans via ss, does them safely (really hard to counter torp it), does return as part of the macro burst (making a landing trap difficult), has all sorts of safeties. It doesn't do kill because, frankly, I think that's a horrible thing to have on a torper (brings limpets home, risks getting your planet stranded afk, etc), has a ton of little features, pre-caches the figs and keeps them up-to-date, doesn't hang on a lot of stupid little things, etc. It works great with mombot as a drop-in replacement for the pwarp torper, and what's fun is if you drop it into commands it'll work alongside saveme. Best of all, it's really simple. The basic setup defaults to stuff that works in 90% of the circumstances so some freaked out corpie can turn on the torper when the grid gets hit even if I'm not there.

Long story short...

I couldn't have gotten a script I like built out of someone else's work. I've tried, yeaaaars ago I rewrote supg's ptorper like 10 times, added a lot of god-awful features and most of them just slowed me down and were impossible for others to learn. Was a waste of time, was better to rewrite from scratch. I've prolly written 10 different torpers, this latest one is simple, safe and effective. It was a good investment of my time, taught me a lot, and wasn't a big project. I get into a game, find a problem, fix it, roll out a fix inside of a few hours. Turn-around time between fixes and bug discoveries can even be in the minutes, rather than hours, if I'm sitting there... as I know the code and fixes are easy. That's really important in a competitive game. I needed a way to overcome a speed problem, I rewrote a chunk of the macro in 20 minutes and had it out the door and loaded on the fastest bot in an hour. You can't do that with other people's scripts. Especially if it's a .cts, you're limited by their vision for the script.

It's just a time investment thing. Sooner or later you'll have to write your own anyway, why not sooner over later?

Anyway, that's just my opinion. Obviously if you just want to automate a complex script you use constantly there's no sense in spending 2 weeks re-writing it to do exactly what it already does. But a torper isn't a big project, it's a good first "my first full script" kindof thing. But of all the above is why I tend to use only scripts i've written, or at least scripts I've worked on during development. Makes changes, fixes, soooo much easier. And there's this whole "vision" thing for a script. People just see scripting differently, they want something different out of a project, and what makes sense to one might not for another. You'll run into that more and more as you go.

iirc, the main reason I don't use your torper much is because it doesn't filter aliens. I know, aliens suck, but they are in the edits that seem to be the busiest.

dny quick photon ignores aliens

Helix

Uhm, it does ignore aliens.

I'm not saying you have to use it, I'm just saying there's a reason why you should write your own stuff... that being if you want to do something different
you can. You can't do that w/ a cts.

>> Uhm, it does ignore aliens.

Sorry... must be thinking of ck or something.