Changing attackone mid-animation

[Piccolo]

Is there a way to change attackone in the middle of an animation ?

The idea is to create attacks that knock down one opponent only (and allow you to continue your combo on the opponents still on their feet). To do that, I thought of using two consecutive attackboxes the first with knockdown power and attackone, and the second without both knockdown power and attackone. But attackone seems to apply on the whole animation.

As a workaround, I split these animations into two (one with the first attackbox, the other with the second), the first animation automatically chaining into the second. But it seems a bit clumsy to use that workaround on every animation that needs this behavior.

Any better suggestion ?

Thanks.

 

[Shaybe]

When you say attack1 is applying to the whole animation... I think I might know what you are saying. Have you tried putting something like this at the next frame
Attack1 0 0 0 0 0
I actually think one zero is enough to clear it, anyway this should clear out attack1 and it won't be able to hit anything else after that frame

 

[Piccolo]

No sorry, here I am referring to attackone which is different than attack1. The former does not create a new attackbox but tells how attackboxes will work. Here's what the manual says about that particular command :

attackone {bi}

~This command sets attackboxes's ability in the animation to hit other opponent.
0 = attackboxes can hit all opponents. This is default setting for all animations but grabattacks
1 = attackboxes can only hit one opponent. This is default setting for all grabattacks.

Thanks for answering though.

 

[O Ilusionista]

I don't know if you can do this, because we don't have a complete list of all Openborconst nowere, but try it:

changeentityproperty(self, openborconstant("ATTACKONE"), 0);

Come on Coders, we need the info to work with

 

[Bloodbane]

You know changing attackone in middle of animation is kinda odd IMO but I have no objection if someone would want to hardcode this feature in engine.

Anyways, a workaround I have in mind is to spawn invisible entity which works as the other attack. This entity doesn't have attackone set allowing it hit multiple opponents

 

[Piccolo]

I don't know if you can do this, because we don't have a complete list of all Openborconst nowere, but try it:

changeentityproperty(self, openborconstant("ATTACKONE"), 0);

Nope, from what I checked there is no way to change attackone like this, or else it is named differently in openbor code.

You know changing attackone in middle of animation is kinda odd IMO but I have no objection if someone would want to hardcode this feature in engine.

Anyways, a workaround I have in mind is to spawn invisible entity which works as the other attack. This entity doesn't have attackone set allowing it hit multiple opponents

Yeah it's kinda odd to use attackone for this, but I think what I want to do makes sense. That is, some attacks, especially horizontal ones, knock down the first entity hit and damage the others. In other words, I try to replicate the momentum loss after hitting an obstacle : attack force is weakened and might no longer be sufficient to break/knock down another obstacle.

Attackone is not the only way to do this, but apperead somewhat approriate.

Anyways thanks for your workaround, might be better than mine 

 

[O Ilusionista]

You know changing attackone in middle of animation is kinda odd

Its not odd and, if you think again, its more logical to be able to do it then not be able. Other engines, like Mugen and FM, can do it frame-based if we want to.
its like followcond, which can be aplied only one time when we should be able to apply it many times without needing to split the animation.

Nope, from what I checked there is no way to change attackone like this, or else it is named differently in openbor code.

Sorry, at least I tried

 

[DCurrent]

You know changing attackone in middle of animation is kinda odd

Its not odd and, if you think again, its more logical to be able to do it then not be able. Other engines, like Mugen and FM, can do it frame-based if we want to.
its like followcond, which can be aplied only one time when we should be able to apply it many times without needing to split the animation.

In OpenBOR, frame level flags are intentionally avoided at all costs.

The reason for this is that memory management is much more important in OpenBOR than it is in Mugen. Remember that every flag requires a variable of some sort, and those variables take up space whether they are used or not. If you have 50 animations, then you have 50 copies of an animation level flag. Now take it to frame level. If every animation was 5 frames each, you're talking about 250 integer variables. For a SINGLE model. And all but maybe 2 or 3 are doing nothing useful.

In a Mugen type engine, you can get away with that sort of waste because A) you generally have just two large models to deal with and B) you're in a PC environment, so there's going to be plenty of RAM to spare.

In an OpenBOR environment, you've got 20-30 active models at any given time in the most modest of modules. So again, the multiplying factor comes in. Let's say just 20 models with 20 animations each, at 5 frames a piece; all very low estimates. That means just one frame flag requires 2000 copies, amounting to ~4KB of RAM. All for one lousy flag. Now recall, OpenBOR is a poly-platform application. When you're dealing with the 16MB Dreamcast or 32MB PSP, it's paramount to have stingy memory management. That's why OpenBOR's default behavior is so geared toward self optimizing (sprite database, auto trimming, clearing of non active entities, and so on).

For these reasons development is geared towards the script engine rather than more pet rocks. It allows the author to decide when and where resources will be allocated instead of forcing bloat on them that goes untouched 99% of the time. If an author wants to create a 6GB super mod that only new PCs can run, that's his choice. If he wants to make something simple for the DC, then the engine must accommodate and not hog memory with unused functionality.

There is give and take of course, but in most cases tiny additions like this will always be relegated to script. For instance; I am working on universal animation and frame flags that can be set and detected with script - then acted on accordingly. So instead of several specialized flags, you get a single user definable flag with infinite possibilities and everybody wins.

DC

 

[O Ilusionista]

I am working on universal animation and frame flags that can be set and detected with script - then acted on accordingly. So instead of several specialized flags, you get a single user definable flag with infinite possibilities and everybody wins.

That sounds cool.

about the constant list, any clue?

"background",
"blockade",
"branchname",
"count_enemies",
"count_entities",
"count_npcs",
"count_players",
"current_branch",
"current_level",
"current_palette",
"current_scene",
"current_set",
"current_stage",
"effectvol",
"elapsed_time",
"ent_max",
"freeram",
"game_paused",
"game_speed",
"gfx_x_offset",
"gfx_y_offset",
"gfx_y_offset_adj",
"hResolution",
"in_cheat_options",
"in_control_options",
"in_gameoverscreen",
"in_halloffamescreen",
"in_level",
"in_load_game",
"in_menuscreen",
"in_new_game",
"in_options",
"in_selectscreen",
"in_showcomplete",
"in_sound_options",
"in_start_game",
"in_system_options",
"in_titlescreen",
"in_video_options",
"lasthita",
"lasthitc",
"lasthitt",
"lasthitx",
"lasthitz",
"levelheight",
"levelpos",
"levelwidth",
"lightx",
"lightz",
"maxanimations",
"maxattacktypes",
"maxentityvars",
"maxglobalvars",
"maxindexedvars",
"maxplayers",
"maxscriptvars",
"models_cached",
"models_loaded",
"musicvol",
"nofadeout",
"nojoin",
"nopause",
"nosave",
"noscreenshot",
"numpalettes",
"pakname",
"pause",
"pixelformat",
"player",
"player1",
"player2",
"player3",
"player4",
"player_max_z",
"player_min_z",
"sample_play_id",
"scrollmaxx",
"scrollmaxz",
"scrollminx",
"scrollminz",
"self",
"shadowalpha",
"shadowcolor",
"skiptoset",
"slowmotion",
"slowmotion_duration",
"smartbomber",
"soundvol",
"textbox",
"ticks",
"totalram",
"usedram",
"vResolution",
"viewporth",
"viewportw",
"viewportx",
"viewporty",
"vscreen",
"waiting",
"xpos",
"ypos",