LF2 GM Progress Thread

[Bamboori]

okay, im currently rewriting template.dat.

original frame 0:

DC-Code: <frame> 0 standing pic: 0 state: 0 wait: 3 next: 1 dvx: 0 dvy: 0 centerx: 39 centery: 79 hit_a: 0 hit_d: 0 hit_j: 0 wpoint: kind: 1 x: 33 y: 45 weaponact: 21 attacking: 0 cover: 0 dvx: 0 dvy: 0 dvz: 0 wpoint_end: bdy: kind: 0 x: 21 y: 18 w: 43 h: 62 bdy_end: <frame_end>

new frame 0:

Code:

case 0: //standing
    {
        pic=0  state=0  wait(4)  next=1  dvx=0   dvy=0   dvz=0   centerx=39  centery=79
        wpoint(1,33,45,21,0,0,0,0,0)
        bdy(0,21,18,43,62)
    }

the wait has to be a function for my scripting to work. i could redo every variable from the top row into a function, would that be better?
and is it okay to have less self-explaining code? wpoint has all the code from the original, just... well compressed id say.

[STM1993]

the wait has to be a function for my scripting to work. i could redo every variable from the top row into a function, would that be better?
and is it okay to have less self-explaining code? wpoint has all the code from the original, just... well compressed id say.

Well, I have no idea about functions, but for the new code format you mentioned, I like it. Its much neater and you won't forget any elements, all you need is just one simple readme that mentions which number means what.

[Dragon5]

I say make them functions. The data would look more consistent that way.
I'm curious to see how opoint will work though. I doubt ID numbers work well for this.

Edit: I do admit it may seem confusing to have some parts of the data bunched without meaning, but as long as there's a tutorial it should be fine.

[Bamboori]

havent really thought about the opoint yet tbh, but i guess using the actual object name would suffice. (in game maker every object gets a name)

[Bamboori]

another question guys.
the itr needs different variables depending on the kind. would you rather like one itr function with varying variables or a function for each itr kind?

currently it is only one function for all itr kinds:

itr kind 1:
itr(1,40,16,25,65,120,120,130,130)
itr kind 0:
itr(0,49,33,30,16,2,0,0,12,16,0,0,20,0,0)

[AmadisLFE]

Bamboori, I don't really know, but it might be, you might need to use different variables for each of them, I am not really a master programmer, so thats why Idk, I am still taking tutorials, its hard, but its fun to learn something new than just sitting like a sitting duck.I think I brought something else in. *DERP*, okay well, uh, good luck. *DERP*

[Bamboori]

what exactly do you mean? the first variable in brackets defines the kind, and dependant on that the rest of the variables are for different things.

[A-Man]

I liked that syntax! Would be really legit if you can have "if" and "for" looping in the frames! As for the functions, I have no idea how stuff works for GM, but try looking into Named Parameters. Here is an example of that with Python:

Code:

def itr( **args):
    if args.has_key( "x:" ):
        assignto_x(args["x:"])
    else:
        assignto_x(defaultxvalue)
    if args.has_key( "y:" ):
        assignto_y(args["y:"])
    else:
        assignto_y(defaultyvalue)
    if args.has_key( "w:" ):
        assignto_w(args["w:"])
    else:
        assignto_w(defaultwvalue)
    if args.has_key( "h:" ):
        assignto_h(args["h:"])
    else:
        assignto_h(defaulthvalue)
    return

then you can do:

Code:

itr(y=10, x=3, w=30, h=20)

That will not only make it more flexible for coders to give the paras in any order, but will also allow them to leave out the unnecessary tags as well. In your case, the coder will have to fill everything and with order; which won't be very efficient when you come to add your own tags.
Edit: No one line code tag O:

[Bamboori]

that is mighty interesting!
using strings as arguments should work, so it would look like this:

itr("kind=0", "x=1", "y=2", "w=4","h=2") and so on.

[A-Man]

that is mighty interesting!
using strings as arguments should work, so it would look like this:

itr("kind=0", "x=1", "y=2", "w=4","h=2") and so on.

I thought about that. What I thought was cool with your approach is that you're using the actual GM script to do the frames. Doing what you said would get you back to parsing. Doing that would destroy all the possibilities to have this (point number 4). Well, unless you're planning to have that stuff parsed as well which would be kinda harder and more memory consuming.
Keep this up!