I was recently setting a macro when i botherd to read the bit of text that accompanys it,
To have it place on the command line instead, append the continuation tag: \... For example: "Jump" Executes the command while "Jump \..." places it on the command line.
I was wondering
I have the macro .click netter (yes this is castle lol)
If i put, .click sell \ .click netter Would it then sell the netter?
I was talking this over with a friend when i came up with a few more idea's.
for example, a location var,
e.g
.click netter \ .click {32,21,1}
to allow more lazy macro's to be invented. To expand on that i suggest:
.click netter \ .click {32,21,1} \ {sleep(100)} \ .click netter and so on and so forth.
Responses? ^.^
ID:133166
 Feb 21 2009, 7:36 am
|
|
|
#1 Feb 21 2009, 7:47 am
|
|
Kaiochao
 |
You can use "\n" in macros to do multiple things at once.
|
.click netter\n.click netter
| |
Thank you, i tryed making a very long one but it seemed to only do the first few commands. Aparantly there is a limit, what exactly is this limit, it varyed for me from 2 to around 10.
Also out of curiousity, are there any other things that you could use with macro's? Also, it would be awesome if i could do like .click buynetter\n{Alt+1} To set off a chain of macro's, i suppose if that particular one WAS alt+1, then it would make a loop that would crash the server, but if you limited that so you cant make loops, a macro setting off a macro would be sick | |
Rushnut wrote:
i suppose if that particular one WAS alt+1, then it would make a loop that would crash the server, It would crash the client, not the server, because the client is the one that gets stuck in the loop. Besides, it might not even crash anything; the client already can't send out more commands than the server can receive (one command per tick), so if it upholds that then there's enough of a delay for it not to crash the client. Problem solved! :) | |
Not really. It seems to lack much point and doesn't look like it'll be used often, and when it would be it could be used to cheat in games or otherwise get an unfair advantage by setting up prior macros to do actions rapidly. Besides, you're really going overboard with trying to make macro commands complex, as if they're a programming language themselves. Rather they're relatively simple in that they don't do anything special in the system - that is, they're just shortcuts for manually typing or using another method to execute an already existing command, etc. So this also means things like adding new functionality to client commands like .click doesn't have to do with macros, but with the command itself.
| |
I was suggesting adding in a few pre set Variables, nothing complex, well really complex atleast.
But what you said just gave me an EPIC idea Runtime code Editing, Screen goes splitscreen, One half code one half game screen, from there the player can, well, play. Active lines of code could glow red of be highlighted, changes to the code require the game to be "Paused" as will be do able by a pre set verb in byond. Once edited the game either restarts if it was somthing too big for dreamseeker/maker too keep running, or if it was somthing small like, changing the range of an archer lets say, the game would just unpause. I know this isnt going to be looked at ANYWHERE NEAR the near future, but i think it would be so benifitial to newby coders to see there work in action, to see what lines of code are actually DOING! | |
I'm sorry, you're just coming up with crazy suggestions and saying they are cool, but irregardless they're just not feasible or of much use in practice. >_> Try to give them more thought.
| |
I think you need to tink a bit farther ahead than you are currently doing.
Whats a better way for a newby to learn? editing, compiling running, getting the error, trying to find the line, which isnt always accurate, fixing it, repeat. or Editing, Compiling, Unpausing, Seeing what line the error occurs on in runtime, fixing it | |
Rushnut wrote:
Editing, Compiling, Unpausing, Seeing what line the error occurs on in runtime, fixing it If you turn debugging on; it tells you exactly what file and line number runtime errors occur on. | |
|
#12 Feb 23 2009, 8:45 pm
|
|
Rushnut wrote:
I was recently setting a macro when i botherd to read the bit of text that accompanys it, A few friends and I have had this conversation about this manner of automation via macros, and none of us have come up with any valid reason beyond the will to cheat or otherwise gaining an unfair advantage. Any reason otherwise is simply a lie. I don't think it'd be a wise use of time to program this functionality directly into BYOND when there's already plenty of third party programs designed solely for this purpose (this one being my favourite). | |
Mobius Evalon wrote:
(...)Any reason otherwise is simply a lie. I dare to disagree. While I agree that the will to bypass intended game restrictions (cheating) is the main reason behind most peoples desire for macros, there is one other reason. Macros can partly compensate for bad user interfaces in games. Since the original poster mentioned Castle, I'll stay with the example. The game works nice, until the "Time Wizard" has bee killed. Upgrading is essential to survive afterwards, but this upgrading consist out of more than 1500 times of clicking a button. Trust me, after the first 500 clicks, it's hardly funny any more and makes you strive for a macro. Yes, this is something the owner of said game could fix rather simple (if he'd still care for BYOND), however often enough, games like this become unmaintained and the users are left alone with such trouble. I am unsure about the use, or hint at third party software, since BYOND often wants to "keep users focused around BYOND", instead of outsourcing. All in all, while I can see the "legal" grounds for the request, I do not think that the possible gain would counterbalance the effort required and the possible abuse. | |
It isnt always accurate, ive often had errors teeling me they are in the original . dme
Then i get told bugs are on file X line 1000020203 or somthing insanely high, nowhere near as many code lines, or even words, that are in the file, as i said It is not always accurate | |
Rushnut wrote:
It isnt always accurate, ive often had errors teeling me they are in the original . dme It is always accurate, the only time its going to give you an off-reading; is if you modified the code in between the time you got the runtime, and the time you're checking for it. And even then, it would only be offset by a few lines unless you did something major. Apparently you just don't understand how to read error reports properly. | |
It's consistently accurate, however due to how reading the code works it can often report an error on the line after the line with the actual error, as it didn't know there was an error until it found a newline in the wrong place without whatever was expected before it (etc). If the error was on a file's last line, it would be reported to be in the DME file, yes, because the compiler works by reading each file then going back to the DME to see what's the next included one, then reads that, etc. In such a case you can easily figure out in which code file the error was and you know it's on the last line, though you do have to navigate to it manually.
| |
I have to agree when he mentions the balance between benefit and risk.
This would be like someone suggesting increasing the functionality of macros in World of Warcraft, so their character could kill mobs without their interaction. This just leads to people abusing the functionality in RPG games where farming is necessary. If the game maker feels it is beneficial to the functionality of the game then they can add things that will more than compensate for what is being discussed here. | |
Well, a runtime error couldn't ever really report inside of anything but a code file. Errors that cause the dme to be reported will always be caught by the compiler because it'll catch the missing closing statement.
Since runtime errors only appear for compiled code they'll generally be very accurate but not always as informative as they could be. | |
