Classes + Extra bodies

[T2k3]

From what i observed in multiplayer footage there are mostly 3 classes:

Builder -> walk around in the factory to place entities and is always shy of space in his bags
Outpost Builder -> always running around laying rails and expanding resource flow
Warrior -> killing spawners en mass, dies pretty fast once he leave his tank

That said, mostly the gear is here what makes the difference. The two Builder run around with Roboports while the Warrior has shields and maybe since .15 some of the offensive gear. That said i saw all this in vanilla footage not in bobs.

My proposal would be a combination of class system and skill-points. Say the classes are the base-multiplier and the skillspoints add on to that or the class says how costly a skillpoint is for you.

The whole part with avatars is pretty interessting in it's own. Maybe as a kind of fasttravel between outposts and main factory. The balance here would be the cost of an avatar. If the production of an avatar is costly enough it would still be a loss if the avatar dies. Maybe you have a avatar-chest (or pod) that needs an avatar placed in it to function.

That all said, i could live without the avatars, but the idea of a skill-point system, with or without classes, excites me!

[bobingabout]

I've been looking at making the classes mod, as a starting point.

it turns out that I can specify starting gear for each class.

So, the question is, which class should start with what gear? (Miner, Fighter, Building and Normal)

here's the base game stuff.

Code: Select all

  player.insert{name="iron-plate", count=8}
  player.insert{name="pistol", count=1}
  player.insert{name="firearm-magazine", count=10}
  player.insert{name="burner-mining-drill", count = 1}
  player.insert{name="stone-furnace", count = 1}

[ukezi]

the miner should start with some axes, maybe steel or better to be significant. fighter should start with a smg maybe a shotgun some ammo and maybe an armour. the builder should start with some belts, inserters, burner miner and furnaces. And nothing else for them. the normal like now. but without permanent bonuses I can't see starting with anything but builder. also can you define bonuses per player? maybe give every armour suit a 1x1 inventory and add bonuses to a item that you start with and add a armour that does nothing but hold that 1x1.

The multi player variant with an outpost builder with more speed, the base builder with more inventory and the fighter with more hp/ resistance / dmg could be better. How about reducing the miningtime/hardness of trees?

[bobingabout]

The current mod (Classes) Is basically just for defining the start condition. a slightly changed character with new equipment. I'm going with the basic plan in the first post, and attempting to (not sure if successful) add a build speed bonus (It's percent bonus, so 0.2 is +20%) via script to the Builder.

Note: Even those non-miners are going to get 1 iron axe, it's a bit painful without that.
Basic plan (Still idea phase):
Miner: Steel Axe x2, pistol, magazine x10, burner-mining-drill x2. no furnace, you don't need it as a miner, can smelt ores in your inventory
Fighter: iron axe, SMG, magazine x100, steel armor (Ammo doesn't last long at all, 100 mags really give you a huge resource boost)
Builder: iron axe, burner inserter x2, standard belt x10, burner-mining-drill, stone-furnace

a summery of the permanent character bonuses of each class (To the player entity, new body (from death and respawn where you can choose another class, or via multiple bodies when I wrote that) are as follows.

Miner: Less health, runs slower, mines faster and can smelt ores by hand.
Fighter: More health, runs faster, less inventory.
Builder: Less health, runs slower, more inventory, increased hand crafting speed.

[bobingabout]

If anyone is still interested...

https://www.dropbox.com/s/1ynlcf7ej1bkv ... P.rar?dl=0
it's a rar, you'll need to extract it.

a demo of my classes mod. (Just the classes, no skill boosts, no multiple bodies. yet)

Let me know what you think of what I've done so far.
I know, this is probably buggy, It's still early.


For the multiple bodies thing... how should I handle that? should your original body be you, and everything else be disposable extras?
I think the biggest problem I'm going to run across is that when you die (or when one of your bodies dies) you only actually leave a lootable corpse IF it causes a respawn. If I intercept death and switch to another body, it will leave no lootable corpse, and if you're not in a body, that won't leave a corpse either.

there is a on_entity_died function, but no on_pre_entity_died, so I can't monitor your "real" body and switch you back to it when you die. So my thoughts is that you shouldn't have a "real" body, you just are whatever body you're currently in. as for what to do when that body dies... Although I can switch to another body, that won't trigger a corpse.
Plus when you log out, all bodies you're not currently in will remain in the world.
Also, although there's an event for on_player_left_game (logged off, lost connection etc from a multiplayer game), there is no on_pre_player_left_game, meaning I can't do a body swap to your "real" body, reinforcing the "you are whatever body you're in" thing.

Basically, as far as multiple bodies goes, it leaves one question. Do I switch away from a body pre-death so that you don't have to re-spawn, but don't leave a corpse either, or do I let you die and re-spawn?

[Nexela]

Code: Select all

if not global then
  global = {}
end
if not global.players then
  global.players = {}
end

This should be inside of your on_init: more specifically since global is already a table so all you need inside of on_init is

Code: Select all

global.players = {}

The if check isn't needed as on_init only runs once and global.players doesn't exist when it does.

Leaving the globals at the top of the code like that will lead to issues if later on down the road you decide to add more global entries.
On a new game during on_init everything in global is copied over to the global in the map. Subsequent loads overwrite global with whatever is inside the maps global. So if you were to later on add a new global.something the way you currently do it wouldn't get read into the map is it would be overwritten.

The correct way to handle adding new globals is to put them in on_init (for new maps) AND on_configuration_changed if you have a pre-existing version (for existing maps)

[bobingabout]

you have a point.

Doesn't answer my questions though

[T2k3]

Well first, i would be nice if the ui would pop up in old saves. I didn't find any simple solution for this on the other hand, maybe someone has an idea. (i kinda provide a solution as well later)

To the balancing:
I did a short test in single-player and have to admit that the whole thing doesn't work too good, since you can't switch you'll end up with picking builder all the time (the gfx seams a bit glitched btw).
The Builder feels pretty rewarding since you can build pretty fast. You pretty much just wait till your miners throw out the resources so you can go on. The whole waiting for your build queue goes away.
The Miner gets you these resources with a simple long klick of the mouse, but since it takes ages for "handsmelting" you end up with the smelters anyway (maybe a "alternative faster receipt" could help). What really nice is that you can move through a forest like an bulldozer and in the first Minutes of the game, you progress pretty fast, but then the slowdown begins.
The Fighter is nice for running around but the whole fighting stuff gets you nowhere at the start. I guess the small inventory, with the speed bonus, makes you just take more round trips whats annoying already with the current game.

Maybe the better way to use this is some kind of "Gear-Kit" that will be used up with switching. Maybe even with multible tiers. So at start you chose a Gear-kit to start with and later on you can switch.

To the multible bodies:
Thinking of the problem from above, maybe the "Gear-Kit" could be an avatar to start of and then you build more and better with time and bigger factory/tech. In this view, you wouldn't have a "real body" more like you control an avatar from your spaceship above. Would be interesting to be able to produce replacements on death : ? something like only radar-mode till your factory produced an replacement.
btw.: Switching bodies from the radar-view would make the whole "spaceship from above" trope more vivid.

hope that helps.

[RenScorch]

Going to be honest with you, this sounds like an amazing thing if you want to make hyper specialized modular suits... Not so much as extra bodies.

[bobingabout]

This is most likely going to be a 0.16 project by now though.

I have done some experiments and prototypes of some of this, and it just highlights how much extra back end it actually needs to work right.

I put in a few requests for additions, and the developers have included most of them for the 0.16 update.


In 0.15:
Non-controlled bodies just vanish on death, without dropping a chest.
All non-controlled bodies are left scattered around the place when you log off.
You always enter a respawn phase when you die.
Creating a new class body requires a script to delete and create a new character entity. This means you can run around with the default body and do things before selecting a class, then your inventory is deleted when you pick one.

In 0.16:
All character bodies whether they are connected to a player or not will turn into a chest on death.
Character bodies can be associated with a player even if they aren't currently being controlled, and will be "Logged off" along with the player and the currently controlled body.
On Death, if I (Via script) change the player controller to a new body, the respawn phase will be skipped, so if you have multiple bodies, you will be able to just switch to an alternate body instead of seeing a game over screen. Which introduces a down-side to building your own new bodies, if you build a spare, you don't get a free one each time you die. You should still get standard respawn when your last body dies though.
Character entities can be migrated, meaning inventory is kept after picking a class.


I'll likely have to make a few changes to my approach with how some things work, such as when picking a class, instead of filling your inventory with a select set of items, instead do a find and replace. for example, on the fighter, if weapon slot 1 == pistol, delete pistol, add minigun. it means you won't get the minigun if you've done something with the pistol, but it also means you don't end up with both (Which could be considered an unfair advantage, a reason to delay choosing your class so you can mess with your inventory to get more free stuff when you do pick one.)


Also, I can't remember if I mentioned it before, but multiple bodies, and classes were going to be two separate mods. with how complex some of the interactions between classes and multiple bodies will be (Since if you have both installed, you can multiple body with multiple classes), it will be far easier just to make it one big mod.

[OvermindDL1]

Also, I can't remember if I mentioned it before, but multiple bodies, and classes were going to be two separate mods. with how complex some of the interactions between classes and multiple bodies will be (Since if you have both installed, you can multiple body with multiple classes), it will be far easier just to make it one big mod.

They should just be kept together, having them work very well together is far better than having them be distinct things. If necessary you can always add options to enable/disable specific parts more easily then having separate mods that talk to each other.

[bobingabout]

Also, I can't remember if I mentioned it before, but multiple bodies, and classes were going to be two separate mods. with how complex some of the interactions between classes and multiple bodies will be (Since if you have both installed, you can multiple body with multiple classes), it will be far easier just to make it one big mod.

They should just be kept together, having them work very well together is far better than having them be distinct things. If necessary you can always add options to enable/disable specific parts more easily then having separate mods that talk to each other.

That's what I was thinking too.

[thc133]

Where can we find the pros/cons of different classes? Thanks!

[bobingabout]

Where can we find the pros/cons of different classes? Thanks!

See this post viewtopic.php?f=51&t=50559#p294186
too big to quote.

Also this doesn't list the starting gear, but that's easy enough to find out from trying it.

[titansfury]

Hi, tested your characters mod.Looks interesting, keep going in this direction(maybe some kind of skill tree or bonuses like smelting as miner). Found some kind of bug. When u start as basic char\fighter\builder and u have installed mods for infinity\long reach u can place buildings\mine resources over selected distance of these mods, but when u chose miner u can only build over selected distance of that mods, mining reach becomes as u coded it for miner. Can u please do smth with that?) I would like to have an option for enable\disable distance of mining with my another mods even if i chose miner)

[bobingabout]

Hi, tested your characters mod.Looks interesting, keep going in this direction(maybe some kind of skill tree or bonuses like smelting as miner). Found some kind of bug. When u start as basic char\fighter\builder and u have installed mods for infinity\long reach u can place buildings\mine resources over selected distance of these mods, but when u chose miner u can only build over selected distance of that mods, mining reach becomes as u coded it for miner. Can u please do smth with that?) I would like to have an option for enable\disable distance of mining with my another mods even if i chose miner)

That's not really a fault of my mod. These other mods that modify reach specifically look to modify the data.raw.player.player entity, which is the default, and balanced character. However, the other classes use a new definition that these mods don't check for.

Because I can't know beforehand how these mods work, I can't easilly check to see if they're installed, or enabled, but they could quite easilly be modified to look at all data.raw.player type entities using a for in pairs loop, rather than specifically data.raw.player.player.

Besides, my classes have unique reachs set as part of the class advantage/disadvantage. Miner mines a lot further than default for example.

[titansfury]

One more question.

character_crafting_speed_modifier = 0.2 this line at builder class means what he have 20% more craft speed or 5x times faster?

[bobingabout]

One more question.

character_crafting_speed_modifier = 0.2 this line at builder class means what he have 20% more craft speed or 5x times faster?

I can't remember. I would have thought 20% bonus, but it would have the word "bonus" in there if it was adding to it. but 0.2 as a multiplier would also sugest it's only 1/5 the speed, not 5x.

If you feel up to it, try changing the number and see what happens, change it to 5 for example and see if things build crazy fast. (I'd do it myself, but can't, I'm at work right now)

[orzelek]

One more question.

character_crafting_speed_modifier = 0.2 this line at builder class means what he have 20% more craft speed or 5x times faster?

I can't remember. I would have thought 20% bonus, but it would have the word "bonus" in there if it was adding to it. but 0.2 as a multiplier would also sugest it's only 1/5 the speed, not 5x.

If you feel up to it, try changing the number and see what happens, change it to 5 for example and see if things build crazy fast. (I'd do it myself, but can't, I'm at work right now)

Modifiers work like this:
new speed = speed * (1 + modifier)
So 0.2 is a 20% bonus to crafting speed.

[bobingabout]

One more question.

character_crafting_speed_modifier = 0.2 this line at builder class means what he have 20% more craft speed or 5x times faster?

I can't remember. I would have thought 20% bonus, but it would have the word "bonus" in there if it was adding to it. but 0.2 as a multiplier would also sugest it's only 1/5 the speed, not 5x.

If you feel up to it, try changing the number and see what happens, change it to 5 for example and see if things build crazy fast. (I'd do it myself, but can't, I'm at work right now)

Modifiers work like this:
new speed = speed * (1 + modifier)
So 0.2 is a 20% bonus to crafting speed.

Although that does look right. my mind was going...
new speed = speed * (1 + bonus) or
new speed = speed * modifier
The word bonus does crop up a fair bit.

Here's the list:

Code: Select all

character_crafting_speed_modifier :: double [RW]  
character_mining_speed_modifier :: double [RW]  
character_running_speed_modifier :: double [RW]  
character_build_distance_bonus :: uint [RW]  
character_item_drop_distance_bonus :: uint [RW]  
character_reach_distance_bonus :: uint [RW]  
character_resource_reach_distance_bonus :: uint [RW]  
character_item_pickup_distance_bonus :: uint [RW]  
character_loot_pickup_distance_bonus :: uint [RW]  
quickbar_count_bonus :: uint [RW]  
character_inventory_slots_bonus :: uint [RW]  
character_logistic_slot_count_bonus :: uint [RW]  
character_trash_slot_count_bonus :: uint [RW]  
character_maximum_following_robot_count_bonus :: uint [RW]  
character_health_bonus :: float [RW] 

So why are crafting, running and mining speeds all called a modifier, when everything else is called a bonus, if they function the same way?