Milestone 0.3 - Putting Astronauts to Work #32
Comments
|
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? |
|
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 |
|
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). |
|
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) |
|
Yeah that's a good one to add, and I'll probably take a crack at that next. |
|
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 |
|
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. |
|
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. |
|
@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). |
|
Also update the kaplan board to say Milestone 0.3 |
|
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. |
|
Yeh that's true, maybe just update the name for now, then later when we get more people it'll become easier to manage? |
|
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). |
|
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? |
BraedonWooding
changed the title
Putting Astronauts to Work
BraedonWooding
changed the title
Putting Astronauts to Work
|
As of right now, I believe we are close to a natural breaking point, and there are 2 things that we should finish. We can sneak in bug fixes when we find them as well.
Anything else that is a major issue let's hold off until 0.4. We can of course address all open PRs, and any bugs that we find along the way. |
This milestone is all around stabilising the systems in place while also adding a new job system!
Job System
XML to JSON
The text was updated successfully, but these errors were encountered: