Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Pages: 1 ... 245 246 [247] 248 249 ... 710

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

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3690 on: December 14, 2017, 03:58:41 PM »

Not without doing some OpenGL to write the sprite to a mesh to be deformed; there's no base effect that warps a sprite.
Logged
Please check out my SS projects :)
Xeno's Mod Pack

Histidine

  • Admiral
  • *****
  • Posts: 4681
    • View Profile
    • GitHub profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3691 on: December 15, 2017, 07:26:51 AM »

Is there a way to apply the autogenerated D-ship overlay to a premade D skin?
I have a skin of a station module, with 3 D-mods, and the spriteName tag is commented out. It still looks identical to the pristine version in mission refit.
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 24111
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3692 on: December 15, 2017, 10:21:55 AM »

Looking into it - this is a horrible hack on my part, but, yes there is! Make sure the *hull id* (not variant id) of the skin ends with the string "_default_D". I really should have just added a boolean to the hull data/skin data, but for whatever reason, it didn't happen that way. I think I wasn't considering the "skin" case at all, on the assumption that it'd be providing its own sprite anyway, being a skin.

Also, if it's using a custom hull style, that needs to d-hull overlays configured, like so:

"dHullOverlaySmall":"graphics/damage/ship_damage_over3.png",
"dHullOverlayLarge":"graphics/damage/ship_damage_over3.png",
« Last Edit: December 15, 2017, 10:24:06 AM by Alex »
Logged

Histidine

  • Admiral
  • *****
  • Posts: 4681
    • View Profile
    • GitHub profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3693 on: December 16, 2017, 12:58:49 AM »

Thanks Alex! But it crashes on application load :(
Code
6023 [Thread-5] ERROR com.fs.starfarer.combat.CombatMain  - java.lang.RuntimeException: Ship hull variant [nex_asgard_module2_default_D_Hull] not found!
java.lang.RuntimeException: Ship hull variant [nex_asgard_module2_default_D_Hull] not found!
at com.fs.starfarer.loading.P.super(Unknown Source)
at com.fs.starfarer.loading.SpecStore.o00000(Unknown Source)
at com.fs.starfarer.loading.SpecStore.o00000(Unknown Source)
at com.fs.starfarer.loading.SpecStore.for(Unknown Source)
at com.fs.starfarer.loading.SpecStore.for(Unknown Source)
at com.fs.starfarer.loading.ResourceLoaderState.init(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)

(baseHullId in skin file is nex_asgard_module2_default_D)

I'll probably just ask the artist (HELMUT) for a proper D/pirate sprite.
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 24111
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3694 on: December 16, 2017, 09:04:47 AM »

That's actually pretty weird - not seeing why it'd do that, and simple attempts to reproduce this have failed to do so. Possibly something I fixed since the release? Hmm.

Edit: making the hullName for the skin end with "(D)" (minus the quotes, of course) is worth a shot, just in case.
Logged

Machine

  • Commander
  • ***
  • Posts: 114
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3695 on: December 16, 2017, 10:24:35 AM »

I can confirm you that it works, at least for me.

Made a "TSC_Sabre_default_D" and a "TSC_Sabre_TT_default_D" skins, and then made some variants that use them, both work ingame.
It seems the ships won't show in markets though, although I admit I did not test too much to make sure it doesn't happen (and no, I did not forget to add them to a faction, just in case).

Spoiler
[close]

Did similarly made "_default_D" skins of every remnant station module and the station itself, copied their variants renaming the modules to the "TSC_(OriginalShipId)_default_D, it works ingame.

Spoiler
[close]

BTW this is awesome I wanted to add this kind of (D) ships for a while, but I didn't manage it, and since it was not top priority, left it for later. Although I think it should be made a boolean in the skin file.
« Last Edit: December 16, 2017, 10:27:53 AM by Machine »
Logged

Histidine

  • Admiral
  • *****
  • Posts: 4681
    • View Profile
    • GitHub profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3696 on: December 17, 2017, 12:17:40 AM »

Okay, think I've figured it out.

Crashes:
Skin ID nex_asgard_d with baseHullId nex_asgard_default_D
Variant with hull ID nex_asgard_d

Does not crash:
Skin ID nex_asgard_default_D with baseHullId nex_asgard
Variant with hull ID nex_asgard_default_D

However, the variant does not include the D hullmods I specified in the skin file. My guess is it uses the autogenerated _default_D hull instead of the premade skin with that ID.

Fixed version:
Skin nex_asgard_p_default_D with baseHullId nex_asgard
Variant with hull ID nex_asgard_p_default_D
« Last Edit: December 17, 2017, 12:19:45 AM by Histidine »
Logged

Originem

  • Purple Principle
  • Captain
  • ****
  • Posts: 430
  • Dancing like a boss.
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3697 on: December 19, 2017, 10:09:22 PM »

I'm learning opengl by RingRenderer.java and something like this.
The texProgress finally become 2.0 and draw the picture 2 times actually, but why? What's the meaning of sprite.getTextureHeight() or getTextureWidth()?
float texPerSegment = pixelsPerSegment * texHeight / imageHeight * bandWidthInTexture / thickness; what's the meaning of this?
Logged
My mods


Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 24111
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3698 on: December 20, 2017, 10:12:32 AM »

The texProgress finally become 2.0 and draw the picture 2 times actually, but why?

The ring texture, if you take a look at, tiles vertically. texProgress tracks the texture coordinate of the current location in the texture. So, the current slice of the ring will start at texProgress and go to texProgress + texPerSegment.

How many times it'll have to go through the entire texture depends on the circumference of the ring, relative to its width - basically we're just laying down texture as we go, and whenever we're done with the ring, we stop. There's a bit of rounding to make sure that the texture ends on a whole number, so that the place where we end the ring merges seamlessly with the place where we started - due to the texture tiling vertically.

What's the meaning of
sprite.getTextureHeight() or getTextureWidth()?
float texPerSegment = pixelsPerSegment * texHeight / imageHeight * bandWidthInTexture / thickness; what's the meaning of this?

Short version: you can actually ignore texWidth and texHeight for this code, since they'll always be 1.

Longer answer: the image you're storing in texture memory can be any width or height, but the actual texture's width and height have to be powers of two. For example, if you load a 400x200 image, it'll be stored in a 512x256 texture, and will only take up a portion of it.

In OpenGL, texture coordinates go from 0 to 1. For this 512x256 texture, the x coordinate would go from 0 to 1 across the entire 512 pixel width. The texture width (at least, in Starsector terms), then, is which fraction of the allocated texture is actually used by the image - in this case, it would be 400/512, or 0.78125. So when you're supplying texture coordinates to draw this texture, you would say "draw from 0 to 0.78125 on the x dimension".

The rest of the texture will be taken up by... I forget what it defaults to, I think Starsector sets the contents to black when it loads them. You can still draw the stuff that's in there, you just generally never want to.

You can also say "draw from 0.9 to 1.1", for example, and it'll wrap the texture. For a tiling texture (i.e. one that connects to itself seamlessly), this is what you want to do - but it has to take up the whole width or height of the texture, so that there's none of the extra buffer to get in the way of the tiling. Which is why, in RingRenderer, both texWidth and texHeight are 1 - because the source texture is, iirc, 512x256 or maybe 1024x512, I forget which.


I'd also suggest looking at some OpenGL tutorials - there's plenty around, and it may help with the basics.
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3699 on: December 20, 2017, 10:37:46 AM »

If you're trying to implement OpenGL within the context of this game, I'd honestly suggest you look at what I did to build a particle system that doesn't use SpriteAPI any more than it has to.

Basically... you use SpriteAPI as an image loader to assign a texture and store it, once only, then do OpenGL work with said texture:

public final SpriteAPI fx_muzzleflash_001 = Global.getSettings().getSprite("fx", "fx_muzzleflash_001");

As Alex just pointed out, using non-power-of-two textures means some adjustments in later code; it's generally better to plan out your textures as power-of-two for ease later on, as otherwise the game has to handle it and you'll have to handle it, too.

Then you use the stored texture to do the drawing, and it's pretty simple, actually.  

Code: java
		//OpenGL Start
glEnable(GL_BLEND);
glEnable(GL_TEXTURE_2D);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

for (Map.Entry<Integer, ArrayList<fx_Particle>> entry : fx_SharedLib.particleList.entrySet()) {
int key = entry.getKey();
glBindTexture(GL_TEXTURE_2D, key);
glBegin(GL_QUADS);
for(fx_Particle particle : entry.getValue()){
if (particle.isDead()) continue;
handleParticle(particle);
float size = particle.size.getX() / 2f;

glColor4ub((byte)particle.curColor.getRed(),(byte)particle.curColor.getGreen(),(byte)particle.curColor.getBlue(),(byte)particle.curColor.getAlpha());

glTexCoord2f(0, 1);
Vector2f vec = MathUtils.getPointOnCircumference(particle.position, size, particle.angle + 315f);
glVertex2f(vec.getX(),vec.getY());

glTexCoord2f(0, 0);
vec = MathUtils.getPointOnCircumference(particle.position, size, particle.angle + 225f);
glVertex2f(vec.getX(),vec.getY());

glTexCoord2f(1, 0);
vec = MathUtils.getPointOnCircumference(particle.position, size, particle.angle + 135f);
glVertex2f(vec.getX(),vec.getY());

glTexCoord2f(1, 1);
vec = MathUtils.getPointOnCircumference(particle.position, size, particle.angle + 45f);
glVertex2f(vec.getX(),vec.getY());
}
glEnd();
}

Please read through FX_Plugin and fx_Particle in my FX project to understand how to do that in detail (storing texture ids within a body of data so that you can reduce the number glTexture() calls to a bare minimum is massively important for excellent performance, for example).



But, for a simple ring where you're not worrying about this at all, you could do something like this:

Code: java
//How round do we want this to be?
int segments = 64;
//We're setting the center of the ring to 0,0 here; obviously, you'll want to adjust that later
Vector2f position = new Vector2f(0f,0f);
//How big is the outer edge?
float outerRing = 256f;
//How big is the inner edge?
float innerRing = 200f;

//OpenGL setup stuff; the only thing that's really important here is the glBlendFunc (in this case, it's "normal", non-additive blending).
glEnable(GL_BLEND);
glEnable(GL_TEXTURE_2D);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

//The value of "key" our texture ID, that we'll use in a second, needs to be assigned.  One quick-and-dirty way to do that would be like this:
SpriteAPI myRingSprite= Global.getSettings().getSprite("fx", "fx_RingSprite");
int key = myRingSprite.getTextureId();
//Generally speaking, you only ever want to do any of this ONCE.  You shouldn't generally be doing this within renderInWorldCoords().
//But to keep things simple in this example, I've done it this way.

//Now that we have the key value, we can bind it for traditional OpenGL here.
glBindTexture(GL_TEXTURE_2D, key);
//NOTE:  If you're going to render multiple rings per frame, and you want this to be efficient, do this part ONLY ONCE.  glBindTexture() is expensive!
//Use a HashMap or an ArrayList to store the positions / sizes / colors / blend states / whatever of all your rings and then process them below, essentially.
//If you're going to have some rings that are additive and some that aren't, you'll need to deal with that properly, too.
//The best answer typically is to draw the non-additive stuff first, then the additive stuff.  Otherwise, it'll look pretty funky, heh.
//I've only built it this way to make it simpler to understand the code flow.

//Start drawing our quads for this ring.
glBegin(GL_QUADS);

//Draws a quad for each segment of our ring.
//Goes in clock-wise order (it won't work correctly otherwise!)
for(int i=0; i<360; i++360/segments){

//Left-top ring segment quad vertex
glTexCoord2f(0, 1);
Vector2f vec = MathUtils.getPointOnCircumference(position, outerRing, (float) i);
glVertex2f(vec.getX(),vec.getY());

//Right-top ring segment quad vertex
glTexCoord2f(0, 0);
vec = MathUtils.getPointOnCircumference(position, outerRing, (float) i + (float) 360/segments);
glVertex2f(vec.getX(),vec.getY());

//Right-bottom ring segment quad vertex
glTexCoord2f(1, 0);
vec = MathUtils.getPointOnCircumference(position, innerRing, (float) i + (float) 360/segments);
glVertex2f(vec.getX(),vec.getY());

//Left-bottom ring segment quad vertex
glTexCoord2f(1, 1);
vec = MathUtils.getPointOnCircumference(position, innerRing, (float) i);
glVertex2f(vec.getX(),vec.getY());
}
glEnd();

Now... I haven't tested the above, so buyer beware... but it should work.  Makes me wonder if I ought to put a ring-renderer into the FX project; it would be pretty easy.
« Last Edit: December 20, 2017, 11:04:06 AM by xenoargh »
Logged
Please check out my SS projects :)
Xeno's Mod Pack

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3700 on: December 20, 2017, 10:45:00 AM »

Fixed a couple of things to show texture-assignment, etc. within that ring-renderer example.  I think it'll basically work as advertised now.
Logged
Please check out my SS projects :)
Xeno's Mod Pack

Originem

  • Purple Principle
  • Captain
  • ****
  • Posts: 430
  • Dancing like a boss.
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3701 on: December 20, 2017, 08:46:15 PM »

The texProgress finally become 2.0 and draw the picture 2 times actually, but why?

The ring texture, if you take a look at, tiles vertically. texProgress tracks the texture coordinate of the current location in the texture. So, the current slice of the ring will start at texProgress and go to texProgress + texPerSegment.

How many times it'll have to go through the entire texture depends on the circumference of the ring, relative to its width - basically we're just laying down texture as we go, and whenever we're done with the ring, we stop. There's a bit of rounding to make sure that the texture ends on a whole number, so that the place where we end the ring merges seamlessly with the place where we started - due to the texture tiling vertically.

What's the meaning of
sprite.getTextureHeight() or getTextureWidth()?
float texPerSegment = pixelsPerSegment * texHeight / imageHeight * bandWidthInTexture / thickness; what's the meaning of this?

Short version: you can actually ignore texWidth and texHeight for this code, since they'll always be 1.

Longer answer: the image you're storing in texture memory can be any width or height, but the actual texture's width and height have to be powers of two. For example, if you load a 400x200 image, it'll be stored in a 512x256 texture, and will only take up a portion of it.

In OpenGL, texture coordinates go from 0 to 1. For this 512x256 texture, the x coordinate would go from 0 to 1 across the entire 512 pixel width. The texture width (at least, in Starsector terms), then, is which fraction of the allocated texture is actually used by the image - in this case, it would be 400/512, or 0.78125. So when you're supplying texture coordinates to draw this texture, you would say "draw from 0 to 0.78125 on the x dimension".

The rest of the texture will be taken up by... I forget what it defaults to, I think Starsector sets the contents to black when it loads them. You can still draw the stuff that's in there, you just generally never want to.

You can also say "draw from 0.9 to 1.1", for example, and it'll wrap the texture. For a tiling texture (i.e. one that connects to itself seamlessly), this is what you want to do - but it has to take up the whole width or height of the texture, so that there's none of the extra buffer to get in the way of the tiling. Which is why, in RingRenderer, both texWidth and texHeight are 1 - because the source texture is, iirc, 512x256 or maybe 1024x512, I forget which.


I'd also suggest looking at some OpenGL tutorials - there's plenty around, and it may help with the basics.
Thanks! I think I understand, and I have made what I want to do though
Logged
My mods


Originem

  • Purple Principle
  • Captain
  • ****
  • Posts: 430
  • Dancing like a boss.
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3702 on: December 20, 2017, 08:49:10 PM »

Now... I haven't tested the above, so buyer beware... but it should work.  Makes me wonder if I ought to put a ring-renderer into the FX project; it would be pretty easy.
Thank for your answer but I know how things work now.
Logged
My mods


Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 24111
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3703 on: December 20, 2017, 09:19:59 PM »

Thanks! I think I understand, and I have made what I want to do though


Cool! Not sure which parts of this involve the OpenGL stuff, but it all looks nice :)
Logged

Originem

  • Purple Principle
  • Captain
  • ****
  • Posts: 430
  • Dancing like a boss.
    • View Profile
Re: Misc modding questions that are too minor to warrant their own thread
« Reply #3704 on: December 20, 2017, 11:14:30 PM »

Cool! Not sure which parts of this involve the OpenGL stuff, but it all looks nice :)
The bending tentacles which use GL_QUAD_STRIP to render  ;D
Logged
My mods


Pages: 1 ... 245 246 [247] 248 249 ... 710