※ Danmakufu Q&A/Problem thread 3 ※

~Hakurei Shrine~ > Rika and Nitori's Garage Experiments

<< < (5/366) > >>

Random Sphere:
I want the homing bullets like Reimu?s ones, but less accurate.

Helepolis:
I am afraid my knowledge lacks on that part :ohdear: and hopefully someone else can come help out .

A question to the people who've been building full fledged games with menu system and everything: Did you manage to successfully implement a continue system?

As far as my research, testing and analysing other full fan games such as well known MPP, RSS and BSM, I have to conclude it is impossible to build a continue system using the functions ph3 offers. Things like GetStageSceneState cannot be called from a Stage Script and GetPlayerState cannot be called outside a Stage Script.

Even thinking of certain detours results in a dead-end. At least, that is my personal conclusion.

So I am curious if anybody successfully managed to achieve this and what did you use to avoid the StageSceneState or PlayerState from going to DED. (As you can't alter playerstate with any function)

Sparen:

--- Quote from: Helepolis on February 14, 2016, 07:19:24 PM ---
--- End quote ---

My continue system is an absolute mess, but I got it to work. It depends on NotifyEvents and CommonData.

In @Event, I use

--- Code: --- case(EV_PLAYER_SHOOTDOWN){//To disable continue system, block comment this case.
if(GetPlayerLife<0){
SetPlayerLife(0.123); //from Arby26
ContinueSystem;
}
}
--- End code ---
By setting the player life to be above 0, you prevent the script from ending. My Continue System task handles communication with the package - if the player has continues left and it's not a replay, the package is notified to Pause the Stage. From here, the player decides in the package which course they would like to take, and the stage is notified from the package via NotifyEvent.

Lollipop:

--- Quote from: Sphe on February 14, 2016, 10:52:39 AM ---I want the homing bullets like Reimu?s ones, but less accurate.

--- End quote ---

I assume something like this would work:

--- Code: ---loop{
let dir = atan2(GetPlayerY-ObjMove_GetY(obj),GetPlayerX-ObjMove_GetX(obj));
ObjMove_SetAngle(obj,dir);
yield;
}

--- End code ---

If you wanted it to be less accurate, there are two ways to go about this. (i think)

1. Have the angle change less frequently

--- Code: ---loop{
let dir = atan2(GetPlayerY-ObjMove_GetY(obj),GetPlayerX-ObjMove_GetX(obj));
ObjMove_SetAngle(obj,dir);
loop(n){yield;} // where n is a variable
}

--- End code ---

2. Have the angle be slightly off

--- Code: ---loop{
let dir = atan2(GetPlayerY-ObjMove_GetY(obj),GetPlayerX-ObjMove_GetX(obj));
ObjMove_SetAngle(obj,dir+rand(-1,1));
yield;
}

--- End code ---

Or you could do both.

I hope this helps.

Drake:
Rather than changing less frequently, many (most?) dynamic "soft" homing implementations will change a set amount towards the direction of e.g. the player.

--- Code: ---task homing_test{
let obj = CreateShotA1(192, 150, 4, 90, 77, 20);
let speed = 4;
let a = 90;
let a_spd = 5; // rate of angle change
while(!Obj_IsDeleted(obj)){
let angle_to = GetAngleToPlayer(obj);

// choose to increase or decrease angle depending on which is closer
let da = [a_spd, -a_spd][((a - angle_to) % 360) < 180];

// if the angles are close enough, just snap instead
if( (|a - angle_to|) < a_spd){
a = angle_to;
}else{
a = (a + da) % 360;
}

ObjMove_SetAngle(obj, a);

// optionally scale speed so it slows down to adjust angle
let scale = (|(a - angle_to) % 360 - 180|) / 180; // ranges [0,1]; is 1 when angles are equal
ObjMove_SetSpeed(obj, speed * scale^2); // squaring also optional, increases slowdown
yield;
}
}

--- End code ---

Navigation

 Message Index

Go to full version