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

Some of the jobs in jobs.xml aren't used. They tend to be called specifically.. whereas decision_tree_jobs.xml is a kind of mini-list that is typically called in groupings. A lot of the instances that I've seen that call the decision_tree are stuff like "run the entire civilian tree".

It is indeed a bit confusing though. Especially if you start looking through the other job xml files haha. There's a LOT of stuff crammed in little corners, and which ones are actually used is a tough to figure out. To make it even weirder you have the workshop edb files that have 'standing order' options that don't correspond to any job and cause errors in the console.txt... but changing that doesn't fix it. The public house is the prime example. The mine throws errors all the time too, but that job *does* actually exist. The REALLY baffling part is that both the public house and mine seem to function just fine, so what job they're actually using is beyond me... I'm starting to think their unique functionality is hardcoded.

 

Good to know; thanks.

Do you think the decision_tree file itself can be changed without breaking it?

 

For sure, though *removing* jobs completely (rather than just disabling/changing their triggers, or adding totally new stuff) may cause unforeseen problems if they are ever called manually elsewhere. The game doesn't like when you call a job name that doesn't exist. I also have a feeling that greatly expanding the decision tree may cause all kinds of performance issues since every job runs evaluations when the tree is executed. But changes are certainly possible

Did you have any specific ideas on what you'd want changed?

 

A billion - too many to go into without derailing the thread.

I have an idea for a new alarm system; it's a little complex but it might work pretty well. I'll write it up and post it in a new thread.

 

I'm stoked to see this! However I am running a Mac (latest OSX) - I tried adding the patch files in as suggested and get a crash immediately on clicking "start game" - am I missing a step or is it just not tested to work on OSX?

Thanks again - happy someone is picking up the torch.

 

I have no way to test on OSX, unfortunately, so I'm not sure how well it will work on there. If 1.0D works fine normally, then either the patch wasn't installed correctly or there is indeed some kind of problem with the OSX version using my changes.

I'm *extremely* ignorant of OSX stuff... is there a chance my usage of 7zip to zip up the patch is corrupting the file for you? You may want to try opening them up and seeing if they look like normal text files. If there is a bunch of jibberish, or if they are blank, then that may be what the problem is.

 

Thanks - I'll try a couple of things and see if I can get it to work. The files all seemed fine, as far as I know (which is not far. Not far at all....)

 

OSX UPDATE: I reinstalled the game and then made sure to follow your instructions for the patch exactly.... and it worked! Works great, actually.

 

Oh whew! I had nightmares last night about this, no joke. Granted they were more in the vein of someone hopping on board to help fix the OSX stuff and totally screwing up the current github flow because they forked master rather than v1 or the current in-progress 0.9.2 branch... made more annoying by the looping effect fever dreams cause (soooo sick at the moment).

VERY glad to know it works though!

 

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

Sorry for how long this patch took. Between two different family visits and getting super sick, it has been slow-going. Still sick, but no family-related stuff for a month so hopefully 0.9.3 will be quicker. Anyways, here's the usual patch info:

• FIX: Trade confirmation/cancel buttons off the screen at 720p
• FIX: Commodities menu off the screen at 720p
• FIX: Jobs menu off the screen at 720p
• FIX: Population menu off the screen at 720p
• FIX: Population menu has useless bar at the top
• FIX: Farms can't be demolished (0.9.0-caused)
• FIX: Major performance drain when colonists set an 'alarm' on an enemy
• FIX: TAG - Brass Cogs aren't used in the chapel
• FIX: Gravestones aren't aligned properly
• FIX: Chapel uses old demolish text
• CHANGE: Stockpiles are freeform. Maximum of 7x7 for each stockpile (hardcoded)
• CHANGE: "Well-Fed" changed to "Well-Fed But Unsated" to reduce confusion
• CHANGE: UI - Reskin - Commodities menu
• CHANGE: UI - Reskin - Jobs menu
• CHANGE: UI - Reskin - Faction menu
• CHANGE: UI - Reskin - Population menu
• CHANGE: 11 new gravestones (mostly unused fence posts)
• CHANGE: Graves are randomly rotated (slightly), to give some variation
• CHANGE: Graves have a tooltip
• CHANGE: Graves state who is buried there in the tooltip
• CHANGE: Gravestones are randomly selected based on social class, citizenship, and whether they were military or not
• CHANGE: Graves have 37 (and growing) different epitaphs that can be chosen from, shown in the tooltip and based on various factors of the deceased

NOTES: Grave and graveyard-related changes only apply to new graveyards. Also while there is a fix regarding gravestone alignment, you'll notice that the new gravemakers are misaligned in comparison to the old ones. This is a model-related issue and the only solution is remake them manually. At some point I'll do this, but for now we'll just have to deal with it.

 

Oh my God, those changes to graveyards are fantastic.

What file are the epitaphs listed in?

 

scripts/gameobjects/grave.go has the epitaphs currently (at the top.. it's a custom local function). I can't promise they're any *good*, mind you haha. Had some pretty bad writer's block when I was trying to come up with them, so they're fairly lame at the moment. The logic is pretty basic as well. I plan to expand it a bit at some point and involve other factors of the deceased... like how they died, etc., but for now it's pretty simple. Anything tag-related can be used to figure out what epitaph pool to pull from, but right now it's just a coin toss as to whether it is pulled from the "all" group, or the social-class-specific one. Kinda like how I did hats... but even simpler.

If you (or anyone) wants more or wants to change some, just make a big ol' list and I'll pop them in there (just let me know what pool to put them in). This is the kind of stuff I'd love to have help with since the more variety the better.

And in case it isn't clear, the "%s" is a placeholder for where the name will go.

 

Regarding using how a colonist died for the epitaph, how is this stored? One of CE's problems is there's not enough information in one place so it can be used to guide actions.

My thought was some table(s) that would track things like who's being attacked and by whom, how and when dead colonists died and who killed them, who's sleeping, eating etc.

 

Well in terms of cause of death and all that there's already plenty of logic in citizen.go (as an example) that handles it in the deathBy() function. Popping in a few new tags to be attached to the corpse would work pretty well to then be used in epitaphs or whatever. Currently most of the logic is just used for adding memories and the like, but it seems like it'd be pretty easy to just add tag usage to it. A totally new table might be tricky because of how saving works, but custom tags (which are already a table that is saved and fully featured) would work pretty well I think. Would take some experimenting to figure out the capabilities of it of course, but I think it'd be doable.

A lot of the advanced methods for finding out who is doing what, etc. is to utilize the query system. It's a little tricky to get used to and takes a LOT of fiddling around with to get working properly, but that's how I get the corpse's info to begin with. I just query anything with the corpse tag within a very small radius and the needed info is re-queried from the resulting info. This is how a LOT of the game works, and there are quite a few different querying methods.

Here's an example (it's how I get corpse info):

Code:

       local results = query("gameSpatialDictionary",
                         "allObjectsInRadiusWithTagRequest",
                         state.position,
                         1,"corpse",true)[1]
 
       if results then
           grave_who_tags = query(results[1],"getTags")[1]
           grave_who = query(results[1],"getName")[1]
       end

The danger with my code is that there *may* be instances where the wrong corpse info is pulled. I tested a bunch and never had any instances of it (the amount of citizens I murdered through dev command-spawned explosions is terrifying), but if it does occur I already have ideas on how to fix it. A better solution would have been to pull the info directly from the job itself to guarantee the corpse's info, but that was turning into a rabbit hole for something that really didn't need to be overly complicated. At some point I will attempt to do it "properly" again, as I think a lot of really cool functionality could be done with the extra info that would be attained... like events based on who buried someone. That'd still be technically doable with my method, but it increases the risk of wrong data being passed.

Anyways, querying works like a simplified SQL query of sorts. It's hardcoded to an extent, but utilizing existing systems (in particular the verrrry robust tags system) means we can do pretty much anything with it. The danger in overuse of queries is performance... but there are other variations that exist that seem to be designed for more optimized searching.

I'm not sure how well a "live" system of query results would work though. For instance: to constantly query who is doing what at any given moment would probably explode the game. Preeeetty sure that's why the population menu kills game performance. But triggering it at specific moments isn't too shabby, and a more sane way to handle it anyways. "Live" querying doesn't really work in database searching systems, after all. Most of the "live" stuff in web development is clever trickery to make it seem like that. Chat-related stuff is probably the closest to "live", but that's either done with intelligently timed pulses to check if anything new was sent (ie 'shoutbox' style), or straight up socket connections... which isn't really applicable here.

That said, finding out who is currently sleeping, as an example, would be very doable I think. I haven't looked into whether sleeping adds/removes tags, but even if it doesn't new ones could just be slapped on there to achieve the same thing.

 

0.9.3 is going to have some UI rearranging, and I'm looking for input. I've removed the little mini-buttons from the bottom-middle (next to "assignments"), made a new bottom-left menu category, shuffled a few things around to be more logical, and added a new "rally troops" command. Turns out 1.0D either broke or intentionally changed "rally squad" to make it call all soldiers... meaning the barracks-specific button wasn't necessary and more just a pain to get to.

Here's a screenshot to show off the changes. Ignore the green circles.. they're added in Photoshop just to show what menu was clicked to show the submenu.



Thoughts? The new menu is meant to be "commands" menu rather than placeable objects.. hence why certain options were moved to that one. As for moving the farm menu: just seemed logical to have all the building/workshop stuff on one side and weirder commands on the other.

I realize that removing the mini-buttons means you have to do an extra click to get to those commands. I *could* keep them in both spots, but I'm trying not to have redundant commands. I had originally wanted to put "rally troops" on the mini-button bar, but turns out it wasn't closeable with ESC when I did it that way. Having it in a proper menu works just fine. If there is enough desire I can add the mini-buttons back... but those always felt really out of place to me.


And totally unrelated: I got exterior decor working! None of it was giving a +1 to quality, but it does now... and it also gets built where the ghosted version shows, rather than going up a few units and clipping into the roof

 

Wait - so the rally button now rallies every soldier in your colony? There's no way to rally individual squads?

Also, does this rally marker expire over time? I recall the last batch of "improvements" put a timer on them.

 

Yeah rally beacons call every troop instead of per-barracks. Not sure if that change was intentional or not on GG's part. I could look into changing that back to per-barracks if desired, but I'm not really sure if it'd be doable on my end... seems like it might have a lot of hardcoded-related stuff, especially with how UI commands work. I'm still trying to figure out if I can make custom commands (in particular a 'bury/dump corpses' stamp), but that behavior is kinda weird and it may all be harded.

And yes, the rally expires over time. Too quickly, in my opinion, but that's on my to-do list to find and change. I think it's just a session variable so it should be an easy change. I don't plan to try to make it infinite as that requires too much micromanagement (made doubly annoying by the hardcoded cursor highlighting hierarchy), but the timer should definitely be increased. I'm thinking maybe 2x what it is currently as beacons often expire before troops come anywhere close to reaching it, even if it's not that far off.

 

It's that time again...

0.9.3 Released https://github.com/SickBoySB/cecommpatch/releases/latest

• FIX: Exterior Lamp (Lamp 00) not giving +1 quality
• FIX: Exterior Lamp (Lamp 01) not giving +1 quality
• FIX: Exterior Lamp (Lamp 02) not giving +1 quality
• FIX: Exterior Lamp (Lamp 03) not giving +1 quality
• FIX: Exterior Lamp (Lamp 04) not giving +1 quality
• FIX: Barometer not giving +1 quality
• FIX: Large Pipe and Valve not giving +1 quality
• FIX: Vent not giving +1 quality
• FIX: Pipe Cluster not giving +1 quality
• FIX: Pipe Cluster only needing 1x width when the model needs 2x
• FIX: Exterior decor placed higher than ghosted version when built
• FIX: Trade office showing the "overseer needed" icon
• FIX: Craters have a large, dark square around them
• FIX: Iron oven door animates opening and closing infinitely when not in use
• CHANGE: Farms and Zones/Constructions (menus) positions swapped to be more logical
• CHANGE: New "Commands" menu created
• CHANGE: Chop, forage, mine, clear, dismantle objects, and flatten commands moved into new "Commands" menu
• CHANGE: "Rally Troops" command created and added to new "Commands" menu
• CHANGE: 16 new paintings (unused GG assets) have been added to the game
• CHANGE: Slight rearrangement of module filters
• CHANGE: "All Art" module filter added
• CHANGE: New paintings added to the "All Decor" and various housing module filters
• CHANGE: The "Republicain Artist" event rewards have been reworked, adding in the new paintings and the mounted beetle head
• CHANGE: Novorus trader item pool given 'common' tier of paintings
• CHANGE: Stahlmark trader item pool given 'uncommon' tier of paintings
• CHANGE: Republique trader item pool given 'rare' tier of paintings
• CHANGE: All trader item pools given the mounted-head items
• CHANGE: Mounted-head items' trade value increased to appropriate amount
• CHANGE: Replay creation turned off to save a bit of processing (only impacts new games)
• CHANGE: Rally Squad timer increased from 20 to 40 seconds
• CHANGE: ALARMS RE-ENABLED!!!
• CHANGE: Steam Knights won't respond to alarms (temp fix for critical performance issue)

Notes:
The fixes to exterior decor modules won't be obvious if you've already placed some in pre-0.9.3 saves, at least until you add/remove at least one quality-impacting module so that the quality calculations are re-triggered.

 

Have alarms been changed, or are they working like before?

 

They are working like they did previously. I do plan to revisit how alarms work at some point, but the re-enabling of the old system was necessary because the lack of alarms was pretty crippling to gameplay... and I found a better temporary fix that allows them to be re-enabled.

It turns out the major performance drain wasn't from the alarm itself, but from Steam Knights' reactions to it. Their node usage for pathing went from 2000 to 250000 per tick when running the "respond to alarm" job, which completely obliterated the time between frames. Not sure why and there wasn't anything obvious in steamknight.go, so it's going to take more time to figure out exactly what the problem is. It *may* actually be a hardcoded problem, but we'll see.

In the meantime I re-enabled the normal alarm system and just put in a case to make Steam Knights not respond to it. They're so slow it doesn't make much of a different anyways They still shoot anything in range and can still set alarms, they just won't actually be assigned the "respond to alarm" job until I can figure out what is making their pathing logic go ballistic.