1.0D CECOMMPATCH - 0.9.5 - Updated: 2017/04/20

Discussion in 'Clockwork Empires General' started by EsBee, Mar 3, 2017.

  1. EsBee

    EsBee Member

    Progress on the next update is going well, albeit slow. The UI overhaul for workshops, offices, etc. went great... EXCEPT for the trade office. Turns out the majority of that menu is either hardcoded, or in a file I haven't been able to find. Unfortunately this means that particular menu looks pretty bleh. It's functional, but it's not pretty. I'll have to work out a better solution later, but ultimately I think it will always be a one-off that just won't match anything else. I'm not super happy with a few other menus, but that's more a matter of fiddling with flavor text and font size/color than anything else.

    I'm on the last phase of this particular patch. I have to combine all the various warning/status texts used in the various workshop menus because the new UI breaks pretty horrifically otherwise. It's slow going because it requires a lot of custom logic for each shop, but this *should* be the last thing I need to do before 0.9.0 comes out. I may take a stab at redoing a few more menus before release, but those should be pretty quick to deal with. Tooltip styling needs a *lot* of love, but I'll do that later as it's a huge pain in the butt with how inconsistently it's handled.

    After this, I'll be back on the bug fixing/etc. train most likely. Ooooor I may get sucked into doing custom font stuff, as I finally figured out how the UI all fits together and can, in fact, do it (wooo!). It's not a quick process, but I think it'd be worth it. I may put that on the back burner for awhile though, as the bug stuff is more pressing.... granted I think most truly critical issues have been solved.

    Here's some previews of the new menus. This whole overhaul is really just a once-over. Over time these will get even more love, but they're pretty much done for this particular pass.

    Overseer menu still needs some love:

    Barbershop still needs to have the warning/status text changes. Also not sure what I think about my Naturalist changes:

    Gah.. the Trade Office...

    Housing and farms... sooo boring. Not a lot I can do with them without just adding pointless fluff, at least for the time being:

    Think I may have gotten a bit too wordy with the Academy. Also, two examples of workshops (they all use the same template):
    Last edited: Mar 21, 2017
    Samut likes this.
  2. Samut

    Samut Member

    Looks great. Are there tooltips for the various options?
  3. EsBee

    EsBee Member

    Yep. I did a once-over consistency pass for tooltips in these windows, though mostly that was just tweaking the visuals to get rid of huge chunks of blank space or inconsistent wording (like "focus on building" and "destroy building" versus all the other variations that were used). Most tooltips are the same as they were in the default game... meaning some areas are oddly sparse. Suppose I may as well go through and add tooltips to the spots missing it while I'm messing with these particular files. The barracks and public house are the two off the top of my head that need 'em for the supplies icons.

    Also, does anyone have a case where they've had more than two "local products" for mines? The font size may be too large in retrospect, but I haven't yet run into anything that has a bunch.
    Last edited: Mar 22, 2017
  4. EsBee

    EsBee Member

    Ooof. 0.9.0 has been released! https://github.com/SickBoySB/cecommpatch/releases/latest

    • !!!MAJOR CHANGE!!! - Office, workshop, farm, and housing menus have been completely reskinned!
    • FIX: UI - Chapel isn't reporting being out of cogs in its menu
    • FIX: UI - Being out of laudanum isn't sending the appropriate warning text in the Public House menu
    • CHANGE: UI - Reskin - Workcrew menu
    • CHANGE: UI - Reskin - Housing menus
    • CHANGE: UI - Reskin - Barracks menu
    • CHANGE: UI - Reskin - Workshops menus
    • CHANGE: UI - Reskin - Farm menu
    • CHANGE: UI - Reskin - Mine menu
    • CHANGE: UI - Reskin - Public House menu
    • CHANGE: UI - Reskin - Barbershop menu
    • CHANGE: UI - Reskin - Chapel menu
    • CHANGE: UI - Reskin - Laboratory menu
    • CHANGE: UI - Reskin - Foreign Office menu
    • CHANGE: UI - Reskin - Naturalist Office menu
    • CHANGE: UI - Reskin - Academy menu
    • CHANGE: UI - Chapel menu "jobs" section removed until consistency in usage can be done
    • CHANGE: UI - Barbershop menu "jobs" section removed until consistency in usage can be done
    • CHANGE: UI - Less sensitive scrolling - House choice
    • CHANGE: UI - Less sensitive scrolling - Office choice
    • CHANGE: UI - Less sensitive scrolling - Workshop choice
    • CHANGE: UI - Farm "focus on" button removed since it isn't working
    • CHANGE: UI - House "focus on" button removed since it isn't working
    • CHANGE: UI - Made "Focus on Building" and "Destroy Building" wording consistent across the board
    • CHANGE: UI - Combined warning/status text - Public House
    • CHANGE: UI - Combined warning/status text - Barbershop
    • CHANGE: UI - Combined warning/status text - Chapel
    • CHANGE: UI - Combined warning/status text - Mine
    • CHANGE: UI - Combined warning/status text - Barracks
    • CHANGE: UI - Combined warning/status text - Laboratory
    • CHANGE: UI - Combined warning/status text - Naturalist Office
    • CHANGE: UI - Combined warning/status text - Academy
    • CHANGE: UI - Combined warning/status text - Foreign Office

    Known Issues:
    • When workshop/office/etc. menus are open, there is a "dead zone" below it that doesn't register clicks. This is a hardcoded issue only made obvious because of visual changes to the UI. The default game actually does this with the "Factions" menu, but now it's a bit more obvious. Closing a window before clicking will mitigate the problem.
    • Old saves may temporarily have odd text issues when a workshop/office menu is open. After resupplying/etc. is triggered the new system will take over. This is purely a cosmetic issue and doesn't impact new saves.
    • The Trade Office menu isn't very pretty. Most of that menu is hardcoded and a good solution hasn't yet been found.
    Samut likes this.
  5. Samut

    Samut Member

    Dang. This is awesome.
  6. EsBee

    EsBee Member

    Just going to leave this here to tease something I was able to accomplish while digging for something else:

  7. Teutomatos

    Teutomatos Member

    Huuuu what's this ? Are they folding chairs ? :p
  8. Samut

    Samut Member

    My apologies, but it's been so long since I played CE that it's not clear what's different in that screenshot. Is it the lighting?
  9. EsBee

    EsBee Member

    Heh, it's the tooltip for an unbuilt item. I was able to get the name to show up instead of it always saying "Module Under Construction". Of course like so much else it goes away when reloading a save, but for a single session there is no more confusion on what it is you had planned to build.

    On a different note:

    I've been doing tests on spawning litter/rubbish when colonists do certain actions. I finally figured out how to get it working how I wanted, so now the real question is what to do with it.

    The idea I had was to have trash start accumulating around the colony, causing despair/anger. The entire thing would be weighted based on character traits... "lazy" would have a higher chance of dropping litter (and have less of a mood impact from seeing it), "organized" and "naturalist" would have a lower chance (and be more negatively impacted). These are just examples, but that's the basic idea on how it would work. Specific actions would create specific kinds of trash. Booze consumption would create broken glass and bits of paper, doing workshop jobs would create bits of wood/brick/paper, etc.

    The next part of the idea is to have a workshop that does something with it. Whether it just burns/destroys garbage, changes it into something usable (recycled paper, fuel, bottles/glass, trade goods, etc), or whatever. There's a lot that could be done with it, it's more just a question of what we *want* to do.

    Thoughts? Ultimately I'd like to turn this workshop into an entirely new "Otherworldy Cleaners" kind of thing that would include doing laundry as well, though I haven't had a chance to test whether swapping the clothing line models is doable yet.
  10. For the "Cleaners" workshop, it could be tiered, like...say, you start out making a stockpile-style "dump", then work up to incinerators, then to recycling machinery that churns out recycled paper/glass/bricks/whatever? You could maybe even somehow tie in the ability for another workshop to make robotic drones that will do these tasks, and/or hauling and such, maybe have them powered or fueled by something else. Just tossing out ideas, I have no clue what you're actually able to add or change from the end you're working with.

    Off the topic of that, but one thing I've been longing to see since EA is a functioning system of paths and roads.
  11. EsBee

    EsBee Member

    Roads are a no-go, unfortunately. They're sort of implemented (just inaccessible without editing files), but they are so hardcoded that there's no way they could be finished. They also crash the game a *ton*, can't be removed, and aren't hooked into a system that requires materials/jobs to build (you just draw them on the ground). The best we could hope for is a hacky kind of solution where you place what are essentially "standalone modules" or gabion/stockpile-esque things that are then built. The colonists wouldn't prefer to use them (that kind of pathfinding isn't in exposed files as far as I know), so they'd be 100% cosmetic. It'd be a pretty awful solution and I'm not sure it'd even work. There's also the question as to whether that kind of solution could be saved.

    Fences are far more likely to be something I could get working... but the biggest issue at the moment is that they aren't saved. It may just be a matter of finishing their implementation, but my gut tells me that we might be out of luck in that regard too. Saving isn't handled by the exposed code, so making totally new systems that aren't just variations of existing ones doesn't work. That's why we can make new workshops, items, recipes, etc... but not something *completely* new. Fences *might* have the advantage here since they're really just glorified gabions, but we'll just have to see.

    While I know some folks want roads, they aren't really even on my radar. The work involved to get something so cosmetic and useless just isn't worth it in the end. If the game world was a ton bigger and giant cities were actually viable (and colonists could be made more inclined to use them), then it'd make more sense.

    As for the trash workshop: it would indeed be a tiered system, like all the other workshops. Early gameplay would be simple incinerators and the like, more advanced modules would be far more useful. I like the idea of robots/creatures doing the cleanup at higher tiers, though I'm not sure how that'd impact performance. The game has a pretty hard time running with 50+ colonists as it is.


    I NEED ASSISTANCE nailing down the stockpile problems.

    Right now there are a lot of problems with stockpiles, but I'm finding it incredibly difficult to nail down where the problems are occurring.

    Here are the issues I know of:

    1. Items can show up in the stockpile list that don't actually exist, both visually and in the overall commodities list.

    2. Different items can be stacked on one another.

    3. Items to be combined into a single stack are sometimes placed on the wrong spot, seemingly disappearing when the combining occurs.

    4. Items are sometimes pulled from nothing (not sure if this is occurring anymore). Similar to issue #3, but it occurs when taking an item *from* the stockpile.

    If anyone has any input on when these problems are occurring, especially if it's reproduceable or consistent in some way, PLEASE let me know. If you want to truly run tests, watch your stockpiles like a hawk... both the stockpile itself AND the stockpile window. Double check amounts, see if there is something specific that occurs each time that causes the problems, etc.

    In my own tests the common issue was the first piece of butchered raw meat. As soon as that item is created, it's put on an already occupied spot in the stockpile which then seems to kind of "corrupt" that spot (or entire stockpile?) causing further problems.

    I've also tested (with dev commands) to see if explosions were causing items to be destroyed, but not removed off the stockpile list. This *didn't* cause any problems, but I'm curious if it's something selenian-slug-related... or colonist-being-interrupted... or who the hell knows what.
    Last edited: Mar 24, 2017
    Rentahamster likes this.
  12. EsBee

    EsBee Member

    0.9.1 Released! https://github.com/SickBoySB/cecommpatch/releases/latest

    • FIX: "Overseer Needed" icon not showing on offices
    • FIX: Beetles (large) don't always produce Raw Beetle Steak when butchered
    • FIX: Aurochs don't produce Raw Auroch Steak when butchered
    • FIX: ICON - Steam Knight Manufactory doesn't show iron ingot icon while building
    • CHANGE: UI - "Ghosted" modules under construction now state what they are in the tooltip
    • CHANGE: RECIPE - Wall-Mounted Aurochs Head is now buildable via the carpentry workshop's decor workbench
    • CHANGE: RECIPE - Wall-Mounted Beetle Head is now buildable via the carpentry workshop's decor workbench
    • CHANGE: Wall-Mounted Auroch Heads are now +3 quality, up from +1
    • CHANGE: Wall-Mounted Beetle Heads are now +3 quality, up from +1
    • CHANGE: New launcher background image for CECOMMPATCH-related info

    The wall-mounted head recipes (and +3 to quality) are up for debate. I tried to make the recipe fairly realistic with the existing materials in the game, so it's a bit expensive compared to other decor. The idea is to make it kind of a specialty item. There's still some to-do stuff with it (in particular the trade value), but it works! One minor note: if you're using an existing save and you try to use bones that are already in your stockpile, it won't work because of how the game's tag system works. Any newly foraged (or new save) bones should work fine though.

    Development may seem to be slowing down, but it's the opposite. The problem is that I'm trying to tackle some of the weirder bugs, and it's taking a *lot* of time to dig through everything. It gets tricky when you're not sure if something is hardcoded or not ;P
    Samut likes this.
  13. Selvah

    Selvah Member

    Your work is really amazing :)
    I'll try to dig into the stockpile issues and tell you if I notice anything.
  14. EsBee

    EsBee Member

    Major performance fix (with tradeoff) in next patch --

    I found that the game's "alarm" system (when colonists see an enemy, they can raise an alarm to get everyone to run away, and get the military over asap) is a major source of unplayable performance. What I mean by unplayable is the slideshow effect (5+ second pauses over and over again) that can occur with larger colonies.

    A temporary fix until the entire system can be rewritten (which may not even help) is to basically deactivate the alarm. This isn't actually too terrible as colonists still run away, military still swarms, etc.... but it means the military isn't quite as all-knowing as before.

    What I mean by this is that colonists on their own won't necessarily bring the military over if they are attacked, fleeing really only occurs for those fairly close to the enemies, etc. During a full invasion you probably won't notice any difference from before (aside from the lack of a major slideshow), but one or two enemies on the outskirts of your colony won't cause the widespread panic that they did previously. I tend to see this as a good thing since it was a bit overkill, but it *is* a departure from the base game and means you may have to use the Rally Squad button a bit more often.

    I do plan to try out a full rewrite to properly fix this issue, but I'm not sure how effective that will be. It may just be that way too much is going on and the alarm system will have to remain disabled.

    Note that this ISN'T something that *completely* fixes poor performance... but it will definitely help squash one of the more severe instances of unplayable slideshows. My test save went from being a guaranteed slideshow of 5-10 seconds per tick even at 1x speed, to being just micro stutters only when using 2x speed. Not too shabby :)
    Samut likes this.
  15. Zakouski

    Zakouski Member

    Man, you are awesome. This thread made me come back to CE, after being strongly disappointed by the editor. May the Cog be with you !
  16. Samut

    Samut Member

    The entire alarm system has always seemed kludged together. There has to be a better way.
  17. EsBee

    EsBee Member

    Yeah I'd rather have it turned into something that is more "word of mouth". Like a colonist running away back to town, telling the military, and them charging out into the fray... rather than some silent alarm bell going off that alerts *everyone*. If I had to guess, I'd say that they were planning to turn it into more of a true 'ring the town alarm bell' system and had only just laid the barest of tracks down to get it up and running.

    If you want to test the difference of having alarms disabled before the patch goes up, go into game/jobs/decision_tree_jobs.xml, find the two jobs called "Military Tree: Raise Alarm" and "Civilian Tree: Raise Alarm", and change

    <require_gameobject input="enemy" amount="1" tag="hostile_agent"
    to something like

    <require_gameobject input="enemy" amount="1" tag="anythingthatcantbefound,hostile_agent"
    Should be lines 132 and 489.

    That will effectively kill the alarms since no entity will ever be considered valid for that check.

    I haven't done much testing of it in small colonies, so I'm not sure how they will be impacted. In my current 50 colonist test save it made a huuuge difference and actually managed to salvage what was otherwise an unplayable save, but I also have enough military to not really have issues with one of them being alerted to an enemy and rallying the others. Smaller colonies *may* have a harder time of it, and may require more usage of manual rally points... not sure. This kind of change is a bit tricky to really see the impact of (outside of blatant performance differences, obviously).
  18. Samut

    Samut Member

    How exactly was the current alarm system causing these performance issues, anyway? Any new system will need to avoid that.
  19. EsBee

    EsBee Member

    I'm not sure. The main script used to handle retreating is the same that causes colonists to run away from, well, anything... so why alarms would cause a problem when normally running away (even in large amounts) doesn't is a bit baffling.

    I have a lot of theories, but nothing concrete just yet. Typical retreating uses the walk_away_from_creature.fsm script to determine the direction and whatnot. It's a bit convoluted and could definitely be optimized, but I don't think that's the actual cause. Clearly something specific to alarms (rather than per-colonist running away) is really broken. I've tried tinkering with other aspects of decision_tree_jobs.xml, but with no luck. The *only* thing that worked was to disable the alarm setting in those two instances.

    The main thing I can think of is that there may be a *ton* of alarm waypoints being created, and the game calculations grow exponentially. It takes 10 ticks of the game before an alarm is cleared (ideally once a second, but in the case of bad performance that means 1 tick per 'slide', aka when the colonists all move a bit then go back to running in place), but many more will be created within that timespan... especially since it may be that alarms are triggered per-entity, per-colonist. So a big colony and a couple enemies means a ridiculous amount of alarms doing duplicated calculations... constantly growing until the threat is gone (at which point the sideshow stops immediately).

    The part that is a little confusing is that decision_tree_jobs.xml seems to limit alarms to some degree. The enemy itself gets the alarm tag, and future 'raise the alarm' jobs will ignore it and not set a new one. BUT the 'respond to alarm' job doesn't look for that enemy or that tag (and instead looks for an actual alarm entity/beacon) so who knows... something is definitely not working as intended either way.

    Not sure if any of that made sense... to nutshell it: I think there may be a difference in setting an enemy as an alarm trigger versus setting an invisible alarm waypoint... and the waypoint(s) is what I think might be freaking everything out.

    Completely unrelated: We have liftoff for freeform stockpiles again! Maximum size is still 7x7 (same as previous 'large stockpile' stamp) as it's hardcoded, but that's a good thing. Woo!
    Last edited: Mar 27, 2017
    Samut likes this.
  20. Samut

    Samut Member

    Thanks for the explanation of alarms. It seems the entire logic has to be rethought. I'll mull over some ideas.

    decision_tree_jobs.xml is weird; it's not clear (to me) if it replaces the military jobs in jobs.xml and so forth, or works with them.