AzeTheGreat

  • Content Count

    141
  • Joined

  • Last visited

Community Reputation

84 Excellent

About AzeTheGreat

  • Rank
    Member
...

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Enable
  1. When using the preinstalled Russian translation, Localization.GetLocale().Code is not properly set. I believe this is because the Russian strings do not declare "Language: " in the header. This means that mod translations may not work properly if the developer is not aware of this edge case (it is possible to work around, but it shouldn't be required).
  2. When deploying a rover, the Build Tool Info Card is created without a Shadow Bar. It appears that `HoverTextDrawer.EndShadowBar` never gets called.
  3. In rare cases, you can get issues that look like this: Note that the first Info Card has a blank Status Item in it.
  4. Because that would be redistributing game files and is illegal. It'd also mean that you have to keep files updated from another download source, which is extra work when Steam will handle that for you. Decompiling is also the easiest step in the entire modding process, so if it's too much for you then I'd recommend turning back now. Honestly your entire post sounds like you're looking for a lot more "help" than you'll ever get. Modding ONI involves mucking about in the internals of the game and you have to accept that and be comfortable with it.
  5. Or did they mean reaching QOL feature parity between the versions? You're just making an assumption, they didn't say anything explicit about the code base.
  6. Can you expand on what exactly you mean by unified here? Will the base game and DLC version share the exact same code base, and just have certain parts of code locked out / no assets distributed without the DLC? Or will it be less unified than that? I ask because sharing the same code would make modding far, far easier. Needing to maintain two versions of every mod is not a fun proposition. And if we get more DLC in a couple years, that just scales... Also, if you have to make changes to the modding system anyways right now, would you consider taking suggestions from the modding community? There are a ton of changes - small and large, that would improve our experience making mods, and end users' experiences with using mods. To be honest, the modding support has felt very bare bones, and I think you could see a lot more modding (which adds value to the game) with some improvements.
  7. I am specifically speaking from the perspective of a mod developer trying to fix crashes. The blackhole screen is different from the "standard" crash screen with a stack trace. Having the button there does nothing to encourage end users, who know very little about coding or bug reporting, to report issues with sufficient information to reproduce/solve them. Half of the bug reports I get include no information at all, and those are unavoidable, but the other half frequently include just the stack trace pasted in. While actually including the error will make the stack trace a lot more useful, it would be even better to encourage users to submit the full logs. Making attaching the full logs just as easy as pasting in the stack trace (and telling users to do that) is the best way to do that.
  8. Thank you so much, this will help a lot. Please consider encouraging users to send the full output log - it can make a massive difference in fixing bugs (which I'm sure you know). Adding a button to open the log location, and a message telling users to submit it to crashing mods would be ideal in my opinion. (I still really think the stack trace shouldn't be shown to end users, but oh well).
  9. I don't know what the intent was, but the button stops delivery from both dupes and sweepers currently.
  10. You can use my mod to configure the values to your liking.
  11. Accessing ReportManager.Instance.YesterdaysReport returns null on the second cycle, when there is a report for the previous day. It looks like todaysReport is not added to the dailyReports until night, so this code, public ReportManager.DailyReport YesterdaysReport { get { if (this.dailyReports.Count <= 1) { return null; } return this.dailyReports[this.dailyReports.Count - 1]; } } should probably check for 0 not 1, public ReportManager.DailyReport YesterdaysReport { get { if (this.dailyReports.Count = 0) { return null; } return this.dailyReports[this.dailyReports.Count - 1]; } } Noticed this because the insufficient oxygen generation notification won't trigger on the first or second cycle.
  12. Drop regolith onto an open, vertical door. The regolith should be stopped on top of the door. Sometimes, however, it will land inside the door, or phase through it entirely. I'm guessing this has something to do with collision detection steps, though it's curious that it's only an issue for open doors. I tested a bit to get some numbers, hopefully demonstrating a rough correlation (that I assume might get better with more trials than 20 per distance). Distance # Stuck # Phased 1 0 0 2 0 0 3 0 0 4 2 0 5 4 0 6 3 0 7 8 0 8 7 0 9 1 0 10 13 0 30 7 1
  13. The robo-miner can not be placed without a foundation in any orientation. However, if it is placed on a door and the door is opened, it continues to work only if it is facing to the right. If the game is reloaded, it will realize that it does not have a foundation, and will not work. Closing the door at this point will not cause it to recognize the foundation until the game is reloaded again.
  14. Well it depends entirely on how it's implemented. You're right that if it's just heating vat -> reactor then it's quite boring, and adds nothing to the game. That's why I tried to expand on it a little. Lets say our heating vat works as a batch system, while the reactor is continuous. So you pump in oil to the heating system, when it's full it heats for a while, then it pumps out your sour gas. So the most basic setup of heating vat -> reactor still works for an initial setup, but you're going to have large downtimes, and it's far from optimal. This immediately introduces more depth. One potential solution is using two heating chambers, and using automation to alternate between the two (one outputting gas while the other fills/heats). That gives you a much more even flow, at the cost of greater design considerations. Maybe instead of automation, you decide to use multiple gas tanks to act as a buffer and cover your downtime. Then, as long as your average sour gas production exceeds demand, you'll be covered. That's not a ton of depth, but this also does something else important: introduces the ability for logistical depth as stuff scales up. This is something that Factorio does extremely well, and ONI does horribly - small operations are easy, but as you scale up balancing resource flow and distribution becomes more challenging. Scaling beyond anything more than 1000g/s of sour gas flow would require more design adjustments than just attaching more machines to the same piping infrastructure. And that's just the start - think about dealing with heat now. If the sour gas comes out hot (as it should), then you have to deal with it. At low throughputs, just letting the environment cool it is probably more than enough, but as we scale up maybe we need to send it through an aquatuner to handle the heat quickly enough. But maybe the reactor could have an ideal temperature, causing it to work faster or give better conversions? That could encourage separating the cooling so that the target temperature could be more accurately reached, and cooling the sour gas through a heat exchanger built with radiant pipes. Maybe that ideal heat is close to some explosive threshold (seriously can we get explosions and fires?), making it a risk vs reward - push it too far without proper safety mechanisms and it could go boom. Then that ties back into the additional heating vat vs gas storage I pointed out earlier - storing more gas is inherently less safe and could cause a bigger explosion. And that's just exploring a couple possibilities for depth...if reactions could have catalysts and different reaction pathways, then that introduces additional choices. Maybe we use a byproduct in a different process, or maybe we use it as a recycle stream. The germ system could probably be adjusted slightly to create a contaminant system so that filtration becomes an option. Hopefully this shows how it could easily introduce depth, without making early designs an insurmountable hurdle for new players.
  15. At least personally, I want internal consistency in gameplay. ONI has a fairly amazing system of gas/liquid/heat interactions - it's not perfect for sure, but it allows us to make super interesting builds, like oil boilers. These require a lot of thought and design to make functional, and there's so much room for optimization. It creates in depth and rewarding gameplay. Now, contrast this with the default buildings ONI provides - many of them essentially serve as 'magic boxes'. Stuff goes in, stuff comes out, with almost no consideration for the processes that are required to occur there. Compare an oil boiler with the refinery - which one is more interesting to design? However, I completely understand that there must be some minimum level at which we accept the 'magic boxes', after all, nobody wants to design a pump and test different impellers...and the early game would be too difficult otherwise. The problem is that, when it goes too far in the direction of magic boxes, we lose the interesting interactions with the rest of the game world and it feels weirdly inconsistent. Just to make some comparisons of where there are ways to do things both with compositions of smaller parts and with the inbuilt structures: Oil boiler vs Oil refineries Physical gas tanks vs Gas Reservoir Door pump vs Actual pump Density vs Mechanical vs Standard filters Heat exchanger vs Aquatuner etc My issue is that different buildings seem to have different levels of granularity and viability. In a perfectly consistent world - everything would be built out of the same fundamental building blocks. Minecraft is a good example of this: everything takes up a block - a massive auto smelter is just a combination of many smaller and simpler blocks, working in harmony to create something greater. There isn't some 'automatic smelter', 5x5x5 structure that could optionally replace it, and I doubt anyone would want there to be. ONI can operate like this as well - just look at any oil boiler design, they're all made of the same fundamental parts: blocks, pipes, doors, and automation. That feels consistent. Now look at a refinery - oil goes in, petroleum and other stuff comes out. There's no concern for us to control temperature ranges, no flowrate concerns, it's a magic box that just somehow works - and it does the job of many smaller parts. Compare that to something like a door pump vs the standard pump. The door pump does do a better job of feeling like it's made from constituent parts, but the pump isn't really a problem because it only does one thing. So, this brings me to my evaluation of what's wrong with the current state of the game / path it's heading down: It's almost always possible to replace an inbuilt machine with a composition of basic parts; this is good and adds depth to gameplay. The problems arise when the inbuilt solution is orders of magnitudes worse, rather than being a trade off with positives and negatives for both, as was the case with oil boilers and is the case with filters; that reduces depth of gameplay because there are objectively better options to take. Finally, the game feels inconsistent because some machines don't just do a single thing - they excessively simplify complex processes into magic boxes; this removes depth from the gameplay because players can just plop down magic boxes without having to perform any sort of design. So, I believe that, as it currently stands, many of the buildings in game are too simplistic for their purpose, and should be split into multiple small buildings. I'm not versed in the process of refining oil, but assuming it requires some kind of reaction and heating process, the refinery could easily be re-purposed into a reaction chamber while a new heating vat could be created. Make the reactor operate continuously while the heating chamber operates in batches and you've already added some depth in design to the oil refinery without making it significantly more complicated to build (New players will actually have to think about how they construct it, but it's not so many pieces that it takes more than a cycle once they come up with a design). This has the added benefit of allowing buildings to be used flexibly: a reactor could have a sour gas -> natural gas recipe, petroleum -> rocket fuel, etc. It could have the ability to accept catalysts to improve reaction conversions, rates, etc. The water sieve could be repurposed into a general filtration machine for removing impurities, the slime distiller could be turned into a distillation tower, and so on. By breaking buildings up into small, single-use structures that also interact with the environment, more design depth is added to the game without making it outright harder, it feels more internally consistent, and it makes it easier for developers to give pros and cons to choosing either the inbuilt structures or player crafted alternatives. Theoretically...