[ News | About | Media | Downloads | Tutorials | Contact ]


Latest News | Previous Article | Next Article

27 September 2015 - Merging Items

If you missed the previous article about Custom Items consider reading it first, as it explains some of how the items work in From Earth. Item Merging or the "Crafting System" is one of those features that I feel like shouldn't have been added, or I should have had the self-control not to add. It adds some value, but I feel like it's still too limited, or not explored enough to add enough value.

Here's how merging items works in From Earth.


There's two type of item merging. Either two entities/models can merge into a new entity or a child item can attach into a host item. Both versions have benefits.

Merging entities into one
This is more rare. Currently only few items do this. It's more complicated to set up. Currently I don't allow this for custom items. The problem would not only be ensuring that the resulted item has the same value as the combination of the values of the previous two items, but also just setting up the code for it. I might add it later as an update.

The benefit from this is not only that is saves in entity count, but it's a bit cheaper when you don't need to calculate the item attachment positions and the child item positions.

Attaching items into each other
This works by having items merge to each other by attachments ("merge01" to "merge08"). This is still limited. The host item needs to be defined to allow be used as a host. The child item needs to be defined to allow to be used as a child. Currently only a handful of items are allowed to be used as a host, mostly weapons.

There's a list of merge points. The attachment for the specific merge point need be defined in both models or they wont merge. For example, rifle has a "gun barrel" merge point. You wouldn't want something that is meant to attach to the front of the armour to attach into the barrel. The attaching model can replace part of the host model (part of the model is hidden by bodygroups).

By default custom items can only be used as a child item. In they "hlss_settings" $keyvalues section you can define one of the merge points to be used as a host. If a merge point is used as a host, it can't be used as a child point as well on that model.

So, this is still kind of limited system, though it would help with just simply starting to add the attachments on more models.


So what does merging items together do? Merged items can affect all sort of values and even functions in its child or parent items. Some of them can only be done by hardcoded items, but big part of them are available for custom items.

So here's a list of some of the things you can modify:
  • Changing damage type or adding damage types into melee attacks
  • Removing or enabling effects from existing weapons
  • Neutralizing type of damage when the item is worn
  • Light color (for existing items that have lights/glows in them)
  • Color of the muzzle effect
  • Settings on an item
  • Rifle aim cone
  • Rifle ammo type
  • Adding or removing how much energy there is
  • Changing the required energy
  • Blade length (if the item replaces a sword blade)
  • Range and melee damage
  • Fire rate and delay
  • User damage
  • Increasing how much melee attacks do damage when the user is wearing the host item
  • Adding or removing predefined effects
  • How fast the item should detoriate (if it's a breakable model)
  • Increasing or decreasing how much wearables shield damage
  • Increasing or decreasing how much goggles zoom
Values can be changed by few different ways: "set", "multiply", "add", "subtract", "divide", "reverse". Some values have minimum and maximum values.

Now this is kind of a limited list right now. Like said before, some items also have hardcoded functions that are modified by other items, and those are not mentioned here. A lot of these are also hardcoded into the existing non-custom items.

In my previous article I talked about custom items and buttons and how I am not sure how I should define functions for buttons. The problem is the same here, I am not sure how I can add a lot of interesting modifiable functions without adding some kind of scripting language. I have never really tried LuA myself since I haven't seen any point in it when I can program everything with C++ myself. I suppose the benefit would be that all of the code would not be loaded at the same time?

Anyway, I am still thinking of how I could improve the merging system. Right now it revolves around few usable items. When I started the system, I was hoping for something that could result in unforseen results, something where items could interact with each other in unpredictable ways. I am not sure if this would be really something could happen with this system. I suppose one problem is that the list of modifiable values is still quite short.

I started adding more merging options for items, though I am not sure if it will just create noise and make it harder to recognize the actually useful items. I was also thinking of player ability to see what the item abilities were when examining the item, but it would be a bit work (basically I would need to hook up each merge variable change function with a piece of code that describes it, and program an UI that draws those on the screen). It would help with players having to try every item aimlessly, but at the same time it would be against the philosophy of the game: Zenaida doesn't know the alien technology and wouldn't know what the item would do.

With some items like armour Zenaida can tell how good it's protecting against damage just by looking at the material it is made of (you can see the armour value when examining). When you look at something like a rifle, you can see the buttons and which mouse key activates, but there's no descriptions what the buttons do. The player has to experiment to find out. But with merging items, it's slower to try merge items together and see what the effect is, so I am thinking of something that would make it easier to figure out what combinations are possible and even what they do.


When merging objects together the physics can be a bit complicated. The item can get bigger or smaller depending how the items are attached to the host. The rifle for example, can have a barrel replacement that is shorter than the normal barrel. The sword can also have blade replacements, and can also break. So, I wanted the item physics object to match the size of the new merged item. First I thought this was nearly impossible, but there's surprisingly lot of access to the physics object creation.

Creating physics from hitboxes.
This is probably the easiest to do. I can access the hitbox data from the CStudioHdr class and iterate through them. I can then calculate the world positions of those boxes and create convex physics pieces out of them. I can use hitbox groups to determine which merge attachment point it belongs to. If the bodygroup mesh for that attachment point is hidden, then that hitbox should be ignored. For each child item, I need to calculate the hit box positions in respect to the host item.

Creating physics from the model physics.
This is slightly more complicated. I need to fetch the data about all the convex pieces in the model physics. Good example of this is in UTIL_CreateScaledPhysObject function in props.cpp. I also need to translate each convex piece to match the host item's local space.

I also noticed that the item physics CPhysCollide isn't really showing up correctly in the client side, though I am not sure why this is. To visualize the new physics object, I needed to include the code that creates the CPhysCollide object on both server and client, and recreate it and draw it when v_collidewireframe is set to 1. When I was implementing this code, there was few cases where the server and client side code had mistmatching physics (something on the server side was causing the physics to be created incorrectly). I had to create a helper function that would do traces on the physics object to draw debug lines on the physics object to show its true shape.

Creating merged objects their own physics might not be 100% necessary. I could have done with the items just having the original physics object. There was a lot of problems with merged child items going through walls and floors, which looked weird, so this fixed that problem. There might also be a problem where item would end up having too many convex pieces as a result of being merged from so many objects. I could also try to create some kind of code that checks if the child item is so completely enveloped by the host item, so that there's no need to create convex pieces from it.


		"animations" 		"default"
		"energy"			"0.5"
		"scanned"			"1"
		"disintegrated"		"1"
		"throw"			"1"

		//These two should match
		"spawn beams energy"
			"value1"		"0.1"
			"parent"		"1"

		"wearable melee energy"
			"parent"	"1"
			"value1"	"0.1"
			"type"	"add"

		"wearable melee"
			"parent"	"1"
			"value1"	"1.5"
			"type"	"multiply"

		"spawn beams"
			"value1"		"beams1"
			"value2"		"beams2"
			"parent"	"1"

		"spawn beams dist"
			"calculation"	"set"
			"value1"		"2.7"
			"parent"	"1"
		"spawn beams width"
			"parent"	"1"
			"value1"	"0.4"

		"spawn beams length"
			"calculation"	"set"
			"value1"		"4"
			"parent"	"1"

		"neutralize shock damage"
			"parent"	"1"
			"value1"	"1"

		"shock damage"
			"parent"	"1"
			"value1"	"1"

Looking for help

We are still looking for people. If you are interested to apply, you can send me a message on Moddb, Twitter, Facebook, or e-mail me at au-heppa@hlssmod.net.

We are looking for a composer to help finish the music for From Earth.

We are interested on getting any help we can get, especially world texture creators and prop modellers.


by Au-heppa
Permalink: http://hlssmod.net/index.php?page=0&news=45

Hide full article list
45.  27 September 2015 - Merging Items
44.  20 September 2015 - Teaser Trailer
43.  13 September 2015 - Custom Items
42.  8 April 2015 - Voice Actors, Streams, and Alien Posters
41.  6 December 2014 - Asi pos Ruumste
40.  22 October 2014 - Steam Greenlight
39.  14 June 2014 - Language Barriers
38.  12 February 2014 - Language System
37.  28 December 2013 - Fighting System
36.  6 June 2013 - Level Designers and a Voice Actress
35.  28 April 2013 - Playtesting From Earth
34.  8 April 2013 - Alien AI
33.  18 March 2013 - From The Darkness
32.  4 March 2013 - Climbing System
31.  4 February 2013 - Interaction System
30.  14 January 2013 - First Person
29.  7 January 2013 - What happened to Human Error?
28.  1 January 2013 - From Earth
27.  15 February 2012 - LAST ZOMBIE
26.  16 December 2011 - World Of Water
25.  11 December 2011 - Speech Bubbles
24.  7 December 2011 - Making Of Water Part III
23.  3 December 2011 - Making Of Water Part II
22.  1 December 2011 - Making Of Water Part I
21.  21 November 2011 - A quick look into the making of a gesture
20.  13 November 2011 - Water Released
19.  6 November 2011 - Water Release Date
18.  30 July 2011 - Human Error Source Code Released
17.  6 January 2011 - First Ever Weapon Render
16.  3 December 2010 - Water
15.  26 November 2010 - Controllable Manhacks
14.  28 July 2010 - Alyx Mode and More
13.  14 July 2010 - Human Error Co-op Beta Released
12.  29 May 2010 - Alien Grunt & Controller Give Away
11.  26 April 2010 - He's a frakking Traitor
10.  8 Feb 2010 - Human Error Released
9.  7 Feb 2010 - This Is Larson
8.  29 Dec 2009 - 2010 Trailer
7.  28 Dec 2009 - Super Secret Beta Testing Blog
6.  17 Nov 2009 - Harder, Better, Faster, Stronger
5.  17 Oct 2009 - This Is Noah
4.  23 Jul 2009 - This Is Embarassing
3.  1 Jul 2009 - This Is Au-heppa
2.  17 Mar 2009 - HLSS in Podcast 17
1.  5 Nov 2008 - First Media Release

[ News | About | Media | Downloads | Tutorials | Contact ]

Valve, the Valve logo, Half-Life, the Half-Life logo, the Lambda logo, Steam, the Steam logo, Source, and the Source logo are trademarks and/or registered trademarks of Valve Software. All information is copyright their respective authors. Website designed by some guy I know.