Modding the VoidExpanse

[Lurler]

That is strange. It doesn't happen in vanilla game... at least for us here. Could you maybe make a gif animation or a video of that? I will investigate what could be causing this.

[Hammish]

Here are two good example, I think.

http://i.imgur.com/rrbRzjk.jpg
http://i.imgur.com/FOVTOt0.jpg

The first is an effect (if a horrible one) from a BTC test build, the second is a screenshot taken from vanilla, standard Autocannon 40P.

One the second screenshot, you can see that the weapon has just been fired and can just barely see the shot starting to come out from the center of the hull.  For the second, the weapon effect gave me a chance to demonstrate better; if you look at it you can actually see where the effect is clipping through the center hull but drawing over the wingtip on the left-side pod.  My guess (and this is just conjecture based on what I have seen in game) is that the game is generating weapon effects right on 0.00 z-plane, but because most of them have no thickness on the z-axis (being sprites and all) the engine is just treating them as planes.  Since the hulls (to the best of my knowledge from doing weapon hardpoint placement) are centered more or less right around 0,0,0z, so an effect generated on 0,0,0 is going to bisect the hull, which is for all the world what appears to be going on with those pictures.

Also, it might be helpful for me to note that the issue does NOT seem to occur with any sort of beam or ray weapon, I assume because the beam is actually generated from a X/Y/Z coord to an X/Y/Z coord, instead of being generated on X/Y with Z defaulting to 0 like with sprite stuff.  Missile weapons also seem to generate at 0 z-coord but you see them appearing out of the hull earlier because they are generated as true 3D objects (and thus, once generated, have surfaces above 0, ect)

Also, I want to say again that this is noooot a huge thing.  It's just a small graphical thing that only occurs for a fraction of a second after firing weapons, and I would prioritize it pretty low.  I just bring it up because I noticed it and because it -might- be more prevalent and noticable as the mod community takes off and people design larger hulls.  For a good example, snag Flessen's Millenium Falcon off his link and try replacing the weapons with some sprite-based ones; the hull clipping is a lot more notable.

[Lurler]

Hm, you are right. It does seem like a bug. Probably just simple thing like missing the proper z assignment. Thank you, it should be easy to fix.

[ai_enabled]

The projectiles are physical objects, so they spawn at Z=0 as all other physics objects do (the rockets/mines also!) - simply because the game has a 2D physics engine!

We decided to keep it simple - it's is hardly noticeable at all for majority of projectiles.

I have an idea - we can offset projectile by Z only on client (to the height level of the turret fire point) and then decrease it gradually with distance from its source to zero value. I'm not sure though, how good/bad it will look... zero Z is important as collision point won't look right if Z shifted.

[Hammish]

Right, that was another reason I figured it'd be low-priority.  It's barely an impact on the existing hulls, it's only really noticable with user-designed hulls that have the hardpoints along the top of the hull.  I've actually found other workarounds for it as well, the most simple of which being to just take some of the more odd-looking top turrets and making them bottom turrets instead, thanks to the handy bit of code ya stuck in for flipping the orientation.   Voila, it appears a lot more natural on those hulls, because you're not expecting to see the projectile until after it's cleared the hull anyway.

Your idea sounds like it might work, though.  I mean, the height on the turrets isn't all that high off the Z-axis anyway, so even if a collision doesn't appear -right- on, it'll be close enough to be almost indistinguishable.  I still agree that it's not a huge deal and not game-breaking by any means, but it seems like it could be something to look into a bit further down the road.  (Like once Steam is chugging along more heavily and, hopefully, people are populating the workshop with all sorts of gorgeous ships.)

I kinda feel badly for bringing it up at all, now, as it seems a little nitpicky.  *sheepish look*

[Hammish]

Necroing my old thread for reasonably-easy (I hope!) occasional questions.

Today's: What's the metric used for the frame delay on weapon sprites?  I figured it was in milliseconds, so if the shot duration is set to 1.5 I assumed I would need to set the delay to 150 to have all the frames play perfectly by the end of the shot.  However, something appears to be slightly off; if I set this and then hold down the trigger the first few shots appear just fine, but after a little while they start to desync and the shots coming from the weapon are starting deeper and deeper in the frame count.  So while the normal shot looks like a small fireball that expands into a big fireball by the end of the shot; after a minute or so of firing the gun instead is shooting mid-sized fireballs that expand to large and then suddenly morph back to tiny, as if the animation was starting around frame 5 or so.

If you'd like, as time allows, I can send ya a copy of the weapon in question for testing, but as usual no rush at all.  Mostly interested to know if just getting the correct delay number in there would fix the issue, or if there is a code way to demand that each and every shot starts at frame 0 with 0 on the delay counter.  Thanks in advance!

[Lurler]

Not exactly sure what you mean, but if I understand you correctly then it's in seconds, not in ms.
Example:
Civilian laser.
<duration>1</duration> - beam time
<duration_prepare>0.1</duration_prepare> - preparation animation time
<duration_complete>0.1</duration_complete> - finishing animation time

[Hammish]

Right, the weapon duration I got.  The issue I'm running into is with the actual projectile animation.   Inside the code it's written as:

<sprite>
   <width>2</width>
   <height>2</height>
   <textures>
      <diffuse>projectiles/flamethrower_3.png</diffuse>
   </textures>
   <animation>
      <rows>1</rows>
      <columns>10</columns>
      <delay>150</delay>
   </animation>
</sprite>

Height and width I get, they apply to the scaling of the sprite.  Texture is obvious.  Rows/cols pertains to the organization of frames inside the texture file.  The one I'm not sure on is delay.  I figured if it was in milliseconds the above example should display seamlessly with a shot lasting exactly 1.5 seconds (10 frames x 150 ms per frame = 1500ms or 1.5s).  Unless... is it possible that the time is in milliseconds but only applied between frames, so the above example would only be running 150ms x 9 spaces between frames?  Dis is the part I don't know.

[ai_enabled]

Hello! I will investigate it and respond later.
Regards!

[Hammish]

No big rush, ai; more just a curiosity than anything.

So far as I know all the projectiles in vanilla have cyclic sprites anyway, so it doesn't matter which frame the animation starts on; it only shows if you use a sprite that has an end state different from the starting state.

[Hammish]

Oh, also had a secondary question, but this is a /really/ low-priority one just in case anyone knows the answer and I can't recall if I brought it up and got an answer, heh:

How does the DPS calculator in the item tooltip handle scattering projectiles?  I'm curious because it seems to be almost double-reporting any projectiles tagged as scattering.   Example:

CRB-F1 Anubis Light Fighter Bay
Launches 1 fighter per second (ROF 1.0)
Each fighter, once launched, takes a second to acquire their target
Starting at 2 seconds the fighter begins firing a shot every 0.25 seconds for 10 damage each.  24 shots are fired in total over 6 seconds for a maximum damage of 10 x 24 or 240 damage per fighter.

So at 240 damage per fighter and 1 fighter per second, the DPS should report at 240... but the game reports it as 480 DPS.  In action the fighter seems to be performing correctly at 10 damage per shot and four shots per second (about 40 DPS for six seconds straight), so it's still working correctly where it counts; was just wondering why the game inflated the number.

[Lurler]

In regards to DPS calculation - it simply adds up all damage values giving you the final raw number. It doesn't do any special calculations

[ai_enabled]

Hammish, thanks for reporting about the sprites issue. The sprites system was completely rewritten (already available in the today release v0.15.0) to fix all issues and inconsistency with it.
The changelist:
1. animation delay in seconds;
2. total animation duration calculated as Rows * Columns * Delay. So if you have 2 rows, 5 colums and 0.1s delay, duration will be exactly one second;
3. animation always starting with the first frame of sequence;
4. sprites rendered same as it looks in the image file (previously it was flipped horizontally);
5. sprites rotated taking into account rotation of the weapon turret (the frames in a source image file should be rotated to "look" upwards, not to the right);
6. performance improved (added pool of sprites);
7. muzzle flashes was also improved as they're using sprites system (but still have issue with orientation - they should be oriented to the right, will fix it at the next release).
Regards!

[Hammish]

Awesome!  I'll have to pour through and rotate sprites as needed, but the system you're describing in the new version sounds way more intuitive.  I always had to do some odd rotation and checking when I worked on sprites previously.

What changed with regards to muzzle flash, BTW?  They were something I was actually thinking about asking about, truthfully, since I noticed a few things like how odd they look if you try to add them to a beam weapon (kinda flicker on and off, I had almost expected them to stay steady-on).  I was also curious as to if, down the road, it might be possible to add in optional positional data from the muzzle flash; I've been making do and just kinda juryrigging the system thus far for stuff like the dual turret in BTC, but I'm finding with the way the engine scales sprites it's impossible to get the flash to look right on any turret type that is a different scale from the default ones.  By optional, I just mean if there is no data in there then it just defaults to the current offset, but if you say have a larger weapon you have the option to offset the muzzle flash along X/Y by whatever amount.

[ai_enabled]

Hammish, you're right about the muzzle flashes, the current implementation is unfinished. We will improve them and also add muzzle flashes for the ray weapons (with smooth fade-in fade-out according to the opacity of the ray).
>> By optional, I just mean if there is no data in there then it just defaults to the current offset, but if you say have a larger weapon you have the option to offset the muzzle flash along X/Y by whatever amount.
Hm... we can add something like "projectile_spawn_offset" for the "weapon_slot" definition in hull XML - it will be used as the starting point for rays and spawned projectiles (currently they're spawning from the center of the turret), and also it seems good to use this point as the root point for the muzzle flash. Or maybe you have a better idea?