May 24, 2018, 02:46:22 AM

Author Topic: Gnomoria v1.0 RC15 release  (Read 93086 times)

Tacyn

  • Full Member
  • ***
  • Posts: 224
    • View Profile
Re: Gnomoria v1.0 RC11 release
« Reply #225 on: January 18, 2016, 03:33:22 PM »
As I don't know either how Gnomoria currently does or would implement events like that, I just assumed each job is a discrete chunk - flags are rest at the end and everything is happy. What I meant by sacrificing events is like what I imagine is happening now at x256 speed: a gnome decides he is hungry and plots the path towards the well, but the pathing takes too long and the gnome's task is just left for the next frame to handle - indefinitely. You're right, it can cause problems, but if the game is good at cleaning up after itself or ensures that any job started is finished in the same tick (or paused to be resumed if possible), it can avoid such issues.
I imagine the game taking events off a queue, and only handling as many as it has time for. If it does not have time this tick, mark that you ran out of time and then move on to the next tick (leaving the unstarted tasks on the queue, and finishing any that you started).

Except, my example is a case where it can't be a discrete chunk because the actual hauling job (moving to and carrying the item) has to lie between setting and resetting the flag.
If the resetting event is dropped, the item is stuck. There is no such thing as "cleaning up after itself ".

It definitely shouldn't be that the game behaves differently at different speeds or with different hardware ( lag and memory overflows excluded).
How would you ever debug something like that?

Lastly, even if the event queue is dynamic, letting events build up faster than the game can complete them is essentially the same as if the queue is full and events get dropped.
It has to take the time to complete all events before starting the next frame.

Scmadar

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: Gnomoria v1.0 RC11 release
« Reply #226 on: January 18, 2016, 09:29:37 PM »
Except, my example is a case where it can't be a discrete chunk because the actual hauling job (moving to and carrying the item) has to lie between setting and resetting the flag.
If the resetting event is dropped, the item is stuck. There is no such thing as "cleaning up after itself ".
Yes, but there is the difference between my 'event' and yours - I define each portion of a job as a single 'event', whereas you split yours (both are valid methods). As I imagine it, when you create a job to go get an item, in one 'event' you a: set a flag stopping other people from grabbing it, and b: compute the path. Once you grab the item, you a: remove the item from the ground, b: add it to the gnome's inventory or wheelbarrow etc, c: compute the next path (maybe this can be pushed to another event). Flagsetting is done at the same time as everything else; unless you are physically stopping the thread's execution you will never have an issue where flags get set incorrectly. I do see your point though, that sort of thing is dangerous and could be the cause of the current ghost item glitches etc. So, keep actions that must happen together together, and absolutely let the event finish before moving on.

It definitely shouldn't be that the game behaves differently at different speeds or with different hardware ( lag and memory overflows excluded).
How would you ever debug something like that?
Take a dump of the queue and finished events after each tick? The only issue that would crop up is certain events being pushed off to the next tick, they still get completed (just a bit later). Hopefully nothing vital (like drinking water so you don't die of thirst) is pushed off for too long, this is solved by a priority queue or probably other solutions. Or by throttling the game back so it doesn't run as fast, and catching up on the events soon, like in a half a second.

This is only an issue when there is a deep lag spike - the game should be intelligent enough to not run too fast (which was a flaw in my original idea, which you pointed out, and thanks for that. It is good to not go at max speed just cause you can if you know you'll hit a lag spike soon). The problem is the underlying lag spikes, fixing those would alleviate this issue as well - if that's not possible you just do the best you can.

Also, this is a citybuilding game, not a fps or other multiplayer game where everything must sync exactly. It's okay if a job gets done on day1 of Summer on one machine and day2 of Summer on another, because the second didn't handle a lag spike as well as it should have. It does make debugging harder and might make play slightly different on different machines, but as long as it's awfully close it should be good. (it should never even get to be an entire day apart, a few hours at the very most, once again because of the throttling of the speed. Half a second is too much? Try a fourth or less. This is just an idea remember)

Lastly, even if the event queue is dynamic, letting events build up faster than the game can complete them is essentially the same as if the queue is full and events get dropped.
It has to take the time to complete all events before starting the next frame.
Well, no, actually, it doesn't. It should complete all events, but if it doesn't then that's probably okay, as long as it doesn't do it too often.

The event is not dropped per se, because it does eventually get done. The only issue is when it gets done, and as mentioned above it's okay if something is a few ticks late. If that means your gnomes stand around for a few ticks then so be it. There are key differences between what I am describing and Gnomoria as it stands - mine is completely hypothetical (though it should work, I guess), mine would sacrifice the fact that events would all happen right on time for being much more responsive and being able to scale time back as necessary, and mine would scale itself back if it finds an issue. The key point being the scaling back: if it is running too fast and the queue is not empty when the next tick starts, it will slow down and empty the queue. (what happens then is up to the programmer, or perhaps user if this is set in config files: either speed up again to go as fast as possible, or go reasonably fast so you don't get many events pushed back, or go at a slow but safe speed so no events at all get pushed back.)

edit: grammar
« Last Edit: January 18, 2016, 09:31:22 PM by Scmadar »

Chatmetaleux

  • Jr. Member
  • **
  • Posts: 55
    • View Profile
Re: Gnomoria v1.0 RC11 release
« Reply #227 on: January 24, 2016, 01:55:39 AM »
I have 5 piles of dirt that cannot be sold to market nor picked up by any hauler. Should I post the game or should I just ignore it?
You can use my addon trick to "fix" the ghost items...https://github.com/Chatmetaleux/YAGE


---
Btw, RoboB0b, i'm getting a game crash (NullReferenceException) in RC11 when deconstructing any handcrank...

Roboute

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #228 on: February 02, 2016, 02:50:52 PM »
Oooh a debug mode, I think I am really going to love that one.
No more playing for years to test out new late-game stuff in my mods :)

Dommain

  • Newbie
  • *
  • Posts: 23
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #229 on: February 07, 2016, 07:30:37 PM »
Oooh a debug mode, I think I am really going to love that one.
No more playing for years to test out new late-game stuff in my mods :)

Crashes every time I try to load a world, not sure I am using it right.

vosechu

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #230 on: February 08, 2016, 11:12:06 AM »
Yay! Thank you so much RoboBob! I was beginning to worry that we hadn't seen you in a couple months, but I see that it was entirely unfounded.

Thank you so much for making this amazing game. I've been playing it so much and I really, really love it. I feel like you've really captured the essence of DF, made it a little more playable, made it a whole lot more beautiful, made it much more mod friendly, and then went on and made it special and unique to boot. Thank you so much!

DwarfwithFakeID

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #231 on: February 09, 2016, 09:01:08 PM »
The spawner is awesome!  Strawberry Anvils for the win!

Anyone up for figuring out a way to spawn water/lava etc?  I mean, it'd be super-useful for debugging this random water issue, which really, oddly enough hasn't been happening as much now.  It could be just a rounding issue going negative.   Before, it was FLOOOOOOD city but now that I've sold off a lot of the stuff @ the bottom of the lakes, it doesn't happen as much now.  Hey wait, I can spawn stuff @ the bottom of the lake so... here goes *backs up save games*.

gNoMore

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #232 on: February 10, 2016, 04:57:01 AM »
Any results where you get the flooding to happen again, Dwarf? I was surprised not to see the water bug mentioned in the fixed list for RC12.

RoboB0b

  • Administrator
  • Hero Member
  • *****
  • Posts: 1036
    • View Profile
    • Gnomoria
Re: Gnomoria v1.0 RC12 release
« Reply #233 on: February 10, 2016, 09:10:22 AM »
The spawner is awesome!  Strawberry Anvils for the win!

Anyone up for figuring out a way to spawn water/lava etc?  I mean, it'd be super-useful for debugging this random water issue, which really, oddly enough hasn't been happening as much now.  It could be just a rounding issue going negative.   Before, it was FLOOOOOOD city but now that I've sold off a lot of the stuff @ the bottom of the lakes, it doesn't happen as much now.  Hey wait, I can spawn stuff @ the bottom of the lake so... here goes *backs up save games*.

I have spawning and removing liquids in already for RC13 :)  I'm still hunting down issues with flooding.  Any additional info you find out is appreciated, thanks.

DwarfwithFakeID

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #234 on: February 10, 2016, 12:48:00 PM »
Flooding only happens when water bodies have lots of just-started-my-kingdom stuffs like clippings, dirt piles, and other stuffs laying in the bottom of them.  I have some saves - though I did mod things a bit - this still happens in the default game.  I have one world where it happened so bloody much every time it rained I created huge pits and was able to fill the lava cavern at the bottom up to level -80-something ... yes, I have lots of obsidian now.  Thank goodness I bought an i7 4790k for the water issues... though I need it much less now with the better optimisations (thank-you sir, from myself and my AMD FX-cpu bearing friend).

Doesn't matter how often it rains, or how deep the water is, if there is stuff in the water, it bugs out if there's stuff in it (the more the 'merrier').  If you have a tile with a few hundred things (not out of the ordinary if you've got a large body of water that pool misc stuff into one spot, like into a drainage ditch) that actually gave me like 672,000 % water, I have steam screenies of it - it pretty much ended the world hahahaha - it flooded up to floor +20 or +21 and my ground was @ 0 (I had a backup, just incase). 

Your game is quite entirely awesome.  I will be starting a new kingdom soon.  I am sure I will encounter extreme flooding again, but don't view this as a complaint... I honestly have come to enjoy it... so in reality, I will miss it if you take it out, because 'monsoon season' introduced a new challenge to the game, one that it didn't have before!  It made the game fun again, because it gave me a reason to hurry up and mine deep and create huge construction projects for my gnomes to survive.  The floods were so frequent on the last kingdom that literally some would start before the last one was over.
I have what is approaching 5500-7000 hours on it (guestimate, offline time not recorded, 2800 hours on this steam acct, 2200 + on my old one, + 1000 hours of offline time or more). 

I would seriously suggest that you try and make yourself some raw obsidian walls, and find out why gnomes are dying getting stuck on it, the pathfinding algorithm doesn't consider RAW OBSIDIAN walls a blocking object and gnomes get stuck & die there.  They get unstuck if someone mines the wall out, or the task is cancelled and they TURN AROUND.  If they have to path through it, they get walk into it and stick to it.  Obsidian floor doesn't do it though.  This bug has existed for quite a while now.  I think it's due to the fact that the game still thinks it's liquid from when it was lava (or water, as you need both to make obsidian).  Thanks!

You will be able to make lava on your new spawner update so you shouldn't have any issues checking this out.  --Great game and hope your youngin' had a happy birthday last month.

Nemeis

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #235 on: February 11, 2016, 03:33:15 AM »
From my own battles against flooding, it seems to be related to water bodies 2 or more levels deep where part of a lower level is covered by dirt/stone etc.  A gnome-made underwater pool I made that had a very small opening was so bad it crashed the game when it erupted (it was triggered by rain). Looking through the water tiles as the flood progressed, those with a dirt floor above rapidly reached 3000% or more. Smaller, natural bodies of water that only had a few tiles under solid ground produced much smaller floods.

Possible explanation: a bug in how it calculates water pressure (percentage) based on water in tiles above might make it confused if what is above isn't actually water.

As a side note, I spent a lot of time making duplicate saves and trying to defuse the water bomb, failing, and reverting the save.

DwarfwithFakeID

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #236 on: February 11, 2016, 07:11:56 AM »
I have had this sometimes from well usage + rain ... sometimes (rarely) from just well usage itself.  Usually always with some type of clutter in the bottom of the pond.   The one time I ended up with 672,000 % of game-ending water in one square (which quickly covered the whole map in about 10 mins)... it was where there were several hundred pieces of clutter in one spot.  That is THE common denominator I've found in my games.  Seems like it bumps the stuff, that 'bump' multiplies the water density... or something like that, so if there's 100 of the there, it happens 100 times (?), or 1000 times if enough items laying about, and would cause that.  Only thing I can think of is it's checking the water density twice and compensating it twice on the same tick (or more than twice - one additional time for each item!).  I have spawned items without success to make it act up, however, it does make the water more restless to have items laying in it... they tend to slosh the water about - it SEEMS that way.   That might be the catalyst in the whole deal.

Nemeis

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #237 on: February 11, 2016, 08:36:46 AM »
I have had ponds with no clutter in them flood. This means clutter is either not a cause at all, or one of several causes. Perhaps RoboBob could let us know, but do items in water (or in general) ever come up in the methods that update water amounts?

Usually always with some type of clutter in the bottom of the pond.

Is the map (or its ponds) generally covered with clutter? If so, regardless of what the cause is there would usually be clutter in the pond. Which really just means we need more data.

To put it in numbers, if around 70% of the ponds have some kind of clutter, we would expect around 70% of the ponds that flood to have clutter, if the two aren't related.

Edit: having had a chance to experiment a bit, I'd like to share what I've gathered:

start-normal size, peaceful, no mods, debug mod enabled. terrain set to be as flat as possible
debug used to spawn supplies leaving gnomes free to dig/build etc.

the following tests were performed:
clutter- spawning items in a single tile in the water, then causing the water to move (draining it)
            causing the water to move, then adding items
            items present in several tiles, then draining the water

terrain- create various underground pockets of water, then drain/disturbe them
            partial covering of a water's surface, then drain/disturb it.

not tested: adding water to a pond/lake with any of the above circumstances.

results: no conditions (or combination thereof) reliably produces a flood. Anytime a flood would occur, reverting the save and repeating the conditions would usually just not create a flood. either the bug is just really finicky, or its entirely unrelated to all of this. Either way, I'm out of patience.

« Last Edit: February 12, 2016, 08:12:56 AM by Nemeis »

DwarfwithFakeID

  • Newbie
  • *
  • Posts: 27
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #238 on: February 12, 2016, 05:38:10 PM »
There is a mathing error occurring somewhere.  Something that happens causes 1-140% of water (usually) to become 5000-9000% usually in the 1st minute.  Sometimes it can become 11,000%, or there-abouts... one or two times it became 252,000%, and one time it became SIX HUNDRED AND SEVENTY THOUSAND PERCENT.  Lots of moving water will do this.  I think for some reason it's ending up multiplying the water vs adding it.  Try increasing your viscosity of your water, it'll cause flooding to happen more (as the water moves more, this bug only surfaces [heh] when water is MOVING, so we'll make it happen more by increasing water's viscosity).  This increase will also help your water find it's level a bit better.  I know one time I filled a cavern that went down to -34 or so, with water, all the way up to -1 and then it began to explode randomly, that caused a lot of issues.  I think i'll go uncap it and see if I can get it to reliably explode.  It's possible the water could have two directions of current moving around it at once.  This used to happen when it was raining for years now, so it's possible it's the same bug as when two raindrops would collide.  I have a good luck with making floods occur regularly in this game so time to make a new world.
The more viscosity the water has the more it moves, make your water more liquid and it'll do it more often.  To that end, is why you don't have lava doing this (GOOD THING!)...

Tacyn

  • Full Member
  • ***
  • Posts: 224
    • View Profile
Re: Gnomoria v1.0 RC12 release
« Reply #239 on: February 13, 2016, 02:24:06 AM »
Have any of you tested this with different game speeds?
Does it flood more at higher speeds or is it the same?