Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Simulator Enhancements (03/13/24)

Pages: 1 ... 9 10 [11] 12 13 ... 706

Author Topic: Misc modding questions that are too minor to warrant their own thread  (Read 1700657 times)

silentstormpt

  • Admiral
  • *****
  • Posts: 1060
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #150 on: January 20, 2013, 12:49:38 PM »

and actually its making it spinning instead of crushing into the hull (it doesnt matter if it does do that, we are the borg, we couldnt care less what happens to your puny ships), i had one ship destroyed while under its effect that it literally got falcon punched out of the combat zone while spinning at a astronomical rate

Code
velocity.set(velocity.x + (direction.x * strength * amount), velocity.y + (direction.y * strength * 100f));

Why is the y velocity change being multiplied by 100 instead of amount? Since amount will usually be about 0.016, that's a significant difference in power. ;) That might be why it's spinning (the AI trying to compensate for being shoved aside).



ops, i was testing something, its already amount on my side not 100f, heh

Its a nice Master of Orion 2 Gyro copy perse

---

EDIT: with the ship mass vs target mass, seems to hold the enemy ship in place, still spins a little if it tries to move away (expected) but doesnt pull

EDIT 2: Also noticed that i cant change the width of the beam depending on the targets size, theres no API support for it ex:
Spoiler
[close]
« Last Edit: January 20, 2013, 01:16:57 PM by silentstormpt »
Logged

Romeo_One

  • Captain
  • ****
  • Posts: 393
  • "Let me do the german dance for you..."
    • View Profile
    • Rejection - The Fight for Unity
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #151 on: January 21, 2013, 06:44:45 AM »

Ok, is it possible that the current build can't use additional backgrounds?

Turns out when you are in dev mode changes to the background appearently get scrapped. Weird.
« Last Edit: January 21, 2013, 06:48:19 AM by Romeo_One »
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23988
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #152 on: January 21, 2013, 09:57:14 AM »

Ok, is it possible that the current build can't use additional backgrounds?

Turns out when you are in dev mode changes to the background appearently get scrapped. Weird.

Yeah - reason is to speed up combat loading, as - due to its size - the background is the one thing that isn't just loaded on startup, and is actually loaded from disk whenever it needs to change. A matter of a few seconds, but those add up to quite an annoyance when you're doing it all the time :)
Logged

Romeo_One

  • Captain
  • ****
  • Posts: 393
  • "Let me do the german dance for you..."
    • View Profile
    • Rejection - The Fight for Unity
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #153 on: January 21, 2013, 10:15:55 AM »

Yeah I thought so, was really confused at first though :)
Logged

Nekora

  • Ensign
  • *
  • Posts: 28
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #154 on: January 22, 2013, 04:54:43 AM »

Regarding the spawnEmpArc() the notes say that you can target this to a specific location by passing in a custom class as the combatentity target: "@param empTargetEntity Target of the EMP arc. If it's a ship, it will randomly pick an engine nozzle/weapon to arc to. Can also pass in a custom class implementing CombatEntityAPI to visually target the EMP at a specific location (and not do any damage)."

Does anyone know a way to do this?

I was thinking allong the lines of useing addSmoothParticle(beam.getTo(), target.getVelocity(), 1f, 0f, .5f, CORE_COLOR); to create a teporary entity to target but couldnt get this to work >_<

Logged

Erick Doe

  • Global Moderator
  • Admiral
  • *****
  • Posts: 2489
  • "Pretty cunning, don't you think?"
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #155 on: January 22, 2013, 05:14:21 AM »

Got an issue I've not been able to solve, and it has made editing ships harder since I can't use Trybolot's ship editor.

Here's the thing. I had to add in custom engines manually for the ships. I found it easier to edit the hull files manually after changing the layout of the hull text from:

Spoiler
[close]

to

Spoiler
[close]

Unfortunately, I don't know how to change back the layout without manually changing every little thing. Because while Starsector has no problem with my new layout, Trybolot's ship editor does.

Any help would be appreciated.

http://fractalsoftworks.com/forum/index.php?topic=2381.450
« Last Edit: January 22, 2013, 05:48:15 AM by Erick Doe »
Logged

Sproginator

  • Admiral
  • *****
  • Posts: 3592
  • Forum Ancient
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #156 on: January 22, 2013, 05:47:41 AM »

Posted a reply on your original topic
Logged
A person who's never made a mistake, never tried anything new
- Albert Einstein

As long as we don't quit, we haven't failed
- Jamie Fristrom (Programmer for Spiderman2 & Lead Developer for Energy Hook)

Cycerin

  • Admiral
  • *****
  • Posts: 1665
  • beyond the infinite void
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #157 on: January 22, 2013, 02:38:00 PM »

Me and EnderNerdcore have been trying to refine the Burst Maneuvering Jets system for a while now. It's currently the major thing preventing me from releasing a new Blackrock version. At this point, it works a lot like intended, except the system tries to bump you in a "straight east/west/north/south" direction if you use it while travelling diagonally at any decent speed. It seems like it has trouble clamping in the correct way... if that makes any sense.

The goal is still to give the ship a short, elegant burst of speed like a fish moving underwater. I half suspect that a lot of the current trouble is due to messing around with deceleration to prevent the ship from being able to change direction in a sudden jerk mid-burst, and endless attempts to get the clamping right to take the boost smoothly from full effect down to normal max speed.

Code:
Code
package data.shipsystems.scripts;

import com.fs.starfarer.api.combat.MutableShipStatsAPI;
import com.fs.starfarer.api.plugins.ShipSystemStatsScript;
import com.fs.starfarer.api.combat.CombatEntityAPI;
import com.fs.starfarer.api.combat.ShipAPI;
import com.fs.starfarer.api.combat.CombatEngineAPI;
import data.scripts.plugins.CombatUtils;
import java.lang.Math;

public class DesdinovaBurstJetsStats implements ShipSystemStatsScript {

        public CombatEntityAPI ourShip;
        public ShipAPI ship;
        public CombatEngineAPI engine;
        CombatUtils utility = new CombatUtils();
        public Math math;
       
public void apply(MutableShipStatsAPI stats, String id, State state, float effectLevel) {
                ourShip = stats.getEntity();
                boolean fluxIsAtZero = false;               
                ship = utility.getOwner(stats);
                if (ship != null) {
                    if (ship.getFluxTracker().getFluxLevel() == 0f) { fluxIsAtZero = true; }
                }
if (state == ShipSystemStatsScript.State.OUT) {
                        if (effectLevel < 1f) {
                            stats.getMaxSpeed().modifyFlat(id, (effectLevel)*stats.getMaxSpeed().getModifiedValue()); // to slow down ship to its regular top speed while powering drive down
                            stats.getDeceleration().unmodify(id);
                           
                            //start clamping our Y velocity
                            if (ourShip.getVelocity().getY() > stats.getMaxSpeed().getBaseValue() && !fluxIsAtZero) {
                                ourShip.getVelocity().set(ourShip.getVelocity().getX(), (stats.getMaxSpeed().getModifiedValue()));
                            } else if (ourShip.getVelocity().getY() > stats.getMaxSpeed().getBaseValue() && fluxIsAtZero) {
                                ourShip.getVelocity().set(ourShip.getVelocity().getX(), (50f + stats.getMaxSpeed().getModifiedValue()));
                            }
                           
                            //start clamping our X velocity
                            if (math.abs(ourShip.getVelocity().getX()) > stats.getMaxSpeed().getBaseValue() && !fluxIsAtZero) {
                                if (ourShip.getVelocity().getX() > 0f) {
                                    ourShip.getVelocity().set((stats.getMaxSpeed().getModifiedValue()), ourShip.getVelocity().getY());
                                } else if (ourShip.getVelocity().getX() < 0f) {
                                    ourShip.getVelocity().set((-1.0f * stats.getMaxSpeed().getModifiedValue()), ourShip.getVelocity().getY());
                                }
                            } else if (math.abs(ourShip.getVelocity().getX()) > stats.getMaxSpeed().getBaseValue() && fluxIsAtZero) {
                                if (ourShip.getVelocity().getX() > 0f) {
                                ourShip.getVelocity().set((50f + stats.getMaxSpeed().getModifiedValue()), ourShip.getVelocity().getY());
                                } else if (ourShip.getVelocity().getX() < 0f) {
                                    ourShip.getVelocity().set((-1.0f * stats.getMaxSpeed().getModifiedValue() - 50f), ourShip.getVelocity().getY());
                                }
                               
                            }
                        }
} else  {
                        stats.getMaxSpeed().modifyFlat(id, 200f);
stats.getAcceleration().modifyFlat(id, 600f * effectLevel);
stats.getDeceleration().modifyMult(id, 0.2f);
stats.getTurnAcceleration().modifyFlat(id, 90f * effectLevel);
stats.getTurnAcceleration().modifyPercent(id, 200f * effectLevel);
stats.getMaxTurnRate().modifyMult(id, 2f * effectLevel);
stats.getMaxTurnRate().modifyPercent(id, 130f * effectLevel);
                }

}
public void unapply(MutableShipStatsAPI stats, String id) {
                stats.getMaxSpeed().unmodify(id); // to slow down ship to its regular top speed while powering drive down
                stats.getMaxTurnRate().unmodify(id);
                stats.getDeceleration().unmodify(id);
                stats.getMaxSpeed().unmodify(id);
                stats.getMaxTurnRate().unmodify(id);
                stats.getTurnAcceleration().unmodify(id);
                stats.getAcceleration().unmodify(id);
                stats.getDeceleration().unmodify(id);
                ourShip = stats.getEntity();
                boolean fluxIsAtZero = false;
                ship = utility.getOwner(stats);
                if (ship != null) {
                    if (ship.getFluxTracker().getFluxLevel() == 0f) { fluxIsAtZero = true; }
                }               
                if (ourShip.getVelocity().getY() >= stats.getMaxSpeed().getBaseValue() && !fluxIsAtZero) {
                    ourShip.getVelocity().set(ourShip.getVelocity().getX(), stats.getMaxSpeed().getBaseValue());
                } else if (ourShip.getVelocity().getY() >= stats.getMaxSpeed().getBaseValue() && fluxIsAtZero) {
                    ourShip.getVelocity().set(ourShip.getVelocity().getX(), (stats.getMaxSpeed().getBaseValue() + 50.0f));
                }
                if (math.abs(ourShip.getVelocity().getX()) >= stats.getMaxSpeed().getBaseValue() && !fluxIsAtZero) {
                    if (ourShip.getVelocity().getX() > 0) {
                        ourShip.getVelocity().set(stats.getMaxSpeed().getBaseValue(), ourShip.getVelocity().getY());
                    } else if (ourShip.getVelocity().getX() < 0) {
                        ourShip.getVelocity().set(-1.0f * stats.getMaxSpeed().getBaseValue(), ourShip.getVelocity().getY());
                    }
                   
                } else if (math.abs(ourShip.getVelocity().getX()) >= (stats.getMaxSpeed().getBaseValue() + 50f) && fluxIsAtZero) {
                    if (ourShip.getVelocity().getX() > 0) {
                        ourShip.getVelocity().set((stats.getMaxSpeed().getBaseValue() + 50.0f), ourShip.getVelocity().getY());
                    } else if (ourShip.getVelocity().getX() < 0) {
                        ourShip.getVelocity().set((-1.0f * stats.getMaxSpeed().getBaseValue() - 50.0f), ourShip.getVelocity().getY());
                    }
                }
               
}

public StatusData getStatusData(int index, State state, float effectLevel) {
if (index == 0) {
return new StatusData("increased engine power", false);
} else if (index == 1) {
return new StatusData("cannot decelerate", false);
}
return null;
}
}

The CSV values for the system are 0.2 chargeup, 0.2 active, 1.1 out. No clamping in the .system file. Stacks with 0-flux boost.
Logged

EnderNerdcore

  • Commander
  • ***
  • Posts: 172
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #158 on: January 22, 2013, 03:08:09 PM »

(and yes, I realize my code there could be simplified a bit, but it shouldn't change the functionality ;))
Logged

Wyvern

  • Admiral
  • *****
  • Posts: 3786
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #159 on: January 22, 2013, 03:14:04 PM »

Cycerin: The issue there is that you're clamping X and Y independently of each other.  What you actually want to do is clamp speed, not velocity.x & velocity.y.

So, some psuedocode:
float speed = Math.sqrt( velocity.x * velocity.x + velocity.y * velocity.y );
float targetspeed = some calculation involving current speed, max speed, & deceleration - basically, what speed do you actually want to be going at right now.
float multiplier = targetspeed / speed;
velocity.x = velocity.x * multiplier;
velocity.y = velocity.y * multiplier;

You may also want to do some extra work with your fluxIsAtZero value & hard-coded zero-flux speed boost of 50 to account for possible skill perks (which can allow "zero flux" to persist up to 25% flux, and/or, cause the zero flux speed boost to be 75 instead of 50.)
Logged
Wyvern is 100% correct about the math.

EnderNerdcore

  • Commander
  • ***
  • Posts: 172
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #160 on: January 22, 2013, 03:47:56 PM »

Cycerin: The issue there is that you're clamping X and Y independently of each other.  What you actually want to do is clamp speed, not velocity.x & velocity.y.

So, some psuedocode:
float speed = Math.sqrt( velocity.x * velocity.x + velocity.y * velocity.y );
float targetspeed = some calculation involving current speed, max speed, & deceleration - basically, what speed do you actually want to be going at right now.
float multiplier = targetspeed / speed;
velocity.x = velocity.x * multiplier;
velocity.y = velocity.y * multiplier;

You may also want to do some extra work with your fluxIsAtZero value & hard-coded zero-flux speed boost of 50 to account for possible skill perks (which can allow "zero flux" to persist up to 25% flux, and/or, cause the zero flux speed boost to be 75 instead of 50.)
I'll reply since I wrote a lot of that code:

We tried some of that. The problem is that there is no direct code method to clamp speed itself (you can set maxSpeed but the game does not force the ship down to that if it is over that max speed and coasting, only if the player is actively holding a direction key), so you have to deal with the Vector2f velocity in some way.

So the issue isn't that it's not working--it is working--but rather that under some conditions (triggered with diagonal movement) there is a small "bump" in a cardinal direction near the end of the system working.

Part of the problem is that from what I can tell, Starsector uses the deceleration value of a ship to determine how fast it can change its velocity vector between the X and Y directions. (as a bit of explanation, in Starsector the velocity vector X is side-to-side movement relative to the ship's heading, and Y is forward-backward movement relative to the ship's heading). So, we drop the deceleration value to prevent players from slowing down rapidly in the Y direction (you can't move forward and then stop on a dime).

Good point about the skill perks though. If we can get this last "bump" figured out, I'll also update the code. Anyone know of an easy way to do this, or does it just involve calling some character skill functions?
Logged

Wyvern

  • Admiral
  • *****
  • Posts: 3786
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #161 on: January 22, 2013, 03:55:03 PM »

We tried some of that. The problem is that there is no direct code method to clamp speed itself (you can set maxSpeed but the game does not force the ship down to that if it is over that max speed and coasting, only if the player is actively holding a direction key), so you have to deal with the Vector2f velocity in some way.

Which is why I provided pseudocode to take a vector that's specified in x and y terms, and clamp by speed.  For example, if targetspeed in the pseudocode I provided ended up at 100, then - after setting velocity.x and velocity.y - the overall speed would be 100.  (Maybe because velocity was 100,0, or 0,100, or -70.71,70.71, or any other vector with a magnitude of 100, give or take small variations due to inaccuracies in floating point calculations.)

Edit: By comparison, if you clamp by X and Y separately, then, with a target speed of 100, you'd end up with maybe 100,0, or 100,100 - in other words, when moving diagonally, you'll end up going faster than if not moving diagonally.
« Last Edit: January 22, 2013, 03:56:37 PM by Wyvern »
Logged
Wyvern is 100% correct about the math.

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23988
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #162 on: January 22, 2013, 03:58:29 PM »

Part of the problem is that from what I can tell, Starsector uses the deceleration value of a ship to determine how fast it can change its velocity vector between the X and Y directions. (as a bit of explanation, in Starsector the velocity vector X is side-to-side movement relative to the ship's heading, and Y is forward-backward movement relative to the ship's heading). So, we drop the deceleration value to prevent players from slowing down rapidly in the Y direction (you can't move forward and then stop on a dime).

That may be the problem, then, because that's not true.

1) The velocity x and y are in absolute coordinates, not relative to the facing of the ship. x is left to right and y is down to up, just like on a math graph.

2) When you set those values directly, the ship's deceleration value doesn't play into it (nor does anything else - it's just set to whatever you set it to. Well, it'll also get clamped to 600 by the engine, but that's it.)
Logged

EnderNerdcore

  • Commander
  • ***
  • Posts: 172
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #163 on: January 22, 2013, 04:06:37 PM »

Part of the problem is that from what I can tell, Starsector uses the deceleration value of a ship to determine how fast it can change its velocity vector between the X and Y directions. (as a bit of explanation, in Starsector the velocity vector X is side-to-side movement relative to the ship's heading, and Y is forward-backward movement relative to the ship's heading). So, we drop the deceleration value to prevent players from slowing down rapidly in the Y direction (you can't move forward and then stop on a dime).

That may be the problem, then, because that's not true.

1) The velocity x and y are in absolute coordinates, not relative to the facing of the ship. x is left to right and y is down to up, just like on a math graph.

2) When you set those values directly, the ship's deceleration value doesn't play into it (nor does anything else - it's just set to whatever you set it to. Well, it'll also get clamped to 600 by the engine, but that's it.)
Oh, I know that about #2, which is exactly why we're doing it that way (to essentially set our own forced rapid deceleration). It seemed like this was having an influence on what was happening when the player changed which keys they were pressing during the operation of the system (such as going diagonally then switching to forward-only motion while the system was engaged).

#1 makes sense then. I had initially assumed it was in polar coordinates (angle, magnitude) but testing showed that that wasn't true. I'm not sure if that actually changes how this system works, though, since it never takes facing into account...
Logged

EnderNerdcore

  • Commander
  • ***
  • Posts: 172
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #164 on: January 22, 2013, 04:08:44 PM »

We tried some of that. The problem is that there is no direct code method to clamp speed itself (you can set maxSpeed but the game does not force the ship down to that if it is over that max speed and coasting, only if the player is actively holding a direction key), so you have to deal with the Vector2f velocity in some way.

Which is why I provided pseudocode to take a vector that's specified in x and y terms, and clamp by speed.  For example, if targetspeed in the pseudocode I provided ended up at 100, then - after setting velocity.x and velocity.y - the overall speed would be 100.  (Maybe because velocity was 100,0, or 0,100, or -70.71,70.71, or any other vector with a magnitude of 100, give or take small variations due to inaccuracies in floating point calculations.)

Edit: By comparison, if you clamp by X and Y separately, then, with a target speed of 100, you'd end up with maybe 100,0, or 100,100 - in other words, when moving diagonally, you'll end up going faster than if not moving diagonally.
Got it. While that shouldn't matter too much for our forced-deceleration clamping (it may have an effect, but it will be small), that actually might be what is wrong with our end-of-system capping (as opposed to clamping) where we make sure that the ship isn't moving faster than it should be. That actually would explain the cardinal-direction "bump".

Oversight on my part. Rusty java skills + smoking weed while doing vector calculations made me completely overlook the fact that we could end up with too much magnitude of velocity.


Now, if only velocity was being expressed in polar coordinates...
« Last Edit: January 22, 2013, 04:21:10 PM by EnderNerdcore »
Logged
Pages: 1 ... 9 10 [11] 12 13 ... 706