Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ontheheavens]

Get the nebula's center, not its star, then get the hyperspace anchor, then get LY dist of that to the player.

Right; the issue with center is that it's a LocationToken. It gives ClassCastException when retrieved by ID from a starsystem instance, and so in my code I avoid all those. Another thing of note that it was not the wrong choice of entity vs its anchor in hyperspace kind of issue, since the Misc.getDistanceToPlayerLY() is supposed to handle that by calling entity.getLocationInHyperspace() in return block, and in fact, other entities in-system do not require separately getting their anchors.

Thanks for the advice though; so far I solved my issue, but will keep your method in mind.

[rogerbacon]

I want to create a tug that carries pods, like modules on a station. Are there any examples of how to add a module to a ship? I tried but got a null reference exception.

[Alex]

i did, and it works, and i was using it quite a lot before asking
however, unlike addShipList, it does not produce an info tooltip on mouse hover
unless there's some extended option or method to allow that
nor does it allow to choose the icon size

Ah, gotcha! Not sure how I can do about this right now, but that'd be a nice improvement to make to it at some point.

A little follow-up for these damned nebulas and their goddamned LocationToken centers: Misc.getDistanceToPlayerLY() produces NPE when passed nebula center SET in unexplored system and player fleet SET sitting in another star system.

java.lang.NullPointerException
   at com.fs.starfarer.api.util.Misc.getDistanceToPlayerLY(Misc.java:594)
   at fleetjour.scripts.panel.EntitySelectorPanel.shouldNotDisplayByDistance(EntitySelectorPanel.kt:176)
   at fleetjour.scripts.panel.EntitySelectorPanel.createEntitiesSelector(EntitySelectorPanel.kt:135)
   at fleetjour.scripts.panel.WriterPanelAssembly.renderEntitiesContainer(WriterPanelAssembly.kt:186)
   at fleetjour.scripts.panel.WriterPanelAssembly.assemblePanel(WriterPanelAssembly.kt:94)
   at fleetjour.scripts.EntryWriter.createLargeDescription(EntryWriter.kt:96)

Looking at the code for Misc.getDistanceToPlayerLY(), this seems like you're literally just passing null in as a parameter. I don't think that method could reasonably throw an NPE in any other way.* (Probably due to the already-established and fixed-in-dev bug with getEntityByd()).

*Unless, like, Global.getSector() returns null, in which case there'd be bigger problems.

I want to create a tug that carries pods, like modules on a station. Are there any examples of how to add a module to a ship? I tried but got a null reference exception.

Hmm, the stations in vanilla? They're probably more complex than what you'd ideally want, though; not aware offhand of any specific mod to look at for something simpler.

[bananana]

another question, is it possible to get the image path for the empty mount cover that the weapon slot would be using otherwise if it was empty

[Ontheheavens]

Looking at the code for Misc.getDistanceToPlayerLY(), this seems like you're literally just passing null in as a parameter. I don't think that method could reasonably throw an NPE in any other way.*

Right, that's entirely correct - the method in Misc isn't a culprit, it's just where the null manifested itself. The issue is with null's origin, which, again, appears to be getEntityByd().

Probably due to the already-established and fixed-in-dev bug with getEntityByd().

But. This isn't the same ClassCastException I reported earlier, doesn't have to do with LocationToken. The syntax that gave me null was (roughly) this:

Code

            val nebula: StarSystemAPI = targetLocation
            var starID: String = nebula.star.id
            var entityInstance: SectorEntityToken? = nebula.getEntityById(starID)   // This returns null.

That's precisely what I wrote in the edit:

Edit: examination with a debugger reminded me that I'm actually working here with a nebula's star, and ID of said star, when passed as an argument to the infamous getEntityByID(), returns null. In other words, idToEntity HashMap of the nebula does not contain the object that is held in the "star" field of the nebula star system instance..

In other words, (going by my memory here), ID of the nebula star (instance type is CampaignPlanet, but it classifies as nebula_center) is something like "system_901", and it's nowhere to be found in idToEntity collection - the planets it contains have ID pattern like "system_901:planet_01".

I solved this issue by working entirely around it; it still might be worth looking at.

Edit: Answer to the question "why do you have to do this the long way with string IDs": because I'm storing the strings in the intel draft item instead of storing SectorEntityToken references. I need the strings.

[Alex]

Ah, right, my bad! Looks like the nebula center isn't actually added to its location, it's just there for certain things (such as the map) but doesn't exist as an object in that location.

Edit: Answer to the question "why do you have to do this the long way with string IDs": because I'm storing the strings in the intel draft item instead of storing SectorEntityToken references. I need the strings.

Is there any specific reason for *that*, though? There very well might be but nothing comes to mind. Why not just store the references?

[Ontheheavens]

Ah, right, my bad! Looks like the nebula center isn't actually added to its location, it's just there for certain things (such as the map) but doesn't exist as an object in that location.

Thanks for the clarification; is that something you are going to fix, or is that something modders should be aware of and not use the API in the way I used it?

It's just that over the course of the work on this topic I had far more trouble than usual amount; the issue is that star systems need to have a reliable SectorEntityToken reference in-system that is always not-null. Because now it appears to me that "star" field of the StarSystemAPI was never intended as that, my question is: are we going to get that in the next update with the fixing of getEntityByID() LocationToken ClassCastException? Because I also looked at initNonStarCenter() - it, IIRC, also returns LocationToken. If we are not, I'd really like to have that.

Edit: Answer to the question "why do you have to do this the long way with string IDs": because I'm storing the strings in the intel draft item instead of storing SectorEntityToken references. I need the strings.

Is there any specific reason for *that*, though? There very well might be but nothing comes to mind. Why not just store the references?

Hmm - no any restrictive reason, to be honest. I just figured it would be a better coding practice, as I do vaguely recall you giving some advice on storing IDs of the instances instead of instances themselves (with ShipVariantAPI, etc.), and also I thought that the references to SET persisting somewhere could prevent them from being cleaned in case that was supposed by some other code blocks.

And to look at it that way: if I didn't went the string route, some bugs would be left undiscovered! 

[Alex]

Thanks for the clarification; is that something you are going to fix, or is that something modders should be aware of and not use the API in the way I used it?

The latter, I'm afraid. I don't remember the details now but there's likely a reason for how it is.

It's just that over the course of the work on this topic I had far more trouble than usual amount; the issue is that star systems need to have a reliable SectorEntityToken reference in-system that is always not-null. Because now it appears to me that "star" field of the StarSystemAPI was never intended as that, my question is: are we going to get that in the next update with the fixing of getEntityByID() LocationToken ClassCastException? Because I also looked at initNonStarCenter() - it, IIRC, also returns LocationToken. If we are not, I'd really like to have that.

What about storing a star system name and getting the star system using SectorAPI.getStarSystem()? Using an in-system entity to store a system seems a little... roundabout.

Hmm - no any restrictive reason, to be honest. I just figured it would be a better coding practice, as I do vaguely recall you giving some advice on storing IDs of the instances instead of instances themselves (with ShipVariantAPI, etc.), and also I thought that the references to SET persisting somewhere could prevent them from being cleaned in case that was supposed by some other code blocks.

Ah! There was probably a specific reason for whatever I'd said; e.g. for variants if you're storing a stock variant you'd want to store the id since that wouldn't normally even go into the savefile.

And to look at it that way: if I didn't went the string route, some bugs would be left undiscovered! 

Indeed

[Ontheheavens]

It's just that over the course of the work on this topic I had far more trouble than usual amount; the issue is that star systems need to have a reliable SectorEntityToken reference in-system that is always not-null. Because now it appears to me that "star" field of the StarSystemAPI was never intended as that, my question is: are we going to get that in the next update with the fixing of getEntityByID() LocationToken ClassCastException? Because I also looked at initNonStarCenter() - it, IIRC, also returns LocationToken. If we are not, I'd really like to have that.

What about storing a star system name and getting the star system using SectorAPI.getStarSystem()? Using an in-system entity to store a system seems a little... roundabout.

I'm sorry, I was very careless with my wording. Actually, it's not that I want to store the system - that's not a problem. I wanted to have a default fallback entity in system that would be reliable to always be there. Here's my current solution:

Spoiler

Code

    fun selectDefaultTargetEntity(intel: EntryWriter): String {
        val targetLocation = this.findTargetLocation(intel)
        if (targetLocation.isHyperspace) {
            val closestAnchor = this.findClosestJumpPoint()
            return closestAnchor.id
        } else if (targetLocation is StarSystemAPI) {
            val targetSystem: StarSystemAPI = targetLocation
            var center: SectorEntityToken? = targetSystem.star
            center?: let {
                center = fetchFirstEligibleEntity(targetSystem)
            }
            return center!!.id
        }
        return Global.getSector().playerFleet.id
    }

    fun fetchFirstEligibleEntity(system: StarSystemAPI): SectorEntityToken {
        val allEntities = system.allEntities
        val filtered = allEntities.filter { token ->
            token is BaseCampaignEntity && !token.isDiscoverable && token.sensorProfile == 0f
        }
        return filtered[0]
    }

And the UI display method that utilizes aforementioned methods:

Code

    fun createEntitiesSelector(assembly: WriterPanelAssembly, selectorPanel: CustomPanelAPI): CustomPanelAPI {
// Boilerplate.
        var inputEntities = this.getSortedEntities(assembly)
        val targetSystem = Common.findTargetLocation(assembly.parent) as StarSystemAPI
        val explored = targetSystem.isEnteredByPlayer
        if (!explored) {
            val defaultEntity = Common.selectDefaultTargetEntity(assembly.parent) // Default entity fetching.
            var entityInstance: SectorEntityToken? = targetSystem.getEntityById(defaultEntity)
            entityInstance?: let {
                entityInstance =  targetSystem.star}
            inputEntities = arrayListOf(entityInstance!!)
        }
// UI display.
    }

[close]

[ctuncks]

Is there any reasonable method to blanket force a faction to use a hullmod if it meets the hullmod's requirements? For context I'm looking to apply cosmetic shield hullmods to various factions.

Also does anyone know if there's any plans to include a setPD_Only & setAnti_Ftr methods to WeaponSpecAPI?

[bananana]

what are the options for making a module render above weapons mounted on the core ship?
or, alternatively, making the weapons (all, or some in particular), render below modules mounted on the same ship?
i'm sure it was asked 9000 times already
but, what is the current situation in that regard, as it stands now? and is anything planned to change for the next patch, regarding render order?

[Lukas04]

Is there a way to open a CustomPanelAPI while in Combat?
Been looking around and ive only found an obfuscated solution, that being to create a new obfuscated implementation of an interaction dialog and starting the custom panel through that.

...
Im specificly looking for this so that i can open a panel in the main menu of the game through an EveryFrameCombatPlugin

Hmm - what about using SettingsAPI.createCustom() and then using EveryFrameCombatPlugin.renderInUICoords() to render it?

... ah, crap, CustomPanelAPI and all the classes it's derived from don't have the relevant rendering/input processing methods exposed; let me add those to the API.

Hope this ends up working, since being able to open CustomPanelAPIs from the Main Menu & Combat would allow me to do something for my Mod Settings Panel like in the gif below, which uses some of the obfuscated code to open one. But that would of course make it not work on MacOS or Linux. Instead i am currently adding an option to the new-game dialog which opens this panel, since the new game dialog allows opening a CustomPanelAPI through its InteractionDialogPlugin, but having it accessible from the Main Menu would be very preferable.

[Alex]

I'm sorry, I was very careless with my wording. Actually, it's not that I want to store the system - that's not a problem. I wanted to have a default fallback entity in system that would be reliable to always be there.

Ah, gotcha.

Is there any reasonable method to blanket force a faction to use a hullmod if it meets the hullmod's requirements? For context I'm looking to apply cosmetic shield hullmods to various factions.

I think you'd need to override DefaultFleetInflater or some other such.

Also does anyone know if there's any plans to include a setPD_Only & setAnti_Ftr methods to WeaponSpecAPI?

You want to spec.getAIHints().add(<whatever enum value from WeaponAPI.AIHints>), I think.

what are the options for making a module render above weapons mounted on the core ship?
or, alternatively, making the weapons (all, or some in particular), render below modules mounted on the same ship?
i'm sure it was asked 9000 times already
but, what is the current situation in that regard, as it stands now? and is anything planned to change for the next patch, regarding render order?

I don't think it's doable, although it's pretty close to it - module weapons are rendered above all of the ships if the module has a CombatEngineLayers.STATION_WEAPONS_LAYER rendering layer. CombatEngineLayers is exposed in the API, but the ship's current layers aren't; I've just added this method to ShipAPI:

EnumSet<CombatEngineLayers> getActiveLayers();

So, in the next release, removing that layer from the return value of this set should make the module weapon rendering follow the "normal" rules.

... but having it accessible from the Main Menu would be very preferable.

I'll make a note to take a look at that; not sure how doable this is within the given time constraints but maybe a quick and easy way will come to mind. (Very cool, btw!)

[ctuncks]

You want to spec.getAIHints().add(<whatever enum value from WeaponAPI.AIHints>), I think.

Did some experimenting and this works a treat

Code

weapon.getSpec().getAIHints().remove(WeaponAPI.AIHints.PD_ONLY);

As to DefaultFleetInflater haven't even began to look at stuff like that yet, might just leave it alone for now and just implement my idea for players and maybe variants.

[bananana]

I don't think it's doable, although it's pretty close to it - module weapons are rendered above all of the ships if the module has a CombatEngineLayers.STATION_WEAPONS_LAYER rendering layer.

out of curiosity
in what exact scenario does this ever happen?
from my observation, module's weapons always render below parents's weapons, however module itself can render above parent's hull
and if module has BELOW_PARENT hint, then both it and all it's weapons will render below the parent, ignoring all other conditions
in which situation could module's weapons render above parent's weapons?

example:
parent is marked in green
module marked in blue
ring is a decorative weapon, mounted on module
tube-looking thing is a large ballistic turret
the deco mounted on module is rendering above parent, but below all parent's weapons

Spoiler

[close]

interestingly, this was not always the case, i remember struggling with this exact ship several years ago, and then all module's weapons rendered above all parent's weapons. which was an unwanted effect then, but i utilized it on another ship, to "fake" a module being above parent and all weapons, by simply putting a copy of it's own sprite on the module as a deco weapon. was surprised when it suddenly stopped working out of the blue.