mharmless wrote:The image below is from 1200x1600 resolution on my secondary monitor. The game looks fine with 1200 width, until you start to stretch it upwards. Imagine it would be a giant pain in the ass to bound scaling on both the X and Y axis, but reporting it anyway.

Yes, it's a "known issue". See my conversation with luciderous on the same point. tldr: I think it's better to allow unrestricted scaling, even though this does mean it's possible to scale the game so that it looks bad.

That said, I could pop up a warning when people resize to portrait mode aspect ratios, which is maybe a good idea.

sven wrote:Yes, it's a "known issue". See my conversation with luciderous on the same point. tldr: I think it's better to allow unrestricted scaling, even though this does mean it's possible to scale the game so that it looks bad.

That said, I could pop up a warning when people resize to portrait mode aspect ratios, which is maybe a good idea.

I'm actually inclined to agree; I think human vision makes it unlikely for portrait-style to ever become the norm, and working poorly on some displays and resolutions is a good trade for likely working well enough on unheard of future resolutions. Has anybody tried this on a 4k display yet? I don't own one but I could probably lay hands on one for a test.

SirDamnALot wrote:In windowed mode, with enough desktop margin around the window.
1. Start on the middle of the screen and move the courser to the left. Notice when the map starts to pan. (for me: really close to border)
2. Move the courser further, outside the window. The map is probably still panning for a bit and hits left most position.
3. Move the courser outside the window to the other side.
4. Slowly move the courser from the right towards the game window. Notice when the map starts to pan. (for me: quite outside the border)

I think the border distance is consistent, regardless of the direction of approach.
The tricky thing is that the scroll speed from edge panning is fast -- so when moving out from the center, you'll usually hit the max pan extent well before you leave the 50px border in which panning is triggered.

SirDamnALot wrote:(Bonus fun: instead left and right, try up and down, but put the game window faar away to the left or right. Panning on the Y axis works for any courser position on the X axis )

That's a bug As of r15031, this should not happen. Also, I've changed edge panning to only trigger in the case that the window has the keyboard focus -- which I think makes it feel a little more natural to me.

SirDamnALot wrote:But I admit, this is a gut feeling that this is wrong. If the boundaries would move completely inside the window, you would inadvertly pan while managing your planet report, confirming event bubbles, click next turn or accessing the top bar with the ressource summary.
So, no, I don't really have a clue what would be better

Yeah, bottom line, I'm not even 100% sure that letting people have edge panning on while in windowed mode is a good idea. A few months ago, I had the feature disabled entirely if we weren't in fullscreen mode with cursor capture turned on. But, then there was a bug report regarding an issue with fullscreen edge panning setups on certain unusual monitor configurations, so, I went ahead an unlinked the options.

The default value for edge panning in windowed mode should certainly be "off", however, and right now, I don't think it is. I should fix that.

edited by sven: As of r15032, I've changed around the behaviors of the options related to edge panning / cursor capture. In fullscreen cursor capture mode, edge panning is now always on. If cursor capture mode is off, and/or if you're in windowed mode, then edge panning is only on if you enable the option "windowed edge panning". This option will be off by default in new installs, but most current testers will probably have it set to "on", due to quirks of implementation in the old system.

On my Planet "Rasalgethi LAB" I clicked on the Factory improvment (wanted to sell it) and this error was thrown:

Game_931, r15036 dev
The factory information was still shown and I could sell it just fine.
Further probing around, every improvement (except Planetary Defense) did throw this error. An empty improvement slot did not throw the error.
Other colonies are also fine.
Maybe some leftovers from my colony name testing ?

Another one:

Game_931, r15036 dev
Appeard after sending my strike fleet from Rasalgethi to Seralta. Plotted the course, hit next turn, error.
The Error prevents the execution of the next turn. Cancelling the move order or selecting another destination does not help.
So maybe it is not my fleet but one of the AI fleets. (with my scanners I see alot of traffic the AI does)

SirDamnALot wrote:Game_931, r15036 dev
The factory information was still shown and I could sell it just fine.
Further probing around, every improvement (except Planetary Defense) did throw this error. An empty improvement slot did not throw the error.
Other colonies are also fine.
Maybe some leftovers from my colony name testing ?

Thanks for the upload. The bug is caused because there are places where I use shorthands, in this case "LAB", to identify places where a formatted text block should include a custom glyph. Of course, now that people have the ability to enter more text content themselves, there's a chance that their custom text might include my glyph codes-- so I have a problem.

There's a lot of potential fixes -- I should have a patch sometime later today.

The Haduir's science advisor, Lieutenant Gitak, does not, in fact, give discounts to any technology. He should give a 50% discount to "power" technologies (I'm assuming these would be Nuclear Power at 120, Fusion at 420, Antimatter at 800, Zero-Point Energy at 3500, and Artificial Singularities at 7000).

NullVoid wrote:The Haduir's science advisor, Lieutenant Gitak, does not, in fact, give discounts to any technology. He should give a 50% discount to "power" technologies (I'm assuming these would be Nuclear Power at 120, Fusion at 420, Antimatter at 800, Zero-Point Energy at 3500, and Artificial Singularities at 7000).

Are you looking at the actual numbers while researching or at the "listed" numbers (not affected by "discount")?

NullVoid wrote:The Haduir's science advisor, Lieutenant Gitak, does not, in fact, give discounts to any technology. He should give a 50% discount to "power" technologies (I'm assuming these would be Nuclear Power at 120, Fusion at 420, Antimatter at 800, Zero-Point Energy at 3500, and Artificial Singularities at 7000).

Ah, yes. That's a bug. In an earlier draft of the tech tree, there was a "Power" field (distinct from Physics), but we retired it. Gitak should probably just not grant any field bonus. That's an easy fix, but, the documentation error will persist in any games started with builds older than 15040.

Build r15018
Unable to move a fleet to a star covered by an enemy fleet

Just as the text says. I couldn't highlight the star to send a fleet there, was trying to scout it. There was a Haduir fleet in front of it. This happened while I was recording some gameplay to send up to youtube (will link when it's done), so I don't have a screenshot.

Build r15018
Can still refit large hulls for which you do not yet have the technology without a starbase.

Captured some Haduir heavy cruisers during the video, refitting them is possible at planets without infrastructure.

Build r15018
Can capture ground units intact inside their transport ships.

Maybe not really a bug, but it sure feels weird to intercept a troopship over the Haduir homeworld and then turn around and use the troops to invade them. The first two alternatives that pop into my head are that the transports should be emptied when captured (Enemy ground units are spaced after seizing control of the transport), or if you want to keep some people from complaining about how you should be able to use the equipment, grant the 10 metal the unit would have cost to build yourself. Either of these options seem just fine to me.

I do think seizing population on transports to put to work is just fine the way it is. Only combat units seem weird.

Bug r15018
Crew can be passed forward multiple times during tactical combat.

I find myself building bridges of ships to funnel crew forward onto the ships doing the invasion. It just seems weird every time I pass troops forward through multiple ships. This isn't really a bug, its just weird. The first thing that pops into my head is that perhaps receiving crew should count as a crew action as well. It wouldn't stop doing this, but it would make it slower and therefore less abusive. The target would have more time to fight back, and you wouldn't be able to move 100 troops from four ships away and board the target with them all in one go.

mharmless wrote:I find myself building bridges of ships to funnel crew forward onto the ships doing the invasion. It just seems weird every time I pass troops forward through multiple ships. This isn't really a bug, its just weird. The first thing that pops into my head is that perhaps receiving crew should count as a crew action as well. It wouldn't stop doing this, but it would make it slower and therefore less abusive. The target would have more time to fight back, and you wouldn't be able to move 100 troops from four ships away and board the target with them all in one go.

When battles become this congested (as they often do in the current build), I see it as a sign that the balance is off. And I've noticed myself building the same sorts of "bridges" in certain mid-game battles. It is odd. But, I don't think making receiving crew expend the ships "boarding rights" is necessarily a good fix. That a number of smaller /damaged ships can all "pool" their remaining marine detachments, transferring them to a central ship over the space of a single turn feels perfectly appropriate to me. And as you say, right now, that rule change wouldn't actually do anything to remove the incentive to have your marines walk from one side of a tactical battle to the other -- such mostly stalemated states are going to persist until we make changes to the core balance and/or AI behaviors. Changing the crew transfer rules would just make the process slower and more tedious.

The most reasonable rule tweak I can think of would be to say that ships can either receive crew (any number of times) OR transfer crew / launch boarding actions, but not both. The problem there is that the rule, while perhaps intuitive enough if you think about it, would complicate the UI, as we'd need to start distinguishing between ships that can still receive crew, ships that can still dispatch crew, and ships that can do either. Which seems excessively complicated for a feature that (assuming the tactical balance gets better) would only apply to an edge case that rarely comes up in practice.

game_967, Bellatrix II - if I embark the mech, colony will disappear.

sven wrote:

SirDamnALot wrote:Game_931, r15036 dev
The factory information was still shown and I could sell it just fine.
Further probing around, every improvement (except Planetary Defense) did throw this error. An empty improvement slot did not throw the error.
Other colonies are also fine.
Maybe some leftovers from my colony name testing ?

Thanks for the upload. The bug is caused because there are places where I use shorthands, in this case "LAB", to identify places where a formatted text block should include a custom glyph. Of course, now that people have the ability to enter more text content themselves, there's a chance that their custom text might include my glyph codes-- so I have a problem.

I decided to use this bug as an excuse to standardize most of the in-game semantic markup schemes. As of r15078, all the developer shorthands should look like XML tags, i.e. "<LAB>". Also, user editable text is no longer allowed to contain '<' or '>' characters.

Updating/standardizing all the old markup strings was actually a pretty big patch -- and there's a reasonable chance that I've forgotten to migrate some of the old-style markup somewhere. If you notice strings like "'LAB" or "PLANET_NAME" that look like they should be replaced with custom glyphs or context-dependent strings, please let me know. It's probably a place where the text markup style hasn't been migrated properly to the new standard.