The steam beta branch for Particle Fleet has been updated with build 1.0.2b1.1.0.2b2.
Please give it a shot and let me know if you have any major problems.
[Right click the game in steam and go to "Properties". Then select the "BETAS" tab. Select "Beta" from the dropdown on that page]
The change log is in the game and will show up when you first start it. I've fixed a range of bugs, and also added and energy consumption display. I tried to be as surgical and sniper like as I could with that feature rather than make some giant whirly-gig that didn't actually help play the game.
I have also added a few options on the advanced settings menu. If you have been experiencing crashes in 1.0.1 and 1.0.2 doesn't seem to help, try some of the options on the advanced menu. In particular, try the "Use Synchronous Scene Loading" option. If you have a really weak machine, check the "Mute Music" toggle on the advanced menu to save a few more CPU cycles. And if you have some corruption and need to force unlock all missions, there is a toggle for that too.
THe energy bar is great. Seriously, just playing with it for a few minutes I got used to how it fluctuates based on the progress of a ship and the likes. Kudos on that!
1] CITG - nice, we can see who's there... possible improvement? : current page # / total # of pages
2] I see what you mean by collapseable ring when in recall mode (can't seem to change recall range from 25 though)
3] No issues found as of 21st [23h45]
Otherwise, Sorrontis out.
Linux, v1.0.2 has forgotten my UI scale setting.
No matter what I do, it's always maxed at restart.
-----
UIscale is a decimal number in the XML, are we having dot/comma issues again?
----------
Yes, can confirm that you didn't fix the linux language issue, I see the old sprite issues again.
Putting 'LC_ALL=C' back fixed it again.
Seems a devious bug, it might be faster to include a shell script to set LC_ALL and launch the game instead of trying to fix it.
---------
Another question, how do I get the changelog back after badly dismissing it? If it isn't possible now, maybe make the "Version 1.0.whatever" clickable.
So in your GameSettings.xml file, you only ever see 1 or 2 for the UIScale? You don't see "1.4" for instance?
To get the change log back edit this line in your GameSettings.xml
<LatestChanges>1.0.2</LatestChanges>
Just make it say anything other than 1.0.2 (removing it is also fine).
I'm doing another beta build today (1.0.2b2). So check back later today if and try the beta branch again. I've potentially fixed another issue with the locale stuff. 1.0.2b1 wasn't properly setting it (there is a big difference between .net 2 and mono 2 when it comes to CultureInfo I've learned). If 1.0.2b2 doesn't fix the locale issue, I'll pursue the shell script path...
What I meant is that I saw '1.1', so I imagined you had a locale issue, and seems I was right.
Thanks for the LatestChanges thing.
Ahh... I see.
When you set your locale from the shell, do you still have the uiscale problem?
No, everything is perfectly working.
Ok, yeah its all locale based. The UIScale field is a floating point value. If it says "1.2" and your locale wants a comma then it is getting read as "12". If it says "1,2" and your locale wants a dot, it also gets read as a "12" (I can easily test that latter scenario).
I might just change the value to an integer to avoid this whole potential problem. The locale stuff will get fixed one way or the other, but even with that I could make things more robust by just using an integer in the gamesettings.xml for uiscale. Currently, the values go from 0.5 to 2 in increments of 0.1. So 0-15 could represent the same thing. Note I will use a different name in the xml for this (UIScaleI) and in the next build you will have to set your scale again since it will default to 1.0 (uh 5).
Quote0-15
Do a favor to yourself and leave room before '0', you never know..., I'd use 5-20.
And yes, in the xml there is always x.y, regardless of locale, and with it_IT PF was reading it as xy (11 in my case).
1.0.2b2 has been pushed to the steam beta branch. If you don't have it already, restart the steam client and it will update. The release notes in the game will show again and have some additions at the top.
If you are on linux in a country that uses commas for floating point numbers, give it a go without the shell fix and see if it works. I give it 50/50...
Has anyone else noticed that the energy use values can be very high and yet your stores do not deplete? I often see a 100 energy usage with far less production and still my stores remain full. In general I think this is great but there seems to be some calculation issues.
Also, it would help newer players if the usage was actually labeled. You are left guessing what that number actually is. For that matter, it isn't clear what colors on the production bar are mine and land.
The usage calculator is averaged over 1 second so it can lag actual usage by that amount of time. In highly variable cases this can lead to values that appear too high or too low for a transient time. If anyone finds a case I can reproduce where the demand outpaces supply and the store stays full all for more than 1 second, I definitely want to take a look and see what is going on.
So, 1.0.2b2 report:
* Linux locale works, thanks a lot Virgil
* Reproducing the issue @tanelorn talks about is pretty easy, you just need to involve omnis and their reactor upgrade.
I could try digging more, but I'm sure Virgil can do it better than me.
Beta 1.2 glitches :
- Various graphical bugs (emitters and energy source invisible and other stuff) See screenshot for difference between 1.1 and 1.2
(http://images.akamai.steamusercontent.com/ugc/425980860091121874/51261265E8FA5E8326B8430BCC0113A58260599A/)
(http://steamcommunity.com/sharedfiles/filedetails/?id=786012717)
(http://images.akamai.steamusercontent.com/ugc/425980860091139686/093B4F6AD0D0D10424BEB71660A482B9D42C54E2/)
(http://steamcommunity.com/sharedfiles/filedetails/?id=786016211)
Windows 10 pro X64 / AMD RADEON HD 5450
Bug report end / Have a nice day. A message from Exostum Fleet Corporate
Maybe it because I still use old version?
P.S. Not yet tried new version because waiting for non-Steam new version.
Linux, amd64, intel integrated graphics here.
I can't reproduce Exostum's bug, everything looks correctly, as in his 1.0.1 picture.
I'm not reproducing it either...
Exostum, check your log and see if anything odd is in it.
Ok, the issue must be the same as this:
http://knucklecracker.com/forums/index.php?topic=22118.msg151386#msg151386
I can manage to reproduce it by resizing the game window when playing. That makes things randomly disappear. If I restart the mission, they reappear.
Now ahat Unity is up to now is currently beyond me. I dared update to 5.4.2final(2) thinking 5.4 had baked for long enough. Silly me.
Alright, the steam beta branch has been updated to 1.0.2b3. This build should address the omni energy reporting issue that could make energy consumption appear wonky while the omni reactor upgrade went from 0 to 100% efficiency.
I have also reverted to Unity 5.3.6. This should address the graphics flaking out. That looks like a bad Unity 5.4 bug to me... I don't need anything in Unity 5.4, so 5.3.6 is more stable currently. Now the reversion required hooking some things up that the upgrade to 5.4 changed. So if you see anything that look purple rather than its correct color/texture, take a screenshot and let me know.
In the beta version, if your UI scale is at a certain setting, the data inside text boxes is missing.
See attached images for clarity
Linux, amd64, v1.0.2b3.
Big V, omnis still give problems to the energy display.
Have a look at these screenshot:
(http://images.akamai.steamusercontent.com/ugc/427106415250555253/10808C19F1069B1065EF7C1A5E15DCFD4FDFF879/)
Energy request well above energy production, yet storage does not decrease (it flip-flopped between 99 and 100).
This is not a transient situation, it was like this for >10 seconds.
No omni reactors, only omni cannons.
Map is Exchange #232
Interesting and embarrassing....
The problem was that the enemy energy mine cannons were counting towards energy consumption. Basically, I neglected to check the enemy status of things collecting energy. Those enemy energy mine cannons are starving and were adding to the apparent energy consumption total for the player.
Just me, or does the emitter options deserve a scrollbar? Just barely able to click the buttons below delete unit.
Yeah, I was figuring somebody would notice. You are running on a 720 high display. I tried and tried to make things fit at 720 over the last two years. But I got lazy when I added the last options to the emitter editor and was only testing at 768.
Also... what OS are you running on? Some of your fonts look really different. The "CORPORATE HQ" font looks different and so does the font in your red game events.
OS X Ver 10.9.5 Never thought anything of the text except I took OMNI as OVNI first.
Has the text always looked like that for you or did it look different in 1.0 or 1.0.1?
--edit--
It looks like for some reason your don't have the Arial font on your system, or it has been replaced by some other font. On my mac things look identical to windows and linux. The fonts that appear differently in your screenshot are all using Arial, though (the Unity default font). Try bringing up the Font Book application on your mac and see if Arial is present. If you upgraded from an earlier version of OSX could be something happened along the way.
If things are working fine for you definitely don't change anything. I'm just curious if Arial is missing on your system and that is what is producing the difference.
It does not appear Im missing Arial on my font. It has been like this since 1.0, (or at the very least since I downloaded it from Steam). Im only slightly annoyed by the emitter thing but its no big deal, just esc out of the menu or click something else to get out.
--edit--
as for the font thing, Steam has constantly required for overlay access or what not whenever I open it up. Thats probably the font issue, I usually click deny since no is better than screwing up with a yes.
The steam beta branch has been updated with the 1.0.2 release build. This will be moved to the default branch tomorrow unless a major problem is found.
Quote from: virgilw on October 24, 2016, 07:31:34 PM
Interesting and embarrassing....
The problem was that the enemy energy mine cannons were counting towards energy consumption. Basically, I neglected to check the enemy status of things collecting energy. Those enemy energy mine cannons are starving and were adding to the apparent energy consumption total for the player.
Hmm, I am experiencing this still. I will post a log, etc when I have a chance.
A mission save that reproduces it would be good. Also make sure your version says 1.0.2 on the main menu. There could easily be some other case I didn't catch in your particular mission setup.
Pretty sure this is the correct save. It is for a map I am currently making. My game had popped up the changelog so I knew I had the new update. Strangely, I just played it now and the energy usage halved and appears to be more in line with how it should look. It was strange because before it would show a massive deficit of 130 and I would be producing...maybe 70-80 energy, and yet my energy pods weren't being used.
There are still times when my energy store is draining yet, my drain is less than my production. See below screenshot. I was watching it like a hawk and it never exceeded 70 yet the store would begin to drain rapidly. I'm guessing it's just an artifact of prediction algorithm you created.
I've seen the same effect @Kharnellius reports, but I couldn't replicate it, either.
I suspect it's related to the energy tank module, but I can't be sure.
It's really tricky calculating energy draw. The problem begins with what that bar actually represents. Energy production is in packets per second. The energy store is in packets. Energy draw should therefore be in packets per second.
One way to attempt to show energy consumption is to count packets created over a unit of time. That works so long as there is sufficient energy to create packets. If there isn't, then the energy demand exceeds production and packets won't get created that reflect that demand.
So the way it works is to note the state that various energy consumers are in. When a ship is building, it requests packets at around 2 per second while building the bridge. That is the ships energy demand whether it gets it or not. Once the hull and weapons are built and powering, it requests energy at 30 pps. That is true on any frame it asks for packets (Even it it only needs 1 packets). So you can see how this becomes a mini exercise in calculus. Omnis are similar and want packets at a rate of 30pps. Unless of course their reactors are coming online.
Anyway, the demands of various things get summed and then added each frame to a rolling queue that is 30 large. That queue is averaged every frame and that becomes the energy drain. So it's a rolling 30 frame (1 second) average of all of the highly erratic energy request rates.
Can I ask how many energy packets the game can serve per frame (assume infinite production)?
There is no limit on the amount that can be created. The limit is that a thing requesting a packet can only request one per frame.