Project NLFFG

[A-Man]

Can I be the "Idea-ist" of this group? No? Okay, anyway, so I only have one serious question to ask, Do you have a pen and paper ready? Is the Data Changing going to be changed in any way?
I mean like the Coding and such? if Not then I will join, if Yes I don't think I can join till I learn how to code.

( Considering Data Changing in LF2 isn't all that hard once you get used to it, I don't think NLFFG's Data Changing will be hard. )

Of course data changing is going to change. We want more mod-ability don't we? Well, we haven't decided whether the A-Engine will be used or will it be another engine (you guys will decide when I can show it), but if it is then:

A-Engine | LF2 General Comparison (Click to View)

A-Engine datachanging (a-engineering as called by @Dragon5 ) is often very analogous to LF2 (naturally, as LF2 was what insprired me to do this in the first place).
For example, here is a fairly basic frame in LF2:

DC-Code: <frame> 123 frame_name  pic: 1 wait: 2 state:3005 centerx: 39 centery: 79 next: 124 dvx: 10 dvy: -5  itr:     kind: 0 x: 0 y: 0 w: 100 h: 100 injury: 100 dvx: 30  itr_end:   <frame_end>

This is of state 3005 which gives the frame no shadows, and if used in a type:3 file, the ball will not fall by gravity. The ball also doesn't go to frame 10 when hit. But "state: 3005" doesn't really tell much about all of this, it just gives an object a bunch of preset properties.

A-Engine:

PYTHON-Code: [f=123] #frame name; not required as its just a comment |NOSHADOW|IGNOREGRAVITY|  img=1 delay=2 center=39,79 x_vel=10 y_acc=5  set_hitbox[x=0 y=0 w=100 h=100 damage=100 x_impact=30] [/f]

(Used a python lexer just to show comments)
Looks clearer I hope.
Instead of states, I let the a-engineers set the properties of their frames. Object types do not exist, and everything needs to be explicitly mentioned using "switches"; these statements surrounded by the "|" characters. There are 10s of these you can mix to give the frame or its components different properties. There exists tags with the name states (named "ai_states"), but these has to do with AI coding.

The 'goto=' tag (equivalent to LF2's "next:") is by default set to @current_frame+1 so that it can be left out in case one is working on a sequence of following frames.

'dvy:' in LF2 misleadingly accelerates the object up or down instead of set its value as a velocity; therefore the equivalent to it in the A-Engine would be "y_acc=" and not "y_vel=". Also, the A-Engine, by default at least, uses an upright y-axis for its coordinates; aka the coordinate system you use in the school's math class:


So to accelerate yourself up, you use y_acc=+5 and not dvy:-5 like LF2.

But in general it's very similar to LF2, and get's rid of the weird preset rules LF2 has. Don't worry ;), you will be able to help.

There are cases where A-Engine can get more verbose compared to LF2, especially when you try to implement a very specific thing in LF2, like hit_fa: chasing which you would achieve instead with the "track_target[]" frame component:

PYTHON-Code: [f=1] #Energy Ball 1 |IGNOREGRAVITY|NOSHADOW|NOBARS|  img=1 center=57,23 delay=2 goto=1  #store screen id of nearest object which isn't of your team and has an id less than 500  set_reg=$target, &get_nearest_obj{@id<500 && <DVZ_ME#2> != <DVZ_ME#3>}  track_target[ |FACEFORWARD| target_id=$target r_acc=2 max_r_vel=10 max_z_vel=3 ] [/f]

Of course this complexity pays off when you try to do something awesome and totally new, like maybe, use this component on a character to set up a z-targeting system ;D

I will try to show some stuff in a video or gifs this week.