[vJASS] Noobish help about struct attaching

[KnnO]

Hi,

I have a noob question since I am learning vJass...

1. can struct components names be the same arguments for the static method create?

2. Can someone explain to me how to attach a handle to the struct instance to a unit
Because I am not sure what to use here, a timer or what, since the instance will last forever...
And how will I manage the handle variable through GUI?

struct bomb
	real t
	unit u

	static method create takes unit u, real t returns thistype
		local thistype new = thistype.allocate()
		set new.u = u
		set new.t = t
		return new
	endmethod

	method move takes real a returns nothing
		set this.t = this.t - a
	endmethod

endstruct

function createBomb takes unit u, real t returns nothing
	local bomb new = bomb.create(u,t)
	// ? attach ?
endfunction

function moveBomb takes unit u, real a returns nothing
	// local bomb h = ? get u handle ?
	call h.move(a)
endfunction

3. Is there anything wrong in my beginning code ?


If there are vJass systems I should import then it is ok

 

[Cokemonkey11]

1. Yes, and your example create method will work.

2. Are you talking about the pointer to a struct instance? It's not a handle. You can't handle structs in GUI.

3. Your move method should say set this.t = this.t - a. the term .t refers to a static variable, so that's not what you want (and same with .a).

 

[KnnO]

I edited the code to fix the .t => this.t (and .a was a mistake).

Maybe, the pointer of the struct instance, so it is not a handle literally
And the pointer is stored into a variable of type <bomb>.

so my way I think is to declare two arrays (bomb and unit) so each index refers to the pointer and unit, and a variable (integer count) that tells how many instances?
(like MUI in GUI)

And make a function that searches for the unit in the array and returns its index.

struct bomb
    real t
    unit u
    static integer count
    static unit array U
    static bomb array B

    static method create takes unit u, real t returns thistype
        local thistype new = thistype.allocate()
        set new.u = u
        set new.t = t
        set U[count] = u
        set B[count] = new
        set count = count + 1
        return new
    endmethod

    method move takes real a returns nothing
        set this.t = this.t - a
    endmethod

endstruct

function createBomb takes unit u, real t returns nothing
    local bomb new = bomb.create(u,t)
endfunction

function moveBomb takes unit u, real a returns nothing
    local integer i = 0
    local integer h
     loop
      exitwhen i>=count
      if (U[i]==u) then
                set h = i
                endif
     endloop
    call B[h].move(a)
endfunction

 

[Cokemonkey11]

Yep, that will work (if you fix the part where you forgot to set i=i+1 in the loop and fix a couple small syntax errors), but your moveBomb method could actually look like this:

local integer i=o
local integer h=-1
local bomb temp
loop
    exitwhen i>=bomb.count
    set temp=bomb.B[i]
    if temp.u==u then
        set h=i
    endif
    set i=i+1
endloop
if h!=-1 then
    call bomb.B[h].move(a)
debug else
    debug call DisplayTextToPlayer(GetLocalPlayer(),0.,0.,"Attempted to move a non-existant instance of 'bomb'!")
endif

In this way, you don't need static unit array U.

 

[KnnO]

Yes just exactly what I though, I could make h initial value = -1 which means no unit..
(I forgot about increasing i in the loop, again)

And about the var <u> I forgot to use it to find the unit through it, maybe because I'm still thinking about stuff like in GUI..
Thank you

(I didn't know the debug pretext, it will be so useful)

 

[Fingolfin]

3. Your move method should say set this.t = this.t - a. the term .t refers to a static variable, so that's not what you want (and same with .a).

This is wrong.
"this.t" and ".t" will have exactly the same output: the postprocessor automatically adds "this" before every dot operator where it is missing, so personally i perfer to omnit it to keep my code clean.

"thistype" however is replaced by the struct name and is used to reference static members. You can ofcourse use the struct name instead, but i perfer "thistype" because it allows you to change the struct name as you work without having to change all references to it inside it's methods.

 

[Cokemonkey11]

This is wrong.
"this.t" and ".t" will have exactly the same output: the postprocessor automatically adds "this" before every dot operator where it is missing, so personally i perfer to omnit it to keep my code clean.

"thistype" however is replaced by the struct name and is used to reference static members. You can ofcourse use the struct name instead, but i perfer "thistype" because it allows you to change the struct name as you work without having to change all references to it inside it's methods.

Not exactly, you should test this yourself. .t will reference static members perfectly fine. But you're right, writing this.t or thistype.t is better practice.

 

[KnnO]

Your avatar

This is wrong.
"this.t" and ".t" will have exactly the same output: the postprocessor automatically adds "this" before every dot operator where it is missing, so personally i perfer to omnit it to keep my code clean.

"thistype" however is replaced by the struct name and is used to reference static members. You can ofcourse use the struct name instead, but i perfer "thistype" because it allows you to change the struct name as you work without having to change all references to it inside it's methods.

You are right about the usage of thistype. so I can change the struct name, but I remember I tested it before, cokemonkey is right..

* Notices your avatar - wondering *

 

[Cokemonkey11]

* Notices your avatar - wondering *

He's not trolling. Technically JassHelper probably should do it the way he said.

 

[Troll-Brain]

Actually i think there is a tag available in jasshelper.conf to handle this behavior.

//To disable implicit usage of members and methods, (not requiring this. ) add:
// a line containing: [noimplicitthis]

However i've never tested it.
I just know that you have to edit the jasshelper in the JNGP folder and not the one in the subfolder "jasshelper" if you're using jasshelper through the JNGP (most likely).

// Default jasshelper.conf for newgen pack, notice that in this setup grimoire's main folder is jasshelper's work folder (.)

I really find ugly to completely omit "this./thistype."
Because then you can easily mix up with local/global variables and method arguments.
Only use ".member/method" without "this/thistype" is at least more clear, but should be probably never allowed in the very first time.

 

[KnnO]

Thanks for the information, Troll-Brain
I never tried to see what is inside JNGP folders.
I sometimes don't use "this./thistype." in some cases when the code is simple, it just depends on the code I am working on

 

[Troll-Brain]

It shoudn't matter if it's complex or simple as hell.
It's just a better practice and less error prone to always use this./thistype.
However nothing forbids you to omit them, i'm just trying to explain why sometimes more verbosity is better rather than implicit not obvious stuff.

 

[Fingolfin]

I disagree.

Personally, i use "thistype" whenever i want to access static members, and just "." when i want instance members. Having a ton of "this" cluttered all over the screen just distracts you from what is important in your code. It also makes some lines unneccesarily long. You should not be mixing anything up since the dot is easy enough to see.

 

[Troll-Brain]

Well, i stated that using only "." was not that bad, but still worse than "this(type)."
Now, it's mostly only an opinion, not a fact.
However i think you will be agree with me that using implicit "this(type)." is misleading.

And yes i forgot to say that it's important to be consistent, once you've make your choice keep and apply it everywhere.

 

[Cokemonkey11]

I disagree.

Personally, i use "thistype" whenever i want to access static members, and just "." when i want instance members. Having a ton of "this" cluttered all over the screen just distracts you from what is important in your code. It also makes some lines unneccesarily long. You should not be mixing anything up since the dot is easy enough to see.

But you could just as easily do the opposite, always using this.x, and only replacing thistype.x with .x - that's why it's better practice to always use both this and thistype.

 

[Fingolfin]

But you could just as easily do the opposite, always using this.x, and only replacing thistype.x with .x - that's why it's better practice to always use both this and thistype.

Or you could omnit both. The reason i use thistype is because in older versions of jasshelper, you could not call static methods without it.
Compare the readability of this statement:

set this.x = this.x + (this.vel+this.acc) * Cos(this.ang*bj_DEGTORAD)
set this.y = this.y + (this.vel+this.acc) * Cos(this.ang*bj_DEGTORAD)

with this:

set .x = .x + (.vel+.acc) * Cos(.ang*bj_DEGTORAD)
set .y = .y + (.vel+.acc) * Cos(.ang*bj_DEGTORAD)

If you are doing vector operations, the difference in text ammount is even more significant.

If you can't keep track on what members are static and instanced, or even function parameters, you should consider naming them differently.


HINT: another pro is that you can skip the struct reference in static methods by naming the instance "this":

static method MyMethod takes nothing returns nothing
	//let's say we want to iterate through a linked list
	local thistype this = .first
	//this actually overwrittes the "this" prefix that jasshelper usually adds

	loop
		exitwhen this == 0
		//now we can reference the members of the picked instance like this:
		set .x = .x+.xspeed
		set .y = .y+.yspeed
		//
		set this = .next
	endloop
endmethod