Messages

You don't calculate distances with flood fill. You just add 1 as you radiate out from the target. It assumes only horizontal and vertical movement though. To make it accurate it would have to add 1.4 diagonally. This makes things more complicated because the list wont remain in order just radiating out. You would want to avoid sorting but I think if you work out the right way to do it you could keep it in order without having to sort. I've been working on it. Here is my pseudo code. I'm using horizontal/vertical distance as 10 and diagonal as 14 because I assume using ints is better than using floats.

Code Select Expand

Starting with an open list of nodes, let's call it ol, with x,y and dist value                       
And closed list that is an array for easy reference cl[x,y]=dist                       
Assume ol has function add (int x, int y, int distance)       
               
ol.add (endNode.x, endNode.y, 0)                       
while ol. count != 0                       
    curDist = ol.getFirstItem.dist                   
    ' Do horizontal and vertical neighbors with dist values from curDist to curDist + 4                   
    for each node in ol do                   
        if node.dist <= curDist + 4 then               
            Get horizontal and vertical neighbours that are not on closed list or blocked           
            Add them to open list adding dist as curDist + 10           
        else               
            break           
        end if               
    end for                   
    ' Do diagonal neighbours for curDist only. Remove from open list as you do them.                   
    while ol.getFirstItem.dist = curDist                   
        Get diagonal neighbors that are not on closed list or blocked               
        Add them to open list adding dist as curDist + 14               
        remove first node from open list and add to closed list               
    end while                   
end while                       

I don't think there is anything there that is to complex so I'm hoping it wont take long to do the whole map. Then instead of using the Manhattan distance for the heuristics ie. abs(startNode.x-endNode.x) + abs(startNode.z-endNode.z) you can use the value in the closed list cl[endNode.x, endNode.y].

On another note I think I found in the vanilla pathfinding where it uses the Manhattan distance.

Code Select Expand

this.h = this.heuristicStrength * (Mathf.Abs((int)this.neighX - this.destinationX) + Mathf.Abs((int)this.neighZ - this.destinationZ));
Technically speaking the Manhattan distance assumes only vertical and horizontal movement. It should really be something like
x = abs(startNode.x-endNode.x)
y = abs(startNode.y-endNode.y)
max = Max(x, y)
min = Min (x, y)
heuristic = max - min + (min * 1.4)

It probably could be done more elegantly than that but I wonder what difference just this one change would make.

Ok I've been raking my brain trying to wrap my head around pathfinding for the last couple of days and I've come up with an idea. I don't really have the ability or drive to test it out so I thought I'd mention it here so better experts than me can pick it apart.

The main problem I see with A* is when you have dead end areas and it checks every square in that area before it exits it to continue on. The cause of this is the heuristics generally don't take into account the obstacle. There is also the problem of simitry but I'm not sure if it's an issue with variable weight terrains.

I came across Jump Point Search algorithm which looks like it's super fast compared to A*. The downside being that it assumes a uniform terrain. But I thought to myself, there has to be a way to use it's speed to improve A*. I thought to myself, "Improved heuristics can improve A*. Heuristics ignore terrain weight. JPS ignores terrain weight". So is it possible to use JPS somehow to make a grid of optimal paths quickly then have A*s heuristics use those JPS paths to come to a more accurate heuristic? If so, I would expect A* to pretty much follow the optimal path right off, saving a lot of time. This assumes that calculating the JPS paths would be faster than the time saved.

Then I thought of another variation of this idea. What if we used flood fill, I think it's called. If we can quickly make an array of of flood fill values from the destination (ignoring terrain weight of course) then use those values as the heuristics then again A* should follow the optimum path immediately instead of going in those dead end areas.

What do you think? Is it worth trying? Or am I just talking shit?

I have no idea what it is. Funnily enough I found it on a forum where they are doing what we are doing. https://forums.oneplus.net/threads/juego-1.13321/page-306

My sister married my cousins husbands brother. It seemed weird at first but you get used to it. Makes our 2 families very close being joined at 2 places as it is.

Technically speaking I don't think it's actually wrong to marry someone who doesn't share blood and is related to you only by marriage. I couldn't even find any information on the web about sibling in-law marriages (which is what I think you are talking about).

5198

That's so funny.

I understand that there is an argument to be made for leaving it as it but I think it would be better changed.

The way it is now you have to accept pawns wasting a LOT of time continuously changing gear (with the associated extra cpu use) or do lots of micromanagement. I'd prefer less micromanagement and less pawns wasting time changing gear.

The way I understand the equipment tab is the pawn should be happy with anything that falls within the parameters and that's the way I'd like it to work.

If vanilla isn't changed I'd like to at least have a mod for it.

Wow... Nice.

 Zhentar did you ever do anything with the jobgive OptimizeApparel? I saw a reference to it in an older version of tweaks.

Ok, necroing an old post but it is on topic.

If you don't want your colonist who is walking around with a 55% jacket beelining to grab the fresh new 100% jacket your tailor just made you have to Forbid it.  Then when you see a colonist with no jacket unForbid it and let him wear it.

I don't mind a colonist changing a 55% clothing for a 100% one. What I find really annoying is when they change a 55% one for a 56% one. Then a little later they change a 54% for a 55% one. It also interferes with trying to restock another colony. If you add a 100% top to a cargo pod, someone will invariable put it on before it gets loaded onto the pod. So ok, now there is a 95% top, so I'll send that but again, someone else goes and puts it on. You basically have to wait until everyone has had a chance to switch gear before you can load the pod. Then all you have left is a 55% top. So you make another 100% top. You wait until everyone has had a chance to change gear and you are left with a 55% and 60% gear. So you send the 60% top to the other colony which doesn't last very long because it was low to start off with so you have to repeat it all over again.

Also, I like to have stockpiles with filters to keep an eye on my good gear. So for example I have a 2 square stockpile for 51-100% tops. When I see less than 2 top in it I make more. What happens with vanilla is it takes longer for that stockpile to empty but when it does, it means every colonist has lower % gear on and are about to loose their tops. So suddenly you need to make 30 tops, one for each of your 30 colonists. If the colonists waited until their tops dropped below the set % range then you would be making tops in more regular intervals which is a lot easier to manage and it would be a lot easier to send better stuff to restock other colonies.

Now, I seem to remember that a mod did something like this. I remembered reading something like "and colonists don't mind wearing lower % gear and generally will change them once below about 60%". Does anyone remember what mod it was?

It would be nice if tailoring was a separate skill from smithing. My dilemna right now is I have only one or two decent crafters, and there are too many things to do. He needs to make parkas(which take a long time), but he also needs to make weapons and armor. Later in the game, he MUST be working on components. But then he can't work on weapons and armor or new clothes. It just seems like the crafting skill encompasses too much, and it'd be nice if it was split up.

Huh? Tailoring is separate from smithing and crafting.

Adamiks is an artificial intelligence created by a madman! Luckily, he's on our side.
5163

Well we can hope.

5164

Nah, he has an algorithm that can simulate saying something funny depending on what was said. Sort of like those text bases programs that used to respond to what you typed in.

5162

Core
HugsLib
MineItAll
Zhentar's Vanilla Tweaks
Numbers
Medical Tab
JTReplaceWalls
JTZoneButtons
Trading Spot
AC-Enhanced Crafting
Area Unlocker
Blueprints
QualityBuilder
Haulpriority_lite
New Zone Tools
I Can Fix It
RimFridge
Industial Rollers
CaravanSpot
Mod List Backup
Refactored Work Priorities
Step Away From The Medicine
Crate
Fresh stockpile filter
Storage Search
Where is Potato soil
Where is rich soil
JTExport
Refugee Stats
Static Quality Plus
HuntersSpot
Realistic Darkness
ExtendedStorage
Follow Me

Wow I forgot about some of those. Must remember to use them.

I know! He's a robot. Never takes offense and unfailingly keeps churning the numbers out while making sure not post twice in a row. Yep definitely a robot.

5154

Really? I thought maybe he has a program set up to automatically post every few hours, but your explanation makes sense too.

5148