Basic room behaviors #1441
Basic room behaviors #1441
Conversation
|
I got poor dudes stuck in front of the door forever (running animation).. they are both trying to haul ice |
|
when trying to assign room the behavior for the second time I get exception: also.. got another stuckage.. |
|
I like how this is progressing. One think I was thinking of is having requirements as Lua functions. For example, for the Airlock it could have a requirement that said that all the doors have too be airlock doors. This could also be done in xml, but there can be other requirements that would be better as Lua, like requiring, for the Airlock, that the air pump has to pump air to space, or maybe a tank, and not a room. Looking at the door changes, I think that we could use a Door component in C# (for a different PR). |
|
@dusho unfortunately it is really hard to figure out the exact causes from images alone, but one possibility is that somehow too much air got in the side room somehow, preventing it from being pumped into anymore, I need to look into tweaking things to ensure that doesn't happen. If you can get it to happen again, do me a favor and check what the pressure is on both the airlock and the room it's pumping to, that might be enough to tell me if it's the problem I'm already aware of or something different. @TomMalbran As is, it can already require specifically airlock doors over regular doors (I chose to use the TypeTag Pressure Door, instead simply for demonstrative purposes). I'm also considering adding "Optionals" though probably not for this first pass, basically something that will be tracked like the requirements, but doesn't have to be there (like an equipment locker for airlocks for storing space suits before exiting, for example), though technically that could be listed as a requirement with a count of 0, but that seems unintuitive from a modder standpoint. |
|
@koosemose From the code I think that I can have a requirement of at least 2 Pressure Doors. But I don't see how I can tell that you can only have Pressure Doors, there shouldn't be any other types of doors. So instead of adding lots of options (the current ones seem good as they can be used for many rooms), we could have some lua requirements. If we later find a lua requirement to be used a lot, we can move to C#. I am not sure about the optional requirements. If we go for a UI similar Prison Architect were we place some sort of warning when the requirements are not met and you can click to show which ones are met and which ones aren't, once all requirements are met, you will not see it again for the optional requirements. But we could have a filter in the build menu to show items that are good fit for the RoomBehaviour the mouse is over. I wouldn't call this optional requirements, as it is more like furniture that fits the room behaviour, and because requirement that is optional in a sense is not a requirement. |
|
@TomMalbran Ahh I see what you mean now, disallowing certain furniture types basically, and yeah while basic stuff would be doable from XML (No plants in airlock for example), but No doors that aren't pressure doors would be a much more complex idea to express in xml which would almost certainly need to be done in lua. The idea behind optional requirements (I had intended them to be a separate section from requirements, so just optionals), is that there is certain furniture you would want to behave in a certain way when in an airlock. THe equipment locker was probably not the best example as interacting with that will likely be done on the character side. But for example's sake, let's say we had an alarm furniture (flashing red light when turned on) and we wanted it, when in an airlock to start flashing when air is being pumped out. It's obviously not a requirement, but it would need to be something the RoomBehavior looks for and keeps track of so it can be accessed from the actual behavior code. Basically a controlled furniture that isn't a requirement. |
|
I can see that limiting to a certain type of furniture might be doable in XML form, but more complex things could require Lua. That sounds good about the optionals. I was thinking more like creating some sort of common room and you could set furniture like tvs, radios, sofas, to be furniture that would work good in that room, but is not a requirement, nor is something you can interact with. Would be more for the UI to show the furniture that fits better in that room. You can still place anything. |
koosemose
changed the title
|
I think I've addressed the errors and I think this code is ready for a more detailed examination, prior to merging. I will look into Lua Requirements, but I don't feel they are absolutely necessary for the basic behavior and will likely leave them for a later PR. |
|
I must be doing something wrong, my scenario:
|
|
Putting this in WIP mode while I see if my latest changes fix the issues with the airlock getting stuck under certain circumstances. @dusho If you would be so kind as to go at this with your previous methods, and see if you can get it stuck again. I think I've got everything in place to prevent sticking from either the rest of the base being at a pressure other than 1 atm, and the side room getting stuffed full of air, it might still be possible to overfill it if you let things run overly long but should be fairly resistant now (it gives the side room a pressure limit of 3 atm for now). There's a bit of temporary debugging information in the select info for the pump now just to further aid any debugging attempts that need to be made, but I'm reasonably confident that this should stand up to most common circumstances. |
koosemose
changed the title
|
just tried it now several times.. seems to be working ok now |
|
Yeah, but that's something for another PR, that has absolutely nothing to do with this one. |
|
Not sure if this is needed anymore, but would it be an idea if you added a GasContainer to the pump. |
|
That might be an enhancement to the pump that might be useful, or perhaps a separate furniture that can also be used for an airlock, but I'll leave that for a potential future PR. Since no one seems to have noted any issues with how this is implemented in general for now or the code, I'm going to ahead and merge this. |
|
@koosemose To be clear, this PR has resolved on the v0.1 milestone? |
|
Yes. On Sep 30, 2016 12:59 PM, "mikejbrown" notifications@github.com wrote:
|
RoomBehaviors are defined in XML as prototypes, the most significant difference from other prototypes is Requirements, which currently supports furniture (by both type and typeTag), and a minimum size in tiles).
When a room is designated, if it meets all requirements, it finds all required furniture and stores that in a dictionary of lists (dictionary key is furniture type or typeTag) containing all furniture matching that in the room (or bordering it, for doors and such). It then sends an OnControl EventAction to its Lua, which is responsible for doing any additional configuration of the furniture to work with the Behavior (such as pressure locking airlock doors, or deactivating pumps and figuring out how to set them to pump out of the room (and in).
From that point furniture is responsible for seeing if it is attached to a roomBehavior (the easiest way to do this at this time is for the OnControl function to set a parameter on the furniture), and request any functionality it needs of the room.
Airlock RoomBehavior is included, which pressure locks all airlock doors, and turns off all pumps. Then the Airlock doors check if they are controlled by the airlock, and request for it to pump air in or out as needed by calling an EventAction set in xml. Additional functionality is involved in ensuring crew don't "fight" over which direction the airlock is pumping.
At this time I am not looking for the small scale stuff such as style and function names or anything of that sort, I would prefer feedback on the broader system, such as if there are more efficient and/or effective ways of doing what the system is currently doing, or design (such as RoomBehaviors currently have typeTags, is there any potential use of having typeTags on a RoomBehavior). I am aware of several sections of commented out code, it is either functionality I need to readapt to the slightly changed map (I included two proper airlocks in the starting map, though they're not yet designated as Airlocks, as I don't wish to have to try to set up that functionality for the starting map prior to getting the actual RoomBehavior code more polished), or code that I am using to debug when things go awry. They will be removed before this PR is no longer a WIP.
For testing, the game needs to be paused immediately, and the airlocks will need to be designated as such (it's the second button with an ugly icon in the build menu), else they will lose air, which causes issues with the airlock as it stands now. I intend to remedy this, but I feel it works well enough for now to start getting feedback.