Bugs and Improvements

how many people need engineers?
if its 3 bases that need an engineer the last 2 can not evenly be distributed and will be kept in reserve

…and completely tanked my productivity because that second consumption didn’t have enough, so now 65% of my workforce isn’t working, when I should have had 24 hours to deal with it.

For reference, I had enough supplies last night to cover 100% of my consumption and knew I’d need to get more soon, but didn’t really have enough export to send a ship right away. So I sent the ship this morning (6 hour one way trip; no point burning fuel to hurry, I’ve got time) once a bit more production had finished (and had cash on hand to buy a couple days worth of water, using the exports to get the same amount of food).

Four hours later I have a 35% satisfaction rating because I ran out of food and water, only able to supply about half of each (I had a little less water due to corp upkeep where by the time I saw it, the only thing left unfilled was water, so I put 2u in, about as much as I was willing to spare, given how new my account is and how close my margins have been).

What kind of upkeep is this?!

Sorry, not corp, the CoGC.

Found a small error in the FAQ of the handbook
https://handbook.apex.prosperousuniverse.com/wiki/faq/#should-i-use-luxury-consumables-such-as-pwo-and-cof
The COF should be 0.5 used daily/100 pioneer
I’ve also messaged a couple of people I was recommended to in game so it might be fixed before someone reads this

ah. ok. thats nice of you but i recommend as a new player to not worry about that.
Let your local planetary goverment take care of that.

Speaking of, how about the game tell new players that?
Or I don’t know, only send the weekly upkeep notification to the relevant people? Like, say, anyone who can vote on which marketing plan is going to be in effect?

1 Like

This is a minor and interesting one: MAT ADC pulls up NE, MAT ADD pulls up RDS, and MAT AAE pulls up STL
image

Got posted as 1500.

image

I don’t see what the issue is, “ß” isn’t a number.

ß isnt a number, thats why the action shouldnt succeed.

Except that it’s trivial to parse text for valid digits and treat that as a number. As best I can tell the game parses the input as (\d*).* and if the capture group is numeric, then it uses that. “1a2s” is similarly treated as “1”

Does it treat “1,200” as “1” since the comma is non numeric? I was helping a new player that appears to have had this happen to him, accidentally posting a bunch of goods for 1 currency without realizing it.

Yes, that would appear to be the case.
From a regex perspective, both . and , should be considered as acceptable values to pass to the numeric parser (decimal values can be truncated and , is just a human separator and last I checked parsers could handle it).

Except in e.g. German where , and . are used the other way around - and it is very easy to put in the wrong one.

If materials are missing for a queued production job, you can’t see anymore if the job is a recurring one or not.

Screenshot 2021-09-27 155517
if normally you are not allowed to make an order out of the market maker bounds because your order would never get filled, it should also prevent you from making an order on the market maker bounds, as they will also never get filled because they were made after the mm-order.

While true, aeryen, the game only treats . as a decimal separator (this can be confirmed by setting a price as 1,1 with a quantity of 100 and seeing that it will cost 100 currency, not 110, as it does when using a .)

I know about other locals, but unless you have a way to set the UI’s language (which I don’t see), then there’s no reason to support comma-as-decimal-separator. If it does, then that can be language dependent (and in fact, most numeric parsers support a localization parameter).

Additionally, the number-of-units can only be a whole number (and doesn’t support . as a decimal separator at all).

SecretIdentity:
Yeah I saw that a couple days ago and was like “lol, those orders will never be filled.”

While this is true, it can happen (and already has :slight_smile:) that you input in the wrong format without checking the total and then submit an order that you totally don’t intend. If you are lucky this will still be catched by the MM bounds, but if not, you may just have sold/bough a lot of stuff for the wrong price.

I would propose to add a simple regex validation to the input field that checks for the right format and highlights the field, just as it already does if the field is empty. Having some characters ignored (especially , ) isn’t the best. Ignoring the , for a 1000 divider might be fine, but I would prefer if the number was not accepted if it contained such - if entered by hand you wouldn’t usually do that anyways, and if copied from some other value, it’s not a bid deal to remove those extra characters.

Also at SecretIdetity: people use to store goods above MM sell as they don’t require storage in the warehouse while listed and nobody can buy them if the price is above MM sell. It’s a totally separate topic if that is a good mechanic :wink:

FFIW if you sell something at an invalid (very low) value, say “100 bulkheads for $1” and there are open bids, you don’t actually recieve $100. The $1 is just the minimum you’re willing to accept. So that first open buy order for 10 at $950 gets filled first (you get paid $9500), and so on down the list until either (a) you run out of stock (b) you run out of bids (the Market Managers acting as a bid of infinite size). Same applies to purchases, the price entered is the maximum you’re willing to accept, and you pay what the current ask is until either (a) your order is filled or (b) there are no more open asks. But you only actually pay the ask price.

Proof:
Screenshot from 2021-09-27 14-35-00

I put that in as a single order to sell 3 items at $1000. There were only 2 open bids at $1100 and then another asking for some quantity at $1000 (I have since deleted the actual order, so I can’t screenshot that).

While yes, you can make mistakes, it’s not as devastating as you’re making it out to be. While the existing system can be improved it is impossible to accept both , and . as decimal separators and as thousands separators. Is “12.001” twelve and one thousandth, or is it twelve-thousand-and-one?

You could say “oh but only two decimal places” but surprise, the game supports arbitrary fractions of currency (down to a minimum resolution of whatever datatype is being used, likely a float, but could be a double or decimal):
Screenshot from 2021-09-27 14-39-45

Mind, it still displays in the order book with only two decimal points of precision, but those other decimal places ARE recognized. So you can’t actually guess at what the user meant if you support both without a localization component. (You also have to be premium to place an order outside the price band, so not only do you get a warning, if you’re a free acount–which 99% of new users will likely be–you get an error if you try to do i t anyway).