Crew Minus Crew

[Jake_Lancia]

Hey guys, just thought of something, mental breakthroug while putting on pants.

Instead of doing the corner to corner meathod, why not just reuse the very old dock system?!!
Wherever you place the docker is the "floor". All future npcs allign with this when generated/spawned in the room. It gives you a 3x3x3 square to work with right off the bat, and you place blocks to expand it like the old system.

Now, the bounding box it draws is green if it works, blue if happy (all crew points generated is used up/all crew points required is filled) and red if one of these conditions apply:

• If bounding box overlaps another room bounding box.
• If less than 50%(or 30 if 50 is too constrictive) of the space bound is open space.
• If the box extends past the ships own bounding box.
• If outside of your ships hull (currently impossible so disabled for now).

The room doesnt work if that happens, and it visually tells you this.


Now the bounding box could count in two ways:

• It could count just volume if schine just wants "space" to be used and encorage hypothetical 10x10x10 boxes of space used for crew. Hey they can jump all they want.
• It could count volume and floor space, which would encourage "decked" designs, with players then turning that hypothetical 10x10x10 space into a parking garage with multiple layers.

There are other advantages to tying this to blocks, like being able to name rooms and see them in the "ship" tab in the menu like how we acess thrust and ai and other systems. Each room would have a default name like teleporters based on their position in the ship.

In advanced build mode (ctrl) a bubble could pop up above each old docker on the ship(will need to rename it to something else) that displays room crew point capacity, and how much is being filled/supplied. Easy viewing at a distance.

You could also have a system block I guess with a display module doing that.

Pretty neat idea actually. I certainly wouldn't have thought of doing crew boxes using the old docking system.
But you say that it won't work if too much is empty space; what is supposed to fill said space?
otherwise a nice addition to an already great suggestion.

 

[Master_Artificer]

Pretty neat idea actually. I certainly wouldn't have thought of doing crew boxes using the old docking system.
But you say that it won't work if too much is empty space; what is supposed to fill said space?
otherwise a nice addition to an already great suggestion.

Oh I had meant if you don't have enough empty space. If you fill your room up too much than is it even a room anymore?

Its more of just a restraint on how big you make your bounding boxes, so you cant just make one to cover half of your ship and just say "yeah I bet there are some rooms in all that." Or to have your room size paradoxically increase as you take damage.
I'm onto you, you powergamers (no hard feelings powergamers )


Hm, that brings up another issue.
Also, an issue would be people powergamers filling the empty space with docked stuff to improve their ship and get both benefits or trying to get docked rooms to use the same space.

Eventually we would need to find a way to stop that, with more complex detection, but that can come later. Just tell people not to do it for now cause it will be patched eventually.

 

[NeonSturm]

But you say that it won't work if too much is empty space; what is supposed to fill said space?

If rooms are boxes and players want non-boxes, you have to fill corners/edges somehow - I see no problem here.
Perhaps we could have generic "tank" blocks in that area which work like storage/powercaps/shieldcaps or whatever you wish to enhance.Maybe you can enhance systems to 200% this way? Maybe enhancing this way has 80% efficiency?

Also, an issue would be people powergamers filling the empty space with docked stuff to improve their ship and get both benefits or trying to get docked rooms to use the same space.

Eventually we would need to find a way to stop that, with more complex detection, but that can come later. Just tell people not to do it for now cause it will be patched eventually.

It's easy, just map every room to the mothership's boundary box.
If turrets or ships have rooms, all space they cover in a full turn will be consumed for the topmost parent (this makes collision handling a lot easier too, or maybe you can count size around 3 strings top-down, left-right, front-rear as a sphere)
Rooms might be reduced in volume size if they are hangars containing other ships once they dock or enter that area.​

 

[kupu]

Off topic, but...
Master_Artificer In your screenshots it looks like you've hit a debug hotkey and skewed the textures on hull blocks?

Spoiler: Fix

First backup your installation in case something goes wrong (it shouldn't).
The following files can be deleted, then repaired via the launcher's repair feature.

In the folder StarMade/data/config
vertexInfo.properties

In the folder StarMade/data/textures
texOrderNormal.config
texOrderPointToOrientation.config

 

[Master_Artificer]

Off topic, but...
Master_Artificer In your screenshots it looks like you've hit a debug hotkey and skewed the textures on hull blocks?

Spoiler: Fix

First backup your installation in case something goes wrong (it shouldn't).
The following files can be deleted, then repaired via the launcher's repair feature.

In the folder StarMade/data/config
vertexInfo.properties

In the folder StarMade/data/textures
texOrderNormal.config
texOrderPointToOrientation.config

Maybe I did, but other people I talked to all had the issue, oddly enough I don't remember when it went away but i think it was a few days after this forum post.

Uh, everything's under control. Situation normal.
What happened?
Uh, we had a slight graphics malfunction, but uh... everything's perfectly all right now. We're fine. We're all fine here now, thank you. How are you?
We're sending a Dev up.
Uh, uh... negative, negative. We had a imgur dump here now. Give us a few minutes to album it up. Large dump, very slow loading.
Who is this? What's your username?
[user has disconneted]
Boring conversation anyway. LUKE, WE'RE GONNA HAVE DEVS

Only meant to do the first half but once I started I had to finish, even if it didnt make sense after the graphics mention

 

[Panpiper]

I agree that this would be a good first step and highly useful to ship builders who could them much more adequately future proof their builds. That said, programming something like this, even though it is technically much simpler than adding the whole of a crew and quarters update is not a trivial task. Given how tight Schine's programming resources are, I expect they would not want to do this level of work, if it meant that the work would be undone later when the full and proper crew and quarters was done.

To that end, any work done on quarters without crew would have to be sufficiently well planned prior to coding that it would naturally seque automatically into adding crew without code having to be tossed out. And to do that, effectively the whole of the crew and quarters update would have to be at least planned out first, not just the quarters. Given that as far as we know, all that has been done so far on the crew and quarters update has been one conversation amongst the Schine crew that led to them deciding that yes, crew and quarters would be a thing. Other than that there has been the brainstorm thread, that as far as I recall none of the Schine crew have actually participated in.

I would recommend rather strongly that this idea be folded into the previous thread as part of a staged development plan, so that the rest of the plan can flow naturally from it.

 

[Batavium]

How realistic is it to get crew into StarMade?

I am talking from both a player and server admin perspective.

We have a lot of Core entity pressure on StarMade servers today. Crew is going to add another hundreds maybe thousands of entities all crawling on ships and stations. If you today hire a crew from the NPC Trader. Then that single dude is capable of bringing the whole server down because of pathway errors. This has resulted that on many servers if you even dare to hire one of these guys you get banned!

Schema has said that he may have looked/coded on it for just half an hour. I know that some are super hyped about this becoming a part of StarMade. But maybe we need a serious realistic look on whether this can even be added to StarMade. Because if this idea needs to be buried down the line. Because it really is impossible to compute all these guys to. On top of all the other stuff that players do and goes on on a StarMade server. Than people are going to be seriously disappointed. Even more if they made stuff to accommodate them months in advance.

 

[NeonSturm]

Crew is going to add another hundreds maybe thousands of entities all crawling on ships and stations. If you today hire a crew from the NPC Trader. Then that single dude is capable of bringing the whole server down because of pathway errors. This has resulted that on many servers if you even dare to hire one of these guys you get banned!

Crew is only 2 blocks. Ships are 32x32x32 chunks. collision checks are a lot easier.

The single dude needs a quarter for his Brainware (limited™) → Mindware (shared but unlocked individually™) → Thoughtware (Unlocked with Mindware™).

 

[Lecic]

We have a lot of Core entity pressure on StarMade servers today. Crew is going to add another hundreds maybe thousands of entities all crawling on ships and stations.

Crew would not be loaded except when players are very close, most likely.

If you today hire a crew from the NPC Trader. Then that single dude is capable of bringing the whole server down because of pathway errors. This has resulted that on many servers if you even dare to hire one of these guys you get banned!

Can you point to which servers have this rule? I don't think I have ever been on a server with a "no NPC crew" rule.

 

[Batavium]

Crew is only 2 blocks. Ships are 32x32x32 chunks. collision checks are a lot easier.

The single dude needs a quarter for his Brainware (limited™) → Mindware (shared but unlocked individually™) → Thoughtware (Unlocked with Mindware™).

I did not look into much of the previous thoughts on Crew. I am looking at it as a performance issue. The NPC dude is also just 2 blocks tall and can create some nasty pathfinding. If a crew is an entity like a core or resambles a current hired NPC then i see lots of trouble. But i could be wrong! That is why i asked if this is at all possible to add StarMade.

Crew would not be loaded except when players are very close, most likely.

That would be one way of dealing with it. Though that would still add a lot of these guys as people spend a lot of time on their ship or station. Current StarMade servers have a rough time calculating anything and everything already.

Can you point to which servers have this rule? I don't think I have ever been on a server with a "no NPC crew" rule.

I had it on my server. It was on others but some time ago. First gen Light vs Dark had serious issues with it. Currently there might not be any that have this rule. I was talking from the past into the present that was wrong of me. But they are still a major headache. I would currently not be happy as admin having a hired NPC on the server. They can act as bad or even worse then a player core stuck in a planet plate.

 

[DukeofRealms]

Schema has said that he may have looked/coded on it for just half an hour. I know that some are super hyped about this becoming a part of StarMade. But maybe we need a serious realistic look on whether this can even be added to StarMade. Because if this idea needs to be buried down the line. Because it really is impossible to compute all these guys to. On top of all the other stuff that players do and goes on on a StarMade server. Than people are going to be seriously disappointed. Even more if they made stuff to accommodate them months in advance.

There has been no crew work at all in StarMade, no planning, no documentation, no development.

schema added some "crew" related data into the game, purely for fun. None of this is actual crew work; you can see his post about this below. I don't believe the classes he made will be used for anything.

These are just a few mostly empty data classes I did for fun. It took about 20 minutes to write.

Crew is planned to happen; we think it's a very realistic feature, while not considered a core gameplay mechanic (as of writing), we believe it would add a substantial section to the game. We have briefly discussed what we'd like crew to look like and potentially what impact that has on the game. This was all informal discussion.

It's impossible to say whether it will "work" or be "feasible", as not us or anyone else knows what crew will look like. Obviously, we're not going to plan crew in a way that can't be done.

 

[NeonSturm]

Perhaps pathing needs to be simplified:

* search most straight path from/to a pathing node (usually a door or wedges between floors)
* search fastest path (spend limited processing time and save results)
​

The easiest way for would be to implement logic-hooks and add "drivers" for common tasks in player-made cpu's or crew-logic.

 

[Nosajimiki]

Mostly I like this idea; however, instead of working on current systems, I feel it should be used to give your ship the currently upcoming chamber effects. IE: Remove chambers from the reactor. Instead make them "rooms" that you attach to relevant other systems like shields/reactors/thrusters etc. and make their sizes relative to the system you are modifying instead of the reactor.

I would also add that all crew paths should be able to reach the core. Otherwise, you will just have a bunch of hollowed out spaces next to each core instead of a truly traversable interior.

 

[MacThule]

Props to Master_Artificer for seeing this solution so early on and trying to get it out!

This definitely seems the best path. I missed this thread first time around, but the core concept is the exact same solution I came up with independently (9 months later) just with different ideas about implementation and specifics (I believe that decor should boost crew space value up to a certain fill percentage or something like).

So many of the key problems are resolved by making interior spaces themselves directly functional.

Once looked at thoughtfully, it literally seems like the entire game just dances around the opportunity to create this mechanic.