Planning 0.3 Milestone

[koosemose]

We have reached (passed) the 0.2 milestone, having missed quite a few things from the milestone. Hopefully this time we can meet the goal. Presently most things on this list are things that didn't make it into the previous milestone. I would like suggestions for additional things to include for our next milestone (even if it's only projects you are currently working on)

0.3

Small

• [ ] Save/Load Jobs #177 #1590
• [ ] Asynchronous Loading #1593
• Any system which prevents PP from being reported as not responding would be acceptable
• Any speed ups in Loading aren't necessary, but would be useful.

  Large

• [ ] Integrate Fluids System and Utilities
• Rather than being universal, a Fluids network should be anything that is connected to a given set of Fluids Cables.
• [ ] Metastockpiles
• Allow Stockpiles to be grouped together, and request items and handle where they go as a whole rather than each stockpile individually
• May require Job system having distinct haul jobs, rather than hauling stuff to a stockpile implemented as a job that requires material.
• [ ] Core Game as Mod #772
• Once the core game (or at least portions of it) are implemented as a mod this should help pave the way for proper mod loading logic.
• [ ] Further improvements to Job System #726 #1590
• [ ] Gear #268
• Should have multiple gear slots (head, torso, hands, feet, for example)
• Should have at least one piece of gear
• [ ] Decouple World and WorldController as discussed in #353
• WorldController currently handles many things that are applicable to the play session as a whole (and in some cases the entirety of the game, that don't need recreated between games).
• We want some amount of separation between things that should exist in the scope of "You are currently playing PP" and things that exist only in the current playthrough. (Possibly also separation between what exists for the current world and the playthrough if we still want multiple "areas" we can send our crew)
• [ ] Effects #1487
• Fire as an initial implementation, others implemented as needed.
• [ ] Overhaul Temperature System #1729

  Ongoing tasks

Bugfixing, always Bugfixing Component System

• Elements of Furnitures (and possibly later other Buildables) that are not common to all furnitures but potentially shared among many should be implemented as Components that can be used for what furnitures need them without each implementing them from scratch, but not polluting class files with things that other furnitures may not need.

Continuing UI improvements (discussed many places)

• Continue moving more of our UI to code based creation, optimally we should never have to directly create prefabs to implement any new UI system, and a mod should be capable of creating UI that exactly mimics anything we've implemented in the core game.
• This is likely an ongoing goal, and may not be completed in a single milestone.

Future Milestones/Optional tasks for ambitious folk (Will require further discussion before implementing)

Storyline #431 (likely best for a much later milestone) Lighting, Lights and Darkness #533 (Possible library for 2d lighting: https://github.com/f15gdsy/2D-Light-of-Sight-Unity ) Minimap #566 Improved Map Generation #306 Gravity

[BraedonWooding]

Temperature maybe also should be on here? Also with the UI stuff I think what we should do is prefabs as an option, so that yes we have ongoing code creation for UI but you can create essentially 'elements' that are premade elements (could even be code premade) but atleast that way it makes building a UI somewhat easier than having to create some complex hierarchies to get a slider or whatever. Also movement of Gas, Temperature and other stuff to a mod (maybe similar hookups to what I've done with my temperature stuff where it sits ontop of world) is probably a future milestone?

[koosemose]

Well the plan is to have as much of the base data as a mod, but with how easily we butt up against performance issues, I don't think we should have too much of the logic (at least anything that has to run with any regularity) as mod, and technically gas actually moving between rooms (via vents, doors and air pumps are performed in Lua scripts. But if too much is in mods, it is much harder to ensure good code (stylecop isn't ran on streamingAssets, and I'm reasonably sure it won't pick up compile errors).

My general thoughts on UI are that the UI itself should be code/data based, but with prefab controls. i.e. to edit a menu, rather than editing the entire thing in the editor, or having to put together each control and customize it via code, you'd instead just do something along the lines of dropDown = CreateDropDown(parent, list) or possibly even have a data file that creates it, have the data file set a name through which it can be accessed or some such.

[BraedonWooding]

Yeh I perfectly agree, and I have a new thing that is perfectly suited for this exact requirement (running regularly is very supported too with immense speed) however I'm still ironing out kinks so I'll keep it as a secret for a little while :P.

On the second point yep that's exactly what I implemented and what I was talking about. However, I did also allow the user (and think we should generally) create their own 'controls' via just doing things like new GameObject(); go.AddComponent() and so on... Just since it requires no extra work on our end :D, with the system I built (for the settings menu which currently I'm planning to push out to things like the FPS monitor and DevConsole since I know their code well) just having you extend a class and implement a few basic methods with the rest being up to you, this system would essentially be 'different' for every sub system (like have a generalElement, then have a generalApplyElement with functions for apply/save and cancel, and trade menus, and have maybe a generalUpdateElement for update functions - for use in things like FPS monitor...) but all be structurally pretty flat (maximum two levels). However I do want to open some discussion on whether or not others agree with my line of thinking (previously I got a decent to majority amount of support for it, though others that have recently joined may have new ideas).

[dusho]

we still need that functionality so utility (cable, ...) can connect to any part of multitile furniture (my attempt to fix that didn't play well with re-connecting of grids)

[koosemose]

Yeah that's a good one to add, and I'll probably take a crack at that next.

[dusho]

can we also put improve/update/re-write pathing.. feels like current one is really bad and re-evaluating same paths and failing (so spamming console with failure to traverse) and causing FPS drops.. then the jobs are just hanging and game is in shitty state afterwards

[koosemose]

As far as I can see pathfinding is fine, the issue lies in the Job Queue, it's still subpar in evaluating if a job (or inventory for a job) is reachable, and is requesting pathing multiple times.

[koosemose]

And I think I found the source of that issue, I missed an inventory.CanBePickedUp, so it was pathing to the stockpile, and being told it can't pick it up, and therefore requesting a new path, and being told about the same inventory so they get stuck in a loop of that, so all crew eventually end up stuck in stockpiles, hammering the pathfinding.

[BraedonWooding]

@koosemose can we also add 'make offline documentation' through either doxygen or sandcastle since that'll act like a 'unity like reference' (basically means we don't have to go looking into code to find functions and what they mean). I can set it up if you want, I've just done sandcastle for a few of my stuff and got it working with Unity (a small workaround).

[BraedonWooding]

Also update the kaplan board to say Milestone 0.3

[koosemose]

Offline docs sounds good, I'll add it later (end of the day for me). And the Kaplan board is a bloody pain to keep updated, particularly since it seems oriented towards a more standard project where a core dev team is working on most of the features (and can each edit it as each stage progresses), as is, I have to keep track of every element and can't know what stage something is at unless it's either in an issue or a PR, in which case it's progress is already documented.

[BraedonWooding]

Yeh that's true, maybe just update the name for now, then later when we get more people it'll become easier to manage?

[koosemose]

So long as quill is absent it will be a pain to maintain (as I have no way to give other's the authority to edit it or anything else, so it will only ever be me maintaining it).

[BraedonWooding]

Wait really? Maybe since quill is absent you should contact him asking to be given administrator permissions since basically you are 'running this'? Either by email or a ping?