Using datatype methods

[Lax]

Methods are much like members, except that they will never result in a new object, and are accessed via : rather than a .. Like members, they can have indices, and can be chained, etc.

For example:
${Spawn[something]:Target} will target the given spawn, and because it is used in ${}, it gives the spawn type's return valuee (the spawn's name). You can also do ${Spawn[something]:Target.CleanName}, which will both target the spawn, AND give the result of the spawn type's CleanName member.
Methods can also be used as commands, so this is valid in the IS console:
Spawn[something]:Target
or
Me:Target
(because Me gives a character type, and character inherits from spawn)

Buffs can be removed like so:
Me.Buff[1]:Remove
or
Me.Buff[Aegolism]:Remove

Window buttons can be clicked like so:
Window[COMBW_CombineArea].Child[COMBW_CombineButton]:LeftMouseUp

That pretty much sums it up for now. There's other methods available on the base LavishScript and Inner Space data types as well.. for example.. MyInt:Inc[14] will increment the int variable MyInt by 14. See the LavishScript and Inner Space data type wiki pages for a complete list of methods for those types.

[jabon]

Many questions, as is my fasion...

Could you explain why you use the ":" operator? Why deviate from the standard "." member operator? Along the same lines, using "[]" to pass arguments to members is on the side of confusing, it makes it look like an array.

You mention that methods can be used as commands, but isnt that their sole purpose? I would argue that you need another abstraction layer as exposing the user to direct member calls can be hazardous and definately is confusing. Stuff like using ${} as some kind of typecasting/nested fuction call is not going to go over well with people who just want to *use* the software, not develop it.

[Lax]

Methods and Members are different internally:
#define GETMEMBER() GetMember(LSVARPTR VarPtr, PCHAR Member, int argc, char *argv[], LSTYPEVAR &Dest)
#define GETMETHOD() GetMethod(LSVARPTR &VarPtr, PCHAR Method, int argc, char *argv[])

And use a different name map for speed (e.g. dont have to add another variable to the struct that says if its a member or a method, do another comparison, then call the right function style) and thus can have the same name as a member, and behave differently on the outside (e.g. will never result in a new object)... so using . is not really an option, as it is already used for members.

Using [] to pass arguments to members and methods does make it look like an array, but it is done for consistency. Instead of looking like an array, it makes arrays look like passing parameters, which is literally the same thing.

Of course it can be hazardous, but that depends on the implementation. You see, it will only change a value if its a LavishScript variable. So its not like someone can do Spawn[name].CurrentHPS:Set[1]. That wont do anything at all. If it's not a LavishScript variable, the value is just a number assigned in a structure, e.g. Dest.DWord=123; <---- that's what theyre changing, if anything.

It would be super-confusing to continue to use . For example... consider the example given with spawn:Target. Say you did this: ${Spawn[merchant tekram].Target} ... you would expect to end up with merchant tekram's target. However, with ${Spawn[merchant tekram]:Target} you can safely assume you will target him, and you can also safely assume you arent going to end up with another object, such as his target.

People who just want to *use* the software dont have to worry about methods at all. In fact, people that just want to *use* MQ2 dont even know the first thing about data types or members.

[Red-One]

I'm wanting to try to move to IS and I guess the hardest part in doing so is converting the macros I use, namely Genbot. So I guess that your reply above pertains to what I need to change to convert it.


Is there an easy way to read a statement and determine what needs to be changed? It does some complex things. While I understand what it is doing, I don't know the things behind the scenes like "what of whats property/TLO/method/datamember it is accessing, and that is the reason to change/not change it".

I guess to better explain, I understand what this does:

Code: Select all

/if (${Math.Distance[${Math.Calc[${Target.Y}-${Math.Cos[${Target.Heading.Degrees}]}*

But I cannot look at that and say, "Ohh, this needs changed". Or "Ohh, this will work fine". The same goes for a line that is less complex, but has a lot of periods in it, like this one:

Code: Select all

/if ((${Group.Member[${tempvar}].PctHPs}<${PalHealPct})&&(${Group.Member[${tempvar}].State.NotEqual[DEAD]})) /call PallyHeal ${Group.Member[${tempvar}].ID} 

I guess as I look at the macro, it is most likely beyond the scope of my abilities to convert it, but I'm willing to give it a shot. (Or donate nicely for someone else who does it! )


-Red


edit: By the way, isxteamspeak and the hud along with it are sweet! Works good, although some names drop off (maybe by design if they don't take or a while, or just the last X amt of people to speak) the list sometimes.

[onetimehero]

in my experience, a lot of the conversion work is mundane:

1) Stripping / from commands
2) Surrounding if statements with " "
3) converting /for loops to do {} while
4) remembering to use EQExecute for commands that aren't part of ISXEQ (EQExecute /sit, etc.)

Not so mundane:
1) Ripping out /goto shit.

Start small, work up.

[Lax]

I had this all typed out and forgot to post it earlier, before onetimehero's response.. so here it is

Well, here's the thing. Inner Space scripts do not use slashes in the commands, so each and every slash gets removed first of all (i.e. /if turns into if). Any EQ command must use the "EQCommand" command, e.g.:
EQCommand /tell bob hi

All variables, top-level objects, etc are going to be almost exactly the same. The lines you pasted require very little change (though you left some off the first /if). Remove the slashes, and change the if so that the entire condition is surrounded by quotes:

Code: Select all

/if "${Group.Member[${tempvar}].PctHPs}<${PalHealPct}&&${Group.Member[${tempvar}].State.NotEqual[DEAD]}"

You'll notice I removed all the (), but that has little to do with LavishScript and you could leave them in if you want -- it's just that it's not disambiguating anything in that if, and LavishScript ifs dont require using parentheses around the entire condition like the MQ2 if. LavishScript does have special characters though, which is why you must use the quotes.

[Red-One]

So is there an easy (or general rule maybe) on how you tell what needs to change from .'s to :'s. Maybe if you could get a few basic examples with some of the things uses more often in scripts I could try to get a general idea.

All variables, top-level objects, etc are going to be almost exactly the same. The lines you pasted require very little change

.


I guess you hit the nail with what I am looking for. I am still getting familiar with IS and I'm not sure of any diagnostic techniques I can apply when trying to convert such a big script like genbot. If there were something I could reference to be able to figure out the differences I could fumble my way through it. The wiki is far from complete it looks like, and it doesn't get down to the specifics while at the same time saying it in laymens terms.

I know documentation for things such as this will never turn into "Noobs guide to compiling MQ2" and it shouldn't, but anything I could reference to help me know what to look for during the conversion process would be sweet.

When you talk about taking out the /goto's, is that because everything in LS is functino driven? So logic as simple as (my favorite example):

Code: Select all

Sub Main

Loop:
     /itemnotify rightear rightmouseup
     /delay 1
     /goto Loop:
/return

would have to be rewritten (besides taking out slashes and stuff). I guess as I look at it, it is not really good logic. Creating an endless loop isn't good, but I guess thinking that there is alway /endmac that it doesn't seem so endless. So assuming there should be a way to break out of it then the logic would be easily to convert to a do/while above, just choose your condition I guess.

Anyhow, there are more complex /goto uses beyond this, maybe either of you can put my above example into the right meaning for the context that I am trying to say it in, if that makes sense.


-Red

[onetimehero]

Well,

Code: Select all

Sub Main 

Loop: 
     /itemnotify rightear rightmouseup 
     /delay 1 
     /goto Loop: 
/return 

could become

Code: Select all

function main()
{
  do
  {
    itemnotify rightear rightmouseup
    wait 1
  }
  while "1"
}

and you could use

Code: Select all

/endscript scriptname

within EQ to end the script at any time.

[Lax]

You never change any . to :. The : are completely new, and are completely separate from .

LavishScript is actually just as function-driven as MQ2 is. The only real differences as far as that goes would be MQ2 calls them "Sub", and doesnt use curly braces :) The reason goto must be removed is it's not supported in LavishScript. LavishScript has some optimizations in its engine that prevent it from being implemented easily. Goto is generally regarded as being sloppy and something that should be avoided at all costs.. and its not really necessary anyway.

[Lax]

To be more direct ... you shouldn't have to change any ${} at all to convert to IS. However, you need to make sure the rest of the macro's syntax is good -- commands, functions, #events->addtrigger, etc

[xyilla]

коро

[xyilla]

240.1

[xyilla]

PERF

[xyilla]

PERF

[xyilla]

Кары