Messages

Heh, I guess we derailed too much

I should have known better, i just really like the idea of multithreading 

Just curious, since we have a thread for this now, where's the multi-threading happening? My initial go at this would be to have the rendering engine be one thread and the backend/updating part broken down into multiple consumer threads with some type of load balancing (round robin probably assuming everything takes about the same amount of time to update)

I don't have the ability to really profile the code and see where it's needed, so I'm just doing at the main game update loop. In particular, I'm splitting threads in the TickList.Tick method. In there, there's a list of every object that has some update to do during a tick. In single threaded mode, it loops through each one. Currently, I make 8 threads (subject to change) that take an object, do it's tick work, and then return and grab the next one. It's using a thread pool too, so no need to worry about constant instantiation of threads.

> (It'll be able to handle reverse patching correctly then).

What is "reverse" patching in Harmony? I haven't seen a discussion of it.

Reverse patching is where you want to patch your own method with the code of the original method, and then change the code of the original method to call the new function. Currently, I have to copy the original function's code during code time (as in when I'm writting the mod) rather than runtime, so I break compatibility with other mods and my code will break if the original code changes with a new version of Rimworld.

I copy the function so I can run it inside of a new environment: there are a few objects that run algorithms that use member variables to store algorithm state, and only 1 instance of those objects is created (such as pathfinder, only 1 per map is created). To create thread safety, either I lock up the instance (which is bleh), or I create new instances of the object and send calls to an instance manager that holds those instances.

I'm not the best at communicating sometimes, hope it helps. I was introduced to the term here: https://github.com/pardeike/Harmony/issues/41

Heh, I guess we derailed too much

He hasn't released a new version as of late, but he has been active on the github project and I believe he is preparing to release a new version. So a new version, barring unforeseen hurdles, should be out sooner or later. For now, I can keep working... by completely destroying the ability for other modders to touch the functions that I am touching ;p

I should add that I'm still completing my degree, and so progress is dependant on the amount of homework I have to complete in addition to my day job.

> Multi-threading is being worked on by a modder, but we'll have to wait and see if it pans out.

I wouldn't hold my breath. That level of surgery; I'm trying to fathom how it could be trusted with direct, real modification of the original core.

This^

The game's logic relies on linear execution. Heck, most mods that have an assembly.dll (ie have C# code) will probably break too. I know without a doubt some of my mods would break as they assume linear execution.

The easiest path of multi-threading i can think of is each pawn is updated on a set number of pawns. Once all pawns are updated the threads are suspended until the scene is rendered -- the could continue to update the pawns but it's questionable if there's any benefit there. This can become at the time of rendering too. I'm not sure about unity or the modifications the Prison Architect team/Ludeon have made to the engine whether it's thread safe and (if it is) if it uses lock-less threading support. If not that's going to cause a ton of thread-waiting. In the long run multi-threading may not buy anything at all.

Another possibility is to launch a new thread when a UI element is created to run it - though if the UI element changes the state to anything in the other thread, watch out as most of the game's code does not do null checking and assumes certain objects are always assigned to/in a certain state without actually verifying that they are before using them

Can think of the choice between single- or multi-threading as the foundation to a new building. Once it's laid there's no changing it. If it must change it can be hacked together. It may work but it would have been a whole let better to have started off the other way in the first place -- it may have actually taken less time/money to have started over than to redo in the long run.

I'm actually the one working on it. It's really not that hard to get threading going, as Tynan did a good job with error recovery. The main issue I'm dealing with at the moment is going through all of the different non-thread safe elements and making them thread safe. I'm also somewhat bottlenecked waiting for the next version of Harmony (It'll be able to handle reverse patching correctly then).

No need to worry about scenes or anything. The main lag is the update loop, not the graphics, and the graphics always waits on the update loop to finish (with some exceptions I believe, steam gysers do some weird things in thier tick with sounds that I've yet to diagnose). There's a loop that goes through every element in the game that has work to do in a "tick". I've simply made that work be put on separate threads.

Methinks a lot of people try to complicate multi-threading a bunch. The game is already multi-threaded, between updates and the UI, as is normal for anything with a UI.

Multi-threading is being worked on by a modder, but we'll have to wait and see if it pans out. The main question is whether the game will run better after all of the non-thread safe elements of the game are modded.

Even if multiplayer won't ever be implemented, it's foolish to combine the thread still. Search functionality loses value if the searcher can't find a thread with a topic relating to thier question. So a new thread is made. Then moderators have to waste time merging. Then another thread is made with the same question because the next person couldn't find the answer.

Allowing more than 1 thread reduces work and maximizes the functionality of the search engine.

Now, if there are two concurrent questions that are generally the same, that are relatively small (<5 pages) it's fine to combine. But the "one thread to rule this entire subject" is inefficient.

But what is the point of a thread of dices sion if it has more than discussion in it?

Having dozens is not bad of threads is not bad. Have a question about how multiplayer might work? There's a thread for that. How about what whether it will be in the game? Another thread. Question about who would be interested? Another thread.

Having a super thread for the subject makes information gathering hard and oppressive. You have to read 17 pages, find that your question is not there, ask it, have the question moved, then nobody looks at it because: 17 pages.

"One spot" is awful. You wouldn't, for instance, write all of multiplayer functionality in one function. Why would we limit ourselves to one thread about such a complex subject?

We play lots of games. Some of us contribute to lots of games and use various forums. May I suggest something?

I recently created a thread in general, asking a question regarding multiplayer and what format people think it should be in.This question was not, and is not a suggestion. I felt justified in creating a new thread for a couple of reasons: First, the search utility brought up massive threads whose titles didn't address specifically what I wanted to discuss with my fellow players. Second, even after searching, some of those threads were too long to properly search to see if my question was answered.

So when I log back in, it's gone. The question was what possible formats players could see multiplayer working in. The question was moved into a 17 page discussion on multiplayer dating all the way back to 2013.

I don't want to come off as my way is best, but I find this behavior to be detrimental. The next player with my same exact question will have his moved also. It will take him an hour to get ideas others have suggested from 2013-now, when he was trying to get current opinions.

Please, don't encourage super threads by moving more specific questions into a thread with a title that doesn't match the specificity of the question/suggestion. When a more specific thread of discussion starts, just let it be its own thing.

Of course, how you moderate your forums is up to you. But I feel this would be a better way to handle offshoots. Smaller threads are easier to read through (as less context needs to be understood), allowing the search functionality to be more effective. Additionally, when reading those threads, you won't have to keep track of when a post was made as you read each post.

Thank you for your time.

There's no multiplayer in the game as of yet.

But, maybe someday Tynan (or some dedicated modder with haxor C# skillz) might make multiplayer an option.

What formats would be best for multiplayer?

Would you prefer the players land in the same area, or in different areas?
Same faction, different faction?
Build the same base, using each other's resources, or keeping it separate and competing for resources?
PvP?
Different storytellers?

Multi-Threading/optimizations, particularly for pathfinding (quick fix would be good for wandering, make it use a simple random direction + 1 movement rather than a call to pathfinding. Animals bring a lot of lag into the game).

Manned Turrets, Better melee combat, world road building, mountain tunnel building (That acts like a road, but removes the mountain terrain penalty), much better rewards from traveling and trading. Better stay-game content, in essence, IE once optimizations are finished adding more for those of us who work towards conquering the world rather than flying away like sissys .

MUCH more granularity into the work tab, maybe enabled by option. I'm talking that each bench type should be potentially given a work type, allowing me to really coordinate work. A fifth priority number would be nice.

General automation of certain user tasks, such as making colonists not get in the way of a fire fight. Maybe a "no-combatant zone" that is temporary that I can place.

Better time restriction controlling as well. For instance, I'd like to see a "meal time" time slot. Allow 2 types of time restriction: Interrupt current task for time restriction and 2 "Suggest" activity time restriction (which does not interupt, so a person will finish thier joy activity for another hour before going to bed).

Finally, prisoners using joy objects, and factoring defensive options/times failed to escape into their escape eagerness (It'd be nice to see a large prison instead of having to separate prisoners out).