Print

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

[Sundog]

Well, LazyWizard , I think I've got a Christmas present for you. A crash report

I've duplicated the error below several times by venting or changing weapons in missions and the simulator (toggling the radar with K hasn't given me any trouble). It seems to be associated with the commands rather than the keys. I like to bind F to 'vent' and C to 'use system', but after resetting controls to default, venting still caused the crash, while using the ship system (default F) did not). Has anyone else tested this in Windows? I think it might have something to do with differences between the native input libraries Starsector uses.

Code

68278 [Thread-6] ERROR com.fs.starfarer.combat.String  - java.lang.RuntimeException: Attempt to access data of a consumed InputEvent
java.lang.RuntimeException: Attempt to access data of a consumed InputEvent
	at com.fs.starfarer.util.A.C.o00000(Unknown Source)
	at com.fs.starfarer.util.A.C.getEventValue(Unknown Source)
	at org.lazywizard.radar.CombatRadarPlugin.advance(CombatRadarPlugin.java:210)
	at com.fs.starfarer.title.Object.float$Oo.super(Unknown Source)
	at com.fs.starfarer.combat.super.B.o00000(Unknown Source)
	at com.fs.starfarer.combat.CombatEngine.advance(Unknown Source)
	at com.fs.starfarer.combat.F.????00(Unknown Source)
	at com.fs.super.oOOO.?0000(Unknown Source)
	at com.fs.starfarer.combat.String.o00000(Unknown Source)
	at com.fs.starfarer.StarfarerLauncher$2.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:619)

On another note, if we can draw shapes with openGL (which is awesome by the way) we should be able to draw textures too, which could open up a lot of opportunities display-wise.

[LazyWizard]

Yeah, I make that mistake every time I add input. Just use the previous release until I can get home to fix it.

[xenoargh]

Huh, I've never thought about that. Although as far as I know (which isn't much after only two weeks of OpenGL experience), concave polygons need to be broken up into multiple convex polygons to be filled properly. That would make rendering slower/more difficult.

Should be able to use GL_POLYGON, although that's a bit slow.  

I think it'd be a complete waste of CPU, though, tbh

[LazyWizard]

.3b is up, get it here. This update only fixes the crash Sundog reported (always remember to check isConsumed() before using an InputEventAPI, kids!). It's kind of embarrassing how I make such a simple mistake every time I use InputEventAPI...

[LazyWizard]

Version 0.4 is up, get it here. Keep in mind this is still a very early WIP, so expect bugs (though please let me know if you find any).

Asteroids, missiles, shield arcs and phased status are now shown on the radar. I also added several options to the config file to enable/disable features and change radar colors and opacity.

Spoiler

[close]

[MesoTroniK]

LazyWizard, man you are the boss! What is next on the list?

[LazyWizard]

I want to display objectives and your current ship target, then add zoom levels, then I have to fix the positioning and scaling issues. That should be enough for an actual release.

Speaking of fixing issues, I had left in some code that more than doubled the CPU overhead of this mod. I uploaded a quick fix for that, along with fixing the radar not changing colors to match the UI properly when you are dead (so if you're not sure if you have the fixed version, go get yourself killed!). Same link as before.

[MesoTroniK]

Well, missile indicator works

Spoiler

[close]

But this makes an interesting thought occur. There is no way to tell the size of the missiles on the radar, in the vanilla tactical screen it scales the size of the icon around the size of the missile. So looking at the radar at a glance cannot decipher the difference between a hail storm of mini HE-frag missiles and high yield torpedoes for example. Is it possible to scale the missile dots on your radar also?

[HELMUT]

Given how many missiles Exigency can throw at you, the radar will always looks like some manic shooter filled with red dots, so even if the torpedoes are slightly bigger dots, they'll still be difficult to see.

How about giving a different color to missiles and torpedoes?

[xenoargh]

Have to vote for a different color for missiles as well, otherwise, that's looking TOTALLY AWESOME. 

I just hope that it, er, won't kill CPUs if we're dealing with Vacuum-sized space battles, heh.

[LazyWizard]

I'll see about changing the color/brightness of missiles based on damage.

Have to vote for a different color for missiles as well, otherwise, that's looking TOTALLY AWESOME. 

I just hope that it, er, won't kill CPUs if we're dealing with Vacuum-sized space battles, heh.

It's ridiculously fast, actually. The only parts that require anything beyond simple vector adding/subtracting/scaling are the concentric circles and ships, which require a single cos/sin calculation each. Asteroids and missiles are essentially free - asteroids are so cheap they don't even show up in the profiler results, missiles only show up because of all the OpenGL color change calls (which account for around a quarter of the total overhead right now). I could probably improve performance even more, but here's what the current performance in a large battle looks like (Paragon vs every fighter and frigate in the default simulation list). You can see the radar's taking on average a little over a fifth of a millisecond of CPU time per frame. I think I can live with that.

[xenoargh]

OK, so basically, it doesn't matter at all, compared to the rest of the load.  

If you want to further optimize it... with glBegin() and color values, you can speed that up with display lists (IDK if you're still wanting to try doing ship borders but that'd definitely have to involve display lists to be fast), with missiles you can probably do a sort of friendly and enemy in an array and then use a display list with pre-built color values; the only operations you have to do in glBegin at that point is scale, position, rotation and calling the list, because the glColor values can already be done in the display list instructions.

That said, I doubt if any of that is actually necessary, let alone doing more esoteric stuff, like using VBO to do more of the work on the GPU

Anyhow, I am really looking forwards to putting this in with Vacuum, where the scale of the battles is such that having this would be a huge thing

[LazyWizard]

Version 0.5 is up, get it here. This release adds objectives to the radar, a marker around your current target, and adjusts the brightness of missiles based on their damage (full brightness at 750+ damage). Please report any bugs you find.

Since all battle map elements* are now included in the radar view, I'm promoting this to the mods forum.

*Except nebulae, which aren't in the API yet.

[xenoargh]

Awesome.  Will try integrating this with the current Vacuum build and see how this goes

[LazyWizard]

Version 0.6 is up, get it here. This adds a bar to the right of the radar that shows how the battle's going at a glance. It's currently based on the total fleet point value of the ships remaining on each side, so you shouldn't rely on it as an accurate representation of your odds of success.

Spoiler

[close]

Awesome.  Will try integrating this with the current Vacuum build and see how this goes

Make sure you call CombatRadarPlugin.reloadSettings() in your ModPlugin's onApplicationLoad(), otherwise it'll crash when you enter a battle (possibly including the main menu battle). And thanks for the display list hint. I made the radar 'box' use one so it's only recalculated when the player's dead/alive status changes.