SpaceBuild Revival

I am responsible for the team that failed the gmod fretta gamemode contest. Although we did lose, we haven’t let that demotivate us from developing, and garry did give us honorable mention for the code put into Warmod. Warmod uses an element distribution system and uses reactions between these elements.

These element resources can be raw materials(chunks of stuff) or stored in containers used to power factories. The entire system is there, and it’s very optimised.
I’m sure you’re away that Resource Distribution of Space Build uses per-second-interval synching, where as warmod’s element system only synchs when something changes. One of the greatest features about warmod was the ease involved with working with elements.

We are the same team responsible for delivering Gravity Hull Designator and Infinite Maps, so why would it not make sense for us to produce a refined SB gamemode? The gamemode will be sandbox based like the original and allow compatibility for all existing addons. The only thing that would be different is the entities used for factories and the code.

To download sb_gooniverse:

North America server:
[lua] [/lua]

European server:


username: anonymous
password: anonymous

Update 1.0:

Current Beta Features
*Element Reaction System
*Factory leaks
*Hoses/Valves system
*Warmod’s destructable system(made by cerberus)
*Onyx’s GUI system(made by cerberus)
*Space Suits with energy, coolant, oxygen, and temperature
*3 SWEPS chosen in the customization menu
*Warmod’s target information system
*Space build map compatibility
*Area based background music
*a little something special from ILiedAboutTheCake…

Spawnable factories that produce elements

Full Gamemode Features


  • Vortigaunts randomly appear on planets that destroy players and ships
  • Large deposits of resources that can be mined on planets, guarded by vortigaunts
  • Spawnable ship weapons(plasma cannons, pulse blasters, quantum distruption missiles)
  • Spawnable ship defenses(Defense Shields, Climate retaining force fields, Teleportation Devices)
  • A gyroscopic pod to easily fly ships with
  • New Model Pack addon(SB models are kind of lame IMO)
  • Animated models for each factory
  • Unique voice files placed on selectable player models(space suit)
  • Toggleable Infered vision

Unconfirmed Planned Features:
? mesh generated planets
? large arsenal of SWEPs
? manual mining with pick axes
? serverside txt saves
? planet terraforming
? automatic map change and vote
? in-game adjustable config for suits
? convars for each factory
? SB:R admin panels
? Ban Hammer SWEP for admins

Easy to Script Factories
csb_fact[“unique factory name”] =
Cells = {element_to_be_used = 200, //If you require an element to used up, if need space to store it.
element_to_be_created = 200}, //It’s also a good idea to have a queue for production element
Prod = {element_to_be_created = 1}, //1 is how much every 2 seconds
Req = {element_to_be_used = 1},//1 is how much every 2 seconds
Name = “in-game name”,
Sound = “My/Sound/File.wav”,
NoSound = false, //I want sound!
Trans = {element_to_be_created = 1},//I get a bonus 1 transfer rate per 2 seconds for my production element to other factories!
Model = “models/props_wasteland/kitchen_fridge001a.mdl”,//A fridge, lul
PFunc = function(ent) //I run every 2 seconds at time of production!
if ValidEntity(ent) then//I’m the factory at run-time!

Cool Hose Based Factory Setup

Realistic Leaks From Hoses

Wire Support

Alpha Test

Sounds really cool. :smile:

Just posting to verify claims about GHD/Infinite maps. Though gryphian+team didn’t write any of the code, they were a resource to me and I regularly work with all of them as a group. I was the second programmer for warmod. If this works out, I’ll make sure it has spherical planets too, possibly with a surface area several times greater than gm_flatgrass and with hilly terrain, etc. We want this gamemode as much as you do. :stuck_out_tongue:

RD checks to see if something has changed each second then networks it if it changed, that way if it is changed more than once a second, it only sends it once a second. Therefore, RD is more optimized, if you are describing Warmod correctly.

It is rare that interval checks are more efficient than per-change updates… Go ask people who play on SB servers with more than 5 people about rd and the horror stories with laggy equipment. We are big SB players and there is a reason we decided to script warmod the way we did.

You’re talking about two different things; cmdrmatthew is talking about network traffic and gryphian is talking about cpu usage. Plus, RD sends tons of data at once every second if I remember correctly, warmod distributes them sporadically depending on the change of data and actually if I remember correctly, warmod never actually sent the resources to the client except when the crosshair was over them for a display. Therefore unattended factories were far more efficient than in RD, since the network traffic was strictly limited to one message per update per player if and only if the crosshair is pointed at the object.

Oh, I see what he was trying to argue.
As for efficiency, I am taking a serious stance of making this gamemode run as smoothly as possible, whether it be network related or processor related.

For example, when a prop enters a new SB_Enviroment(planet, space, etc…) it gets all of it’s attributes updated frequently about temperature and gravity. This is cool for hurling some barrels and stuff, but as far as 45 prop space stations with gravity hulls are concerned, this is horrid. Simple solution: make all constrained entities share these attributes. This is with me working within SB for the first day(most of it was porting what was needed and throwing out what was to be changed)

It’s a long road ahead. I’ll keep updates here.

It’s just setting a simple value, its just as expensive as doing “variable = 1” it doesn’t copy anything, tables act just like any other variable type in this case. Sure, it might be slightly cheaper (except the getting all constrained entities part) to do it that way, but it really isn’t much of an improvement.

Don’t feel like fighting you every step of the way on development… I’ve worked with both and looked at the difference myself…

Tables are referenced unless they are copied.
Here’s a simple example of what I mean…

A = {}
B = A
C = A
A.Temp = 40




I can easily just set up a reference as soon as the entity is constrained. No need to get all the entities constrained each time.

“pics or didn’t happen” response

try it for yourself

Good luck on the project. I hope it goes well.

It may be me, but I have noticed that many GM projects (revivals in specific) tend to die. My guess is that some of them get too complex or too big and just get dropped indefinitely (too many suggestions, unnecessary additions, etc).

I am a little worried about the “compatibility for all existing addons” bit. Although compatibility is good, I tend to see more work being done to make outdated/old/abandoned addons work rather than the GM itself. Wouldn’t it be easier to set a new standard and have everyone else update to that standard?

“Compatibility for all existing addons” is only meant to include addons that work with either sandbox or SB.

Many of the addons however, such as Life Support, and RD will be built-in(very easily, like I said, it’s just copy+paste from warmod’s RD)

What does that even support? It proves my point more that it does yours. It has nothing to do with your point.

[editline]23rd August 2011[/editline]

I’m not talking about the location checking, just setting the environment.

Your point that removing tiny lua executions has little effect is valid. However, you’re extending your point and implying that a system that stores things entirely serverside is inferior to one that beams large amounts of data to the client every second that the entities exist.

You’re rating him dumb? You’re calling the guy who found workarounds to two of Source’s biggest limitations an idiot? You should be practically worshipping him!

Sometimes I think this forum is full of nothing more than a bunch of insufferable buffoons. Anyway, this looks really interesting, and I hope to see something good come of it.

I did not know how Warmod worked befor and that whole networking thing was a misunderstanding. Gryphian posted that it updated when it changes, I assumed that was the whole truth and told him the downsides to a system that updates everytime it changes. Now I know what actual system it uses, and really like the idea. So much so that I have already implemented a system that works in a way similar to this in my own LS and SB remake. Thanks for the accidental inspiration! :smiley:

All that mess aside…

The HUD is being worked on using Onyx’s HUD system which basically is a collection of tools to dynamically draw/update all parts of common HUD elements(progress bars, icons, text, etc…)

The HUD is currently being decided between warmod’s old HUD(just some bars and voice notifications) and a new overhaul to be metroid style where you have the feeling of staring out of a visor(works with the space suit immserion)
(warmod’s HUD: )

It is also a good thing to note that it will use warmod’s Target ID code, which allows players to look at entities and show:

Name(setable with tool)
Ammo(if weapon)
Active weapon(if player)
Resources(if any)

(Warmod’s Target ID system

although Spacebuild: Revival uses Element Transfer Tools from warmod, our factories will NOT feature wireless resource beaming. All connections must be made manually similar to RD.

He rated Gryphian dumb, not me. Gryphian certainly doesn’t deserve it either though; it was all a misunderstanding like CmdrMatthew said.

By the way, your reuse of code is bittersweet to me. I loved the warmod element system (because I wrote most of it), but I also would have loved to see an even better one made from scratch. Provided that it can actually be outdone… lol, just kidding. For those of you who don’t know, warmod’s element system actually had a chemical reaction system. For instance, hydrogen could leak out of containers and come in contact with running factories, igniting them for a short period. Water could leak out and make things wet, which would make them slippery-- meaning that you had a very tiny chance of slipping when you sprinted on them, and you could not climb them with the acrobatics system. Acid could be dumped out of buckets (by turning them upside-down!) onto walls, and if you tried to climb them it would burn you. And my favorite… you could drop chunks of elements into liquids and they would be transformed. I think I was going to make it so you could drop salt into the water and it would dissolve, at one point. By the way Gryphian-- are you going to be using the Pylons or are we sticking with the hoses? I think for a spacebuild revival the hoses would be the best way-- if so, you guys are going to LOVE the hoses :3
Oh, and I wanted to make that valve system at one point… let me know if you still want it.

Factory interfaces are going to be using the Resource Distribution Wire system, because it’s much better for tracking resources. Hoses are great but clunky, and will have thier place for ultra-fast resource transit. But factories needs to be completely redone so that they work with wire and such.

Also, keeping the menus for factories, so that instead of USE for off/on, you can change settings for example propane processor and nitrogen procesor could be one factory, simply a Gas Processor that you can edit configuration settings for via wire or menu-interface

Hmm… Can we have a sort of screen we can attach to the resource nodes without having to spend a day coding a chip to do it? Something that allows an easier interface than keybinds and buttons, while displaying the relevant information and settings?

That’s what I meant by menu interface. Litterally built-in panels on USE.

Anyway, here is the work that was done for today, just coded a test factory that produces 1 oxygen, coolant, and energy every 2 seconds using the Warmod Elements system.

Also, the main concept for the HUD is done, but will be revisited to improve on it.

Finally, true to warmod, everything that isn’t a brush entity is destroyable.
Objects get health assigned to them automatically based on:
Material Type

For example, a prop with 200 mass made of metal has significantly more health than a prop made out of wood.
Also, adjusting the entity’s mass does not effect he entity’s health, unless it is manually done with lua. Entity’s health doesn’t get setup until a player looks at the entity(which someone will do most likely), or the entity is damaged for the first time. When entities are broken(health falls below 0) it doesn’t just explode like CDS. Instead it spawns actual gibs which can range from chunk of concrete to flaming metal