Check out Half-Life Re-imagined competition results!
Check out Skewing textures in Hammer, our newest tutorial!
Say hello to kesizewi, our newest member!

logo

Site Stuff

Reference

Maps

Community

ShoutBOX

Poll

Feeling Blue

What's your favourite shade of blue?

Azure

17

Cobalt

32

Turquoise

11

Cyan

12

Royal

11

Teal

3

Onliners

7 mins

Dimbeak

13 mins

ToTac

16 mins

Solokiller

29 mins

Dr. Orange

47 mins

savvaisnotagirl

55 mins

Penguinboy

56 mins

23-down

Affiliates

A gaming and technology blog by TWHL admins Penguinboy and Ant. A music blog by TWHL users Ant and Hugh.

Half-Life engine access

[1] 2 3 4 5 6 7 8 9 10

Forums > HL Engine Discussion

13 Jul 16, 18:28
By Solokiller
avatar
Member
As some of you already know, for the past few weeks some Half-Life community developers and players have been discussing getting access to the engine. We're planning to ask Valve to open source it so we can deal with bugs and other issues in the engine, of which there are many. Some public discussion has taken place on Valve's Half-Life Github repository: https://github.com/ValveSoftware/halflife/i
ssues/1712


We've also been writing a letter that we'll be sending to them. We'd like anyone that supports this endeavor to sign the letter so we can show Valve that a large number of people want to make this happen.

This is the letter: https://docs.google.com/document/d/1wxoVprq
JYYvTFgTsI-fwfVhRQWTBaqvD9l29CCQFHIo/edit
?usp=sharing


This is a copy of the document we're using, without names.
13 Jul 16, 19:21
By Loulimi
avatar
Member
I'd love to see the Goldsource engine made open source. I expressed my support on the Github thread.
13 Jul 16, 21:47
By Admer456
avatar
Member
Oh man, can't wait for someone to add DirectX 9, 10, 11 support on GoldSource, as soon as it's open source. And, best of all, if it becomes open source, we can finally extend the limits, and make big, open world maps, with 1024 models.

Imagine coding a mix between Source and GoldSource. Like, displacements, voxels and ragdoll physics in GoldSRC. God, I'm imaginative, arent't I?
13 Jul 16, 22:22
By Solokiller
avatar
Member
I wouldn't waste any time on DirectX. OpenGL can do everything DX can, and it's cross-platform. Not that it shouldn't be possible to implement (giving anyone a chance to take a crack at it), but the current engine code setup makes it downright insane to add more renderers.
The current setup has one engine library for each renderer, that's the library containing the entire engine. Linux is even worse, having multiple dedicated server software renderer libraries and a hw.so for clients.
13 Jul 16, 23:00
By Loulimi
avatar
Member
Just out of curiosity: what about Vulkan? Isn't it an alternative to OpenGL? I've heard it's easier to develop with it. But I doubt it would be worth it to consider adding it to the Goldsource, since it's not based at all on it.
13 Jul 16, 23:24
By Penguinboy
avatar
Haha, I died again!
Vulkan only runs on very new GPUs, so most hardware that runs HL now won't be able to use it. OpenGL is still the best (and only) option right now if you're aiming for older hardware and cross-platform support.

I'm fully in favour of open sourcing the engine. It would be an amazing resource to the Goldsource community and would allow us to do some cool things that have never previously been possible.
14 Jul 16, 00:48
By JeffMOD
avatar
Call 141.12
I don't think anybody who develops for goldsource is going to be doing anything intensive enough to warrant going through the Vulkan API for the extra power lol. Besides, just moving away from immediate mode and to a modern version of OpenGL that actually runs a proper pipeline would be a massive gain, I'm sure. Let's stick to removing the hardcoded engine limits first.

Valve haven't done anything with the engine or code resembling it since ~2003, so I don't really think they'd have any financial repercussions to open-sourcing it, and giving people a base or reference like that would be a big boon to programmers trying to make their own games - most of which I imagine would want to end up on steam where Valve would be taking a cut.

I can't see any issues with open-sourcing the engine, and there's a lot of potential for gains. I'm in - where's the name collection doc?
14 Jul 16, 01:34
By Half-Rats
avatar
Member
The opps...think of the opps.

We could have improved sound quality....all these other great features to boot.

And then I realize it's 2016, and Unreal 4 is free.

I am not meaning to be a weenie here; but at what point does it just make sense to move to another engine; rather than try to revamp GS? At what point is it no longer GS technically? What are your thoughts?
14 Jul 16, 01:34
By Jessie
avatar
Ladytype
Exactly what sort of things does the engine control?
14 Jul 16, 05:15
By Stojke
avatar
= O P L - 3 =
What could be implemented is improved rendering efficiency, influence on engine specific functions via map code, higher limits, a way to make solids render like models, better underwater effects, and such.
14 Jul 16, 07:10
By Admer456
avatar
Member
OK, here's a good list of things:

- Displacements
- Physics
- Massive texture size
- Normal maps, specular maps, and bump maps
- Voxels (because, why not?)
- New renderers (as mentioned above)
- Much better collision
- A scripting language, so we can have mappers to make custom weapons without changing the game's code
- Parenting! Way useful if you think about it
- Parallax mapping, phong shading, displacement mapping
- Tesselation
- Better handling of 1000's of wpoly
- Attaching other models/entities to bones of character models
- Better sound quality, including .ogg, .wav., .midi and .mp3 support
- Playing videos (like an in-game cutscene), could be nice for intros
- Animated textures up to 256 frames
- Dynamically resizing the player's size (Attack on Titan, everyone)
- Fully dynamic, omnidirectional shadows and shadow mapping, like the ones from Far Cry 1.
- Hell, why not deforming terrain, like the Half-Life 2 Beta
- Getting in and out of vehicles, like in GTA

I think some of these are already possible with the SDK, but all this is just a handful of ideas.
14 Jul 16, 07:21
By Crypt
avatar
120% sorry!
Honestly it sounds like you just want Source, Admer.
14 Jul 16, 08:31
By Solokiller
avatar
Member
@Loulimi As Penguinboy said, it only runs on new cards, but if the renderer is refactored into its own library anyone can take a shot at it.

@JeffMOD I've worked on some retained mode OpenGL rendering and the performance boost it gives is considerable, even without using vis data. Definitely worth it all on its own.

There is some backported Source engine code in there though, as well as Steamworks code. It looks a bit different compared to the Steamworks SDK, probably because the engine is so damn old. There's packet obfuscation code, as well as some "secret" stuff, but nothing you can't reverse engineer out of the Linux libraries.

I was able to generate import libraries for tier0 and vstdlib so i could get VGUI2 working, and i can reverse engineer any interfaces, OpenGL code and other code i need with little effort. Its source code is an open secret by now, but the legal issues surrounding it are a real pain in the ass. Valve's lawyers aren't known for being very lenient.

@Half-Rats Sound quality is one thing that's relatively easy to improve. Even when using Miles you can improve the quality, though i don't know if the library version the engine uses is capable of it. You can always go for FMOD or OpenAL. In all likelihood the Linux headers for Miles will be broken though, i had to fix those for SC because it had double newlines.

IMO no other engine is as good at allowing modding as GoldSource. Source gives you more power, but it limits you in some ways, and it doesn't have stuff like gibbing.

@Jessie To give you a good idea:
Sound
Graphics (sprites, studio models, brush models, particles, HUD, VGUI1/2)
GUI (WON remnants, VGUI1, VGUI2)
Input
Entities
Networking
Physics
File handling (when using enginefuncs_t/cl_enginefunc_t, otherwise it's the filesystem library)
Steamworks server handling (master server connection, heartbeat, etc)
Voice streaming (Steamworks, the rest are never used, despite the cvars still being there)
Mod loading (liblist.gam, Metamod support)
Data corruption & memory leaks (longjmp error management)

Believe it or not, the engine actually has Metamod code in it. Unused, but still quite surprising. I think Valve wanted to add engine level support at one time, probably while they were adding their secure library code. That's now obsolete, so the Metamod code is probably just legacy stuff.

@Stojke All possible to do, but it'll take some time. The engine is a mess you won't see in projects started after 2000. See Quake's codebase for examples. Global variables, global variables everywhere.

@Admer456 Lots of good ideas, but not all easy to do.
Graphics related features would require a completely new texture system. Something like Source's material system.

Displacements require a new BSP format, thus a new compiler, editor and map format as well. Dynamic mesh deformation is possible, but you'll have to account for all possible edge cases, like a mesh being used by multiple copies of a displacement. Probably requires a new physics engine.

Physics may be a problem if no real-world size mesh exists in the map. Hull 0 might be good, but since some compilers provide hull size overrides, it may not always work. You also have to consider that mods may assume that the existing physics engine is being used. The point hull might be what you need here, i'm not quite sure.

Parenting may be possible to implement in game code by applying parent velocity to children. I think that's how Spirit does it. A new physics engine would allow you to add support at the lowest level. Bullet has constraints for this: http://bulletphysics.org/mediawiki-1.5.8/in
dex.php/Constraints


Some of those will look familiar to Source engine users.

I've already implemented a scripting language in SC before, and i'm rewriting my helper code from the ground up to use in a new project. Relatively easy to do if you know the scripting API. I implemented custom weapons as well as custom entities, but there are limitations, largely engine limits. Still, it's very powerful, even with the crappy quality of the SDK.

WPolys aren't a problem if the renderer is using retained mode.

Attaching stuff requires parenting to work properly, atm you can use MOVETYPE_FOLLOW to attach to other entities and (IIRC) attachment points. I don't think it's exposed as an entity though. A scripting API would make it easy to do.

Better sound support is possible if Miles supports other file types. Otherwise, new sound system. ambient_music is a must-have, streaming large files from disk is highly recommended. You don't want maps using gigabytes of memory because they reference a lot of music (see SC's bm_sts for that problem).

Playing videos requires render targets, and streaming data from disk. Not terribly hard, but the renderer in its current state is crap.

More frames in animated textures probably requires a new texture format. WADs aren't up to the task and all of the tools won't know how to handle the new limit. The pitiful name length limit (15 characters) will be the biggest problem.

Resizing players is dependent on multiple factors, you can do it in mod code, but you'll be limited by hulls. Needs a new physics engine.

Vehicles shouldn't require engine level support, but you'll need support for viewpoint modification and player parenting to vehicles or smoothly moving them without gibbing them. Completely overriding input handling in a non-crappy way is recommended (SDK uses Use functions with USE_SET).

I've been working on making my HLMV code use interfaces for rendering, once that's done i can implement a retained mode renderer alongside the immediate mode one. Eventually it'll be capable of everything the engine can do.

I've also got a prototype BSP renderer that uses retained mode. It has shaders for lightmapped textures, solid textures, horizontal water wave effects, and transparency. It's really not that hard to implement when you have the code that does it in immediate mode, but i've got to reverse engineer or guess at everything. If i had the engine's source, it'd be much easier.

I've seen the engine's code. I removed over 300000 lines of code from it (ancient Steam Friends UI, HLTV, random old stuff like ~2000's hardware surveys), and there's still a million lines of code left. There are old and new versions of utility classes that were ported from pre-release versions of Source to GoldSource, with missing bugfixes like using sizeof on wchar_t arrays. Gotta love those out of bounds errors.

If they do make it available, anyone that works on it will be in for one hell of a ride. If you don't plan ahead and work in stages (starting with code removal and cleanup), you'll go nuts. You'll want to avoid anyone that tries to block a change by claiming John Carmack wrote it, those kind of guys aren't in it to make modders' lives easier.

I recommended a 2 stage approach for SC, making backwards compatible changes first and breaking changes only after all compatible changes have been exhausted. You could also maintain 2 codebases to do both at the same time.

Whatever you choose to do, you absolutely need a plan. Discussing stuff first will reveal issues you probably won't have thought of yourself, e.g. increasing the maximum size of a network message will require the read and write calls to account for the size of the variable. You can use template magic to make it choose the correct function automatically, but the engine's written in C so you'll have to convert it first.

@JeffMOD I can invite you to the Google doc so you can sign it. I'll need your Google account name for that though. We're going to make a public petition somewhere so this won't be needed, but right now this is how it's being handled.
14 Jul 16, 08:49
By Admer456
avatar
Member
@Crypt

Source is the thing I need. It's the Source of all my problems.

My imaginary girlfriend's middle name is Source. In fact, it has most of the things I need, so I'm going to migrate there. I found CryEngine 1 to be better, but it has a steeper learning curve.

(P.S. Her full name is Jody Source Cryfox)
14 Jul 16, 10:36
By Stojke
avatar
= O P L - 3 =
Also Dynamic sky effects and sun light tracking glare/flare.
In my opinion changing the engine too much is pointless. There are already engines that can handle insane amount of graphical objects, like ue4.
Half Life should be modified to a point where it still retains its classic feel and looks but gains improved immersion, atmosphere and best of all functionality, for further mod and map development.

Pretty much, it needs some cool new graphical effects, audio improvements, polishing in movement, aiming and physics of objects, additional control over certain map and object aspects, better and more efficient rendering, more ability for entity interaction, and similar.

Sollokiller is there a place or a website where one can see other peoples engine modifications and read more about it?
14 Jul 16, 10:43
By Solokiller
avatar
Member
The only group that can modify the engine is the Sven Co-op team, and they don't exactly share the details of their work. You can check their forums for any information they have though.
If unofficial engines are your thing then you can check Xash or ReHLDS. Both are on Github, and Xash is on ModDB.
14 Jul 16, 10:53
By Stojke
avatar
= O P L - 3 =
I saw xash, its pretty good. I haven't read much about it lately so im gonna inform now. I didn't hear about ReHLDS so that's cool.

I just had an idea, there should be ability to change texture sounds and import new sounds for each texture for crowbar hit and walk/etc.

As well as pack all resources into one file and not 50 different files and file types.
14 Jul 16, 12:38
By Solokiller
avatar
Member
Texture sounds are handled by mod code, but customizing it requires a fair amount of work. Using pack files is relatively easy as long as everything uses the filesystem interface to access the data.
14 Jul 16, 13:01
By Loulimi
avatar
Member
Quote:
Honestly it sounds like you just want Source, Admer.

This. I don't see the point of trying to imitate a modern engine. As some of you already pointed out, modern and free engines like Unreal Engine 4 already exist. Plus it would be impossible to defy them on those aspects. The only reason why Goldsource still stands out today for me is its classical aspect, the easiness with which it's possible to develop, its gameplay...
Not having tons of modern features like physics are not necessarily a bad thing IMO, but a feature instead. Apart from its bugs, I like the simple physic of Goldsource where you don't get a headache (well, kind of) when you're trying to move a crate, its graphical atmosphere more focused on lighting and textures rather than an overdose of props as we see in modern video games, and its limited size as well as the options it offers make it easier and more enjoyable to code or map with it (well, for coding, I never actually made any coding as part of a Goldsource project)...
But then, not everything has to be kept. The flashlight is awful, there are bugs, limitations (~15 characters for texture names, x16 texture dimensions, etc.) poor performances... These would be for me what needs to be fixed and the reason why we need access to the Goldsource engine (besides making customizing it for mods easier).
19 Jul 16, 21:17
By EsprimoP
avatar
Member
Wait, would it mean that....

RGB Chat will be possible??
19 Jul 16, 21:48
By Solokiller
avatar
Member
What do you mean by that? Embedding colors into chat?
19 Jul 16, 22:00
By EsprimoP
avatar
Member
Counter Strike;
It's a half life mod right? And uses the exact same engine, correct me if I'm wrong I'm not much of a 'reader', there are only 5 chat colors available in cs: red, blue, white, green, normal (yellow / con_color cvar in RGB). In amx and metamod plugin scripting adding new colors is impossible because It's hardcoded to the engine. Uhh, so bad at explaining, but it would be cool have a colorful chat like in minecraft or example.
19 Jul 16, 22:11
By Shepard62700FR
avatar
Member
Quote:
- Displacements
BSP Renderer + custom physics engine = job done
Quote:
- Physics
In the past, people already implemented Novodex (which we know refer to NVIDIA PhysX) within GoldSource, so this is feasable.
Quote:
- Massive texture size
- Normal maps, specular maps, and bump maps
Custom OpenGL renderer is enough (see Cry of Fear/PARANOIA)
Quote:
- Voxels (because, why not?)
Forget it, that would make BSP useless.
Quote:
- New renderers (as mentioned above)
For modern hardware, I agree that a "modern OpenGL" renderer (based on shaders) would be great, otherwise "legacy OpenGL" is just fine. Direct3D would be a no (because it's a Windows only API and Valve dropped it's support in GS anyway in 2013) and don't mention Vulkan (why would you use 666 satchels charges to blow a headcrab ?)
Quote:
- Much better collision
IMHO, Half-Life without the "Quake style" collisions wouldn't be Half-Life, you can improve the collision code or like I said above, use a custom physics engine.
Quote:
- A scripting language, so we can have mappers to make custom weapons without changing the game's code
Solokiller planned to add Angelscript support like Sven-Coop, I remember some mods implemented Lua in the past.
Quote:
- Parenting! Way useful if you think about it
Hmm... could be cool.
Quote:
- Parallax mapping, phong shading, displacement mapping
- Tesselation
Same as above, custom OpenGL renderer and you're done.
Quote:
- Better handling of 1000's of wpoly
You mean : "optimised code" ?
Quote:
- Attaching other models/entities to bones of character models
You can do it already, retrieve the model pointer, get it's bones info, get the name (or index) of the bone that inrest you, get it's origin and angles and you know the rest. This is how we specify the origin of shell ejection for weapons in ARRANGEMENT.
Quote:
- Better sound quality, including .ogg, .wav., .midi and .mp3 support
I don't know much about Miles, but you can do like me, write and use a custom audio engine with FMOD (or OpenAL, Wwise...)
Quote:
- Playing videos (like an in-game cutscene), could be nice for intros
Just implement Bink, FFMPEG or something similar, convert the video frames to OpenGL textures (or TGA images) and show them through a custom OpenGL renderer (or VGUI), decoding audio will require a custom audio engine (FMOD, OpenAL, Wwise...)
Quote:
- Animated textures up to 256 frames
I'm gonna repeat myself : custom OpenGL renderer with a Quake III Arena style shader system
Quote:
- Dynamically resizing the player's size (Attack on Titan, everyone)
I think this can be done.
Quote:
- Fully dynamic, omnidirectional shadows and shadow mapping, like the ones from Far Cry 1.
Again custom OpenGL renderer.
Quote:
- Hell, why not deforming terrain, like the Half-Life 2 Beta
Like displacements, custom BSP renderer and physics engine.
Quote:
- Getting in and out of vehicles, like in GTA
Have you heard of tanks in HL: Invasion and Gunman Chronicles ?

In other words, most of the things you've asked can already be done from a mod standpoint.

Quote:
Also Dynamic sky effects and sun light tracking glare/flare.
SoHL has (or had) a dynamic skybox feature similar to Unreal Tournament 1999, sun light tracking glare/flare can already be done through VGUI (or through a custom OpenGL renderer if you are using one).

Quote:
The flashlight is awful, there are bugs
Something to take in account is that dynamic lighting was "expensive" in old engines. Make a 32 players listen server and spawn 31 bots in the same room, have them toggle their flashlight at random intervals (or just have them all on) and you will see that even modern PC will suffer from huge FPS loss.

Quote:
RGB Chat will be possible??
This can be already done if you write your own chat in VGUI instead of using the HUD one.
19 Jul 16, 22:33
By Solokiller
avatar
Member
Yeah, chat colors are defined in the client library. It's up to mod devs to add support for it. Alternatively, client side scripting with hooks for chat handling.
19 Jul 16, 22:41
By DiscoStu
avatar
Member
It exists because many mods use it for team chats.
20 Jul 16, 11:31
By EsprimoP
avatar
Member
You can make a VGUI chat? Prove it.
20 Jul 16, 11:39
By Solokiller
avatar
Member
Oh that's easy. Just handle the messagemode and messagemode2 commands in the client's HUD_Key_Event function and open a VGUI panel there. Close it when you get an enter or disconnect/mapchange event. Granted, there are no hooks for that AFAIK, so you'll have to work around that, but it's possible.
20 Jul 16, 12:57
By JeffMOD
avatar
Call 141.12
Quote:
Parenting!

Wait hasn't Spirit had that since, like, 1.0?
20 Jul 16, 13:04
By Penguinboy
avatar
Haha, I died again!
The biggest deal for potential engine updates for me is the networking efficiency. Imagine being able to play HLDM with people all over the world and it actually being semi-playable!

I was hoping that the networking would improve in SC5, but if anything it seemed to get worse unhappy - :( (admittedly, I haven't tried it since it released, maybe it's better now)
20 Jul 16, 13:22
By Shepard62700FR
avatar
Member
Quote:
The biggest deal for potential engine updates for me is the networking efficiency.
Agreed, client prediction could use a complete rewrite because it's doing more damage than good.
20 Jul 16, 13:53
By Solokiller
avatar
Member
SC5 has worse networking because they moved a lot of client side code over to the server for customization purposes. Combine that with the increased limits, which required an increase in delta.lst settings and you've got tons of bandwidth being wasted.

If entity A has to send 10 bits for iuser1 then all of them will, even if the other ones only need a single bit. Even when it's compressed, there's no guarantee it'll work out fine. Some entity might be naively setting a boolean as any non-zero value, which won't be efficiently compressed.

I suggested allowing the game libraries to set per-entity class settings, but i doubt that'll happen. I also suggested using CBaseEntity on the client and doing what Source does, even built a prototype for it. I was told it would be too much work.
It'd be great for writing dll agnostic code, as well as allow code to be moved over to the client, eliminating a lot of bandwidth usage in the process. It would break mod support though, possibly even Metamod if you allow any CBaseEntity member to be networked.
20 Jul 16, 18:43
By DiscoStu
avatar
Member
What do you guys mean by "SC5"? Because my brain fills it in with "Sim City 5" and it could very well apply to what you said.
20 Jul 16, 18:53
By Suparsonik
avatar
Withstood the post-nuke test.
Sven Co-op 5.0 AKA the standalone release.
20 Jul 16, 21:06
By DiscoStu
avatar
Member
Right, my bad. Thank you. I'm not too familiar with it.
20 Jul 16, 22:11
By fuzun
avatar
Member
This may be a bit off topic but what exactly is,
fuser
vuser
iuser

And

RPG weapon set some values of vuser but why -for example- mp5 don't
21 Jul 16, 08:18
By Solokiller
avatar
Member
Those are all user variables. They were added to allow mods to share state with the physics code and the client. Entities, weapons and clients all have it.

The RPG sets it because it has additional data to share. Specifically, the number of rockets and whether the spot is active. I don't know why they added it to the clientdata_t instance, but i was going to move that code in my SDK copy.

If you've ever worked with networked entities in Source, think of them as CNetworkVar instances, only hardcoded. The settings for them are in delta.lst.
08 Aug 16, 23:08
By abbadon
avatar
Member
I only wish the engine could handle a bunch more entities, models, sprites, based on actual hardware instead of 1997's hardware... In fact I want to get rid of the "ed_alloc no free edicts" thingy tgat makes my mod crash again and again...
09 Aug 16, 18:43
By Solokiller
avatar
Member
Have you tried increasing the maximum number of entities using the -num_edicts or edicts liblist.gam setting? ed_alloc issues usually happen when you run out of entities, so increasing it to its maximum (2048 iirc) should help.
09 Aug 16, 20:44
By Unq
avatar
Member
You can put the edicts in liblist.gam? I was only familiar with the Launch Options setting.

And last week's Steam update broke the Launch Options for HL1 mods for me. unhappy - :(
10 Aug 16, 20:47
By abbadon
avatar
Member
Yes I have tried, but it doesn´t work, the only way is through a new and upgraded version of the original HL engine.
10 Aug 16, 21:28
By Solokiller
avatar
Member
@Unq:
The engine checks liblist.gam for it, so i think so yeah.

@abbadon:
You can always try running under Svengine, if you're willing to risk your mod breaking due to an update. It supports up to 8192 entities, provided you adjust delta.lst accordingly.
11 Aug 16, 13:36
By abbadon
avatar
Member
Svengine?, how can I use it? is a new hl.exe? O_o
11 Aug 16, 13:46
By Loulimi
avatar
Member
I think it's the modified Goldsource version Sven Co-op is using.
11 Aug 16, 14:23
By abbadon
avatar
Member
So you say thst I have only to put my mod's dir into the Sven dir and that's it?
11 Aug 16, 16:22
By Solokiller
avatar
Member
Probably not. Your mod will use Sven Co-op's assets as the default, so if you are currently using the same VGUI resource files, sounds, models, etc, then you'll end up using SC's instead. It might take some doing to get it to work under Svengine like it does under GoldSource, but you'll have increased engine limits. Whether it's worth the effort is up to you.
11 Aug 16, 21:19
By abbadon
avatar
Member
Mmm, I think I'll stick with GS until an upgraded version is released, at least in what's about entity limit, I pass of the rest of fancy things like bump mapping, glares, etc.

Btw: I have sent a similar letter to Valve, giving them a full dossier about what I was doing and asking (begging, yes, I admit) for a solution for the max entities/models/sprites/etc. issue, and they never answered... unhappy - :(
12 Aug 16, 02:31
By hfc
avatar
Member
i read somewhere on the twhl but i dont remember where, "valve wont open GS's source files. because they want source engine will be used for making games" if we want to use improved goldsource use source engine instead.

nevertheless it will be nice if Valve will let us to modify GS. we can overcome the limits. then bigger maps bigger textures and such things will be usable by old half-life style modders. and also we will make another version of improved goldsource that includes new technology. and this will be very usable by GS modders wants to make modern looking game and dont want to give time to learn a new engine from scratch.

in my personal opinion i will move to another engine, if there is a easier modable and bigger limited and simple engine. because sadly there is some bad things in GS for my laziness grin - :D . there is too hardworking things in goldsource engine. for example making and using new textures are hardwork, first find proper textures then convert 32 to 8 bit then pack them into wad file then use them in hammer editor.

if there was a UV like property of a map brush i will export all UV's of map file and then i can texture it with my concept. just like in a modelling software. but in original goldsource hammer editor's texture applier sits between texture files and UV coordinates of a brush. this is making lots of design things complicated.

i mean GS mapping feels much like "there is a door and wall picture on the newspaper lets cut and fold it to make a model house". but it will be much easier if "lets make a house model with clay dough grin - :D then paint with my imagine" this is much flexible design process than goldsource's. i think more flexibility means more lazy frienly. overcoming slow modding process will vastly improve design ideas.

disadvantage of this flexible design is, the map geometry and texture design will effect each other. you cant use every texture on every brush. but this design will let people to make a game instead of a mod. if i can modify the goldsource to overcome that texture problems it will be nice because this new engine will be easier use to other game maker engines such as unreal and unity

btw what is the reason of wadding the textures? i wondering that so much. if someone knows that please tell me.

it will be nice if we can raise the limits. then we can use models instead of most brushes that no intersects with play area. for example we can use 3d sky to make open world maps in new goldsource games. that would be cool. imagine modders will make a real arizona desert in their mods instead of making small enclosed area that uses the desert texture and still can use old half-life gameplay stuff on that grin - :D

and we can make a game maker engine on goldsource engine such as unreal. imagine that if we will make a editor that will use virtual programming style (whatever is this programming style's tecnical name) instead of c++ environment of original goldsource modding. and we can add smart prefap placing on maps just like in unreal engine for example we can use foilage tool and easily place lots of prefabs such as debris or rocks in one pass. but this virtual programming game maker engine must use classic vanilla half-life graphic engine otherwise it will useless to make this i mean we can go unreal 4 instead of making this. but if we use normal hl engine for this it would be super awesome for lazy GS modders. grin - :D speeding up design time makes vastly improved designs.
16 Aug 16, 18:22
By Loulimi
avatar
Member
Has the letter been communicated to Valve or the Github discussion is the only thing they could get?
We could send Gabe Newell an email (he posted it somewhere on reddit), or send Valve physical letters (well, it would be mostly a task for residents of the USA).
I think that if we make some communication we could get more people involved, not necessarily active HL1 modders, but former ones, HL1 fans, gaming passionate, code freaks, open-source militants...
HL1 is still a big part of the gaming culture even for people who never played it, and thus I think a lot of people could feel concerned.

Ross Scott, the person who made Freeman's Mind, has called his viewers for action against EA's habit of killing games (by making them online-only games, then shutting down the servers). He asking his followers to send letters to the company. His call has been forwarded by other and bigger Youtubers. While the fact that the Goldsource engine is closed-source is not exactly killing games, it makes their future unsure and slows down modding. Maybe him or other youtubers would like to do something for the open-sourcing of the Goldsource.

I don't believe that we can gather thousands of people to join our cause but what do we have to loose?
We could otherwise ask to have at least some people have access to the engine. Valve trusted some of the Sven Co-op developers after all.
17 Aug 16, 21:42
By Solokiller
avatar
Member
The letter has not been sent yet. I will be doing that soon (maybe tomorrow), after i've done something about this: https://github.com/ValveSoftware/halflife/i
ssues/1739


I've made a proposal for new interfaces to cover some missing stuff. If open sourcing, licensing and limited access all fall through, this should be a reasonable alternative to cover some serious known issues.
I can do 99% of the work for them, all they have to do is add it to the engine and insert some function calls.
I'm not kidding, i can tell them where in the engine to put the calls. It's trivially easy for me at this point.
17 Aug 16, 23:53
By Penguinboy
avatar
Haha, I died again!
Not wanting to sound negative, but has any issue on the HLSDK repo had any attention from Valve employees recently? Unfortunately posting there just seems like wasted effort...
[1] 2 3 4 5 6 7 8 9 10

Forums > HL Engine Discussion

Login to Reply

You must be logged in to reply.