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: New music for Galatia Academy (06/12/24)

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - tomatopaste

Pages: 1 ... 17 18 [19] 20
271

Thanks for the help earlier, I'm currently fine-tuning the drone movement, and I was wondering how the param of Ship.giveCommand(..., param, ...) works. I've only been setting the param as null, but the API mentions param - Generally a Vector2f with a "mouse" location. See ShipCommand.java for details., but as far as I can see ShipCommand.java doesn't have any comment on a mouse location. Does this mean that I can choose to make the e.g. accelerate command act in a certain direction instead of cardinally? The code below shows what I have. This is quite innacurate as the drones only move diagonally or straight, which causes them to overshoot, correct, then fly around amusingly. Thanks!

"param" is for commands that need a mouse location, such as firing a weapon (missiles uses this for target-picking), using a ship system, or raising shields.

That's a bummer. Is there another way that I could increase the accuracy of the ship acceleration then? Does the source (which I am more or less trying to imitate in behaviour) liberally use intervalutil?

272
Thanks for the help earlier, I'm currently fine-tuning the drone movement, and I was wondering how the param of Ship.giveCommand(..., param, ...) works. I've only been setting the param as null, but the API mentions param - Generally a Vector2f with a "mouse" location. See ShipCommand.java for details., but as far as I can see ShipCommand.java doesn't have any comment on a mouse location. Does this mean that I can choose to make the e.g. accelerate command act in a certain direction instead of cardinally? The code below shows what I have. This is quite innacurate as the drones only move diagonally or straight, which causes them to overshoot, correct, then fly around amusingly. Thanks!
Spoiler
Code
//MOVE TO TARGET LOCATION
        float angleFromDroneToTargetLocation = VectorUtils.getAngleStrict(drone.getLocation(), movementTargetLocationOnShip);
        float angleRelativeToDrone = MathUtils.getShortestRotation(drone.getFacing(), angleFromDroneToTargetLocation);
        float distanceToTargetLocation = MathUtils.getDistance(drone.getLocation(), movementTargetLocationOnShip);

        //do large movement if over distance threshold
        if (distanceToTargetLocation >= roamRange) {
            //accelerate forwards or backwards
            if (90f > angleRelativeToDrone && angleRelativeToDrone > -90f) { //between 90 and -90 is an acute angle therefore in front
                drone.giveCommand(ShipCommand.ACCELERATE, null, 0);
                drone.giveCommand(ShipCommand.ACCELERATE, null, 0);
                drone.giveCommand(ShipCommand.ACCELERATE, null, 0);
            } else { //falls between 90 to 180 or -90 to -180, which should be obtuse and thus relatively behind
                drone.giveCommand(ShipCommand.ACCELERATE_BACKWARDS, null, 0);
            }

            //strafe left or right
            if (180f > angleRelativeToDrone && angleRelativeToDrone > 0f) { //between 0 and 180 (i.e. left)
                drone.giveCommand(ShipCommand.STRAFE_LEFT, null, 0);
            } else { //between 0 and -180 (i.e. right)
                drone.giveCommand(ShipCommand.STRAFE_RIGHT, null, 0);
            }
        } else {
            snapTo(ship, 0.1f, drone, movementTargetLocationOnShip);
        }

        //some fine tuning and deceleration
        if (distanceToTargetLocation <= roamRange * 2f) {
            drone.giveCommand(ShipCommand.DECELERATE, null, 0);

            if (tracker.intervalElapsed()) {
                //decelerate if close to target location or attempt to reverse thrust
                if (distanceToTargetLocation <= roamRange) {
                    drone.giveCommand(ShipCommand.DECELERATE, null, 0);
                    if (drone.getEngineController().isStrafingRight()) {
                        drone.giveCommand(ShipCommand.STRAFE_LEFT, null, 0);
                    }
                    if (drone.getEngineController().isStrafingLeft()) {
                        drone.giveCommand(ShipCommand.STRAFE_RIGHT, null, 0);
                    }
                    if (drone.getEngineController().isAccelerating()) {
                        drone.giveCommand(ShipCommand.ACCELERATE_BACKWARDS, null, 0);
                    }
                    if (drone.getEngineController().isAcceleratingBackwards()) {
                        drone.giveCommand(ShipCommand.ACCELERATE, null, 0);
                    }
                }
            }
        }
[close]

273
Trying to implement a custom drone AI with
Quote
@Override
    public PluginPick<ShipAIPlugin> pickDroneAI(ShipAPI drone, ShipAPI mothership, DroneLauncherShipSystemAPI system) {
        if (DEUCES_DRONE_CORONA_ID.contentEquals(drone.getHullSpec().getBaseHullId())) {
            return new PluginPick<ShipAIPlugin>(new SPE_droneCoronaDroneAI(), CampaignPlugin.PickPriority.MOD_SET);
        }
        return null;
    }

Where the AI script is completely empty
Quote
package data.scripts.ai;

import com.fs.starfarer.api.combat.*;
import org.lazywizard.lazylib.MathUtils;
import org.lazywizard.lazylib.VectorUtils;
import org.lazywizard.lazylib.combat.AIUtils;
import org.lwjgl.util.vector.Vector2f;

import java.util.List;

public class SPE_droneCoronaDroneAI implements ShipAIPlugin {

    //not relevant
    @Override
    public void setDoNotFireDelay(float amount) {
    }

    //called when AI activated on player ship
    @Override
    public void forceCircumstanceEvaluation() {
    }

    @Override
    public void advance(float amount) {
    }

    @Override
    public boolean needsRefit() {
        return false;
    }

    //not relevant
    @Override
    public ShipwideAIFlags getAIFlags() {
        return null;
    }

    //not relevant
    @Override
    public void cancelCurrentManeuver() {
    }

    //not relevant
    @Override
    public ShipAIConfig getConfig() {
        return null;
    }
}

For some reason, this always causes a nullpointer crash
31829 [Thread-4] ERROR com.fs.starfarer.combat.CombatMain  - java.lang.NullPointerException
java.lang.NullPointerException
   at com.fs.starfarer.combat.systems.N.Ò00000(Unknown Source)
   at com.fs.starfarer.combat.systems.N.advanceImpl(Unknown Source)
   at com.fs.starfarer.combat.systems.F.advance(Unknown Source)
   at com.fs.starfarer.combat.entities.Ship.advance(Unknown Source)
   at com.fs.starfarer.combat.CombatEngine.advanceInner(Unknown Source)
   at com.fs.starfarer.combat.CombatEngine.advance(Unknown Source)
   at com.fs.starfarer.combat.CombatState.traverse(Unknown Source)
   at com.fs.state.AppDriver.begin(Unknown Source)
   at com.fs.starfarer.combat.CombatMain.main(Unknown Source)
   at com.fs.starfarer.StarfarerLauncher$1.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)


What's wrong here?

274
Mods / Re: [0.9.1a] Boggled's Terraforming Mod (v4.0.1)
« on: March 09, 2020, 03:09:39 PM »
It's okay, I'm not Anglo myself, so I'm well-equipped to interpret your writing.

That aside... I was just hit with a realization that should've come to me the moment I considered this issue.
Wouldn't the immense depths of a typical water world just crush anything at the bottom into a solid, immovable orb? Could tectonic activity even happen when the lithosphere is being subjected to obscene amounts of pressure from every direction?
I'm not an expert, but that seems unlikely. Even our own little Mariana Trench(11km) is terrifying with how easily it can crush things, so imagine what a world of only water that's 100s of miles deep can do. Even if there were some plate tectonics, I feel like the pressure would be strong enough to keep their effects localized and they would never reach the surface.

What do you think?

This is getting a little off topic, but high water pressure has negligible effect on dampening waves. Instead, it makes it easier to transmit energy.

275
I really like the idea of a modern tile-based graphical interface for mods, would really enhance the whole scene. That said, like a lot of the other people in the thread I'm concerned about the effort required to maintain multiple forum/nexus/uomozRepo postings (although I don't intend to ever use nexus myself). If your website offers an efficient solution to work with all them I'm all for it  ;D

edit: To add to that, It would be a good idea to have modders contact you (or moderators if that ever happens) to be whitelisted as users that can submit their own packages.

Thanks for the feedback!

The tile graphic was a must have imho :D

The cool thing of the system is that you basically have just to allow the crawler to go through your mod automatically. I you want you can just skip the whole configuration and just allow the crawler to go through the files. It will automatically detect new versions/changes in the forum post, changes in the images etc. It's a 0 effort thing really. And for those who want they can make so the crawler is smarter about what it finds, but again, is not required!

To submit a package just post a mod in the forum (and add the repo_crawl = true anchor bbcode in the post somewhere) and you are done!

Ah, right, I missed the whole automation thing. That said, the automation process is going to fail at some point, and some way to mitigate that would be nice.

276
I really like the idea of a modern tile-based graphical interface for mods, would really enhance the whole scene. That said, like a lot of the other people in the thread I'm concerned about the effort required to maintain multiple forum/nexus/uomozRepo postings (although I don't intend to ever use nexus myself). If your website offers an efficient solution to work with all them I'm all for it  ;D

edit: To add to that, It would be a good idea to have modders contact you (or moderators if that ever happens) to be whitelisted as users that can submit their own packages.

277
Sorry to double post, but are there any considerations I need for the custom drone AI? Possible pitfalls, requirements etc. (Maybe even a peek at the source :DDD)

278
IIRC it's the drone AI doing this, not the ship system AI, so you could get whatever behavior you wanted by providing a custom one for your drones via ModPlugin.pickDroneAI().
Oh fantastic, cheers  ;D

279
Is there some AI override for the DRONE_LAUNCHER shipsystem? It's completely closed source and the DroneLauncherShipSystemAPI has no functionality for moving drones around (or other states like my post in the API suggestions thread). The image shows what I'm talking about, the drones are snapped every frame with the code below. The actual snapTo vector is just a point on circumference with a desired angle. As far as I can tell, the shipsystem script is trying to pull the drones back to their target location as defined in JSON. Free roam being on or off does not effect this.


Spoiler
    private void snapTo(
            ShipAPI target,
            float magnitude, //==1f
            ShipAPI drone,
            Vector2f targetPosition
    ) {
        if (null == target) {
            return;
        }

        magnitude = MathUtils.clamp(magnitude, 0F, 1F);

        Vector2f locationDelta = Vector2f.sub(targetPosition, drone.getLocation(), new Vector2f());
        Vector2f velocityDelta = Vector2f.sub(target.getVelocity(), drone.getVelocity(), new Vector2f());
        float facingDelta = target.getFacing() - drone.getFacing();
        float angularVelocityDelta = target.getAngularVelocity() - drone.getAngularVelocity();

        drone.getLocation().x += locationDelta.x * magnitude;
        drone.getLocation().y += locationDelta.y * magnitude;
        drone.getVelocity().x += velocityDelta.x * magnitude;
        drone.getVelocity().y += velocityDelta.y * magnitude;
        drone.setFacing(drone.getFacing() + facingDelta * magnitude);
        drone.setAngularVelocity(drone.getAngularVelocity() + angularVelocityDelta * magnitude);
    }
[close]

280
Suggestions / Re: API request thread (please read OP before posting!)
« on: February 10, 2020, 05:05:39 AM »
boolean DroneLauncherShipSystemAPI.isInHoldingPattern() would be really useful to avoid a workaround I've been using for the DRONE_LAUNCHER shipsystem type (this is even displayed as a status for player ship on the HUD so it's annoying that it can't be gotten in code...) thanks :)

281
I don't think that'd work - iirc this method is provided so that other info that the game isn't directly aware of could be specified by mods. The stuff that's already in there I don't think keeps getting re-read from the json. And, even if it was, that json is shared between all instances of the system, so changing it for one ship would change it for every ship.
That's a bummer, it did seem too sketchy to be useful. I guess I could have better luck with giveCommand? Thanks for the help.

282
Hello, I've been working on a shipsystem of the DRONE_LAUNCHER type, with a BaseEveryFrameCombatPlugin to modify the drones themselves. My question is whether I can modify the .system file JSON during combat using DroneLauncherShipSystemAPI droneSystem.getSpecJson() to modify the preferred position of the deployed drones? Normally the .system JSON specifies their angle but the DroneLauncherShipSystemAPI offers no way to change the position of the drones during combat. Thanks  :)

Example
ShipSystemAPI system = ship.getSystem();
List<ShipAPI> droneList = ship.getDeployedDrones();

            if (ship != null && system != null && system.getId().equals(SYSTEM_ID) && ship.isAlive()) {
                DroneLauncherShipSystemAPI droneSystem = (DroneLauncherShipSystemAPI) system;

                if (droneList != null) {
                    for (ShipAPI drone : droneList) {
                        int droneIndex = droneSystem.getIndex(drone);
                        if (isInFocusMode) {    //what happens if in focus mode and drones not recalled
                            if (droneIndex == 0 && !drone.getSystem().isActive()) {
                                drone.useSystem();
                            } else {
                                try {
                                    JSONArray droneBehaviorJSONArray = droneSystem.getSpecJson().getJSONArray("droneBehavior");
[close]

283
Modding / Re: [0.9.1a] Captain Trek's Guide to the Modiverse
« on: January 31, 2020, 06:27:58 AM »
Any guide inherently creates a visibility divide between mods that are in it and mods that aren't. Because it seems comprehensive, pinning this would not only crush mods that aren't in it, but also new mods that don't make a big enough splash.

I really have to dispute the notion that my guide would be worse than the systems we already have in place in this regard. The biggest reason prv is criminally overlooked is because it doesn't show up in the Mod Index. And indeed, new up-and-coming mods like Gal. Tigers and Kipling don't get placed there until they prove themselves a bit either (and Sozzer's hasn't even made it to the Index yet, but it's already in my guide). Vayra's pin in Modded Relay is anything but comprehensive, and when people ask for recommendations they invariably get told about the popular stuff the people responding to their queries already know that they themselves like. All of those things already serve to "crush" less well-known mods. Quite contrary to your position, I firmly believe my guide can serve to shed more light on mods that people otherwise wouldn't have known about than they currently get.

Agreed. This especially denigrates unique mods that otherwise create new concepts or mess with stats to have fun.

I'd be very interested to know what mods, specifically, that I'm "denigrating" so I can actually correct any such issues, as otherwise this feels rather like an unsubstantiated insult. The overwhelming majority of mods presently missing from the guide are mods I plan on adding in the future. Most particularly Discord-exclusives. What you see here is just version 1. The fruits of several months of labour, but by no means complete.

Trek has a point here, as the author of one of the aforementioned up and coming mods, I agree that any "mod crushing" and "denigration" this post causes is in most cases likely justified (looking at the shelves of low effort portrait packs here...). While I agree with my pin suggestion being a little unnecessary, I think that some claims should be substantiated.

284
Modding / Re: [0.9.1a] Captain Trek's Guide to the Modiverse
« on: January 31, 2020, 04:08:24 AM »
Congrats on finally posting this, and as predicted it's already caused its fair share of controversy - maybe this could end up as a forum/discord pin (my two cents, of course ;D).

Any guide inherently creates a visibility divide between mods that are in it and mods that aren't. Because it seems comprehensive, pinning this would not only crush mods that aren't in it, but also new mods that don't make a big enough splash.

Agreed. This especially denigrates unique mods that otherwise create new concepts or mess with stats to have fun.
You're right, I was very hasty in that assessment heh.

285
Modding / Re: [0.9.1a] Captain Trek's Guide to the Modiverse
« on: January 30, 2020, 07:24:06 PM »
Congrats on finally posting this, and as predicted it's already caused its fair share of controversy - maybe this could end up as a forum/discord pin (my two cents, of course ;D).

Pages: 1 ... 17 18 [19] 20