Post your screenshots! WIP thread Created 16 years ago2007-12-16 00:58:58 UTC by doodle

I guess I'll have to figure out how to do that. Thanks.

I may as well post some pictures when I'm done with that so we can be on-topic.

@Crypt Will do when I get a minute.

This midsection was a real bitch, and will continue to be while I tap the remaining holes on the bottom. Next time I'm not chamfering any edges until I know I will have an equal amount for the holes that will be put in later.

@Victor That is the first time I've seen somebody use func_train for an actual train.

@Shepard62700FR

"nice try son, you forgot one thing : clipnodes."

Nice try, and that "try" had its success in one of my maps.
If you've seen my The Specialists map, ts_untergrund, you'd have noticed that it has a lot of triangles and tetrahedrons. The rest are, well, 4-sided prisms, i.e. usual brushes.

I only had the clipnodes problem when I converted the terrain into a func_detail. But then we have the bevel texture which supposedly removes clipping from the surface it's applied onto.

@Victor That is the first time I've seen somebody use func_train for an actual train.

technically it's 14 func_trains set to passable, with a ton of func_wall_toggle and trigger_hurt to maintain the illusion of running people over; if I simply relied on func_train collision detection they'd "stick" on people and get out of sync. It's split up because if they were all one brush entity it'd be longer than Hammer's max allowable dimensions.

@Admer : Your map has nice terrain for the Gold Source engine and if it runs well on old PCs then it's good. But I think you missed the point that HL2 displacements is a different story than what GS mappers can achieve with vertex manipulation.
Add the fact that Source maps are x4 times bigger than Gold Source maps we can conclude that standard Gold Source will likely cry (I even doubt if the map would be compilable).

Take a look at this image I've found on Google Images :I highly doubt that if you replace the displacements by brushes under GS it would compile.

@James Luke : about the physics engine, I think you don't really need to access engine data to achieve that. Server side should be enough.

@Sherpard:

I just checked, there are some physics calls being handled within the engine.

But that aside, it would be a lot better to handle everything client-side. Not as many pre-defined limits there. Also the networking would kill your PC...even after having like 100 physics-entities. And I have a relatively powerful computer.

The only problem would be is changing the physics code engine-side to handle Newton within Half-Life, and allowing for collisions with Newton objects. Regular Half-Life only supports SIMPLE collisions. Very SIMPLE collisions.

That's why HL2 changes that with Havok, it adds new collision types that makes it compatible with dynamically-shaped objects. But that's done in the engine. Which is locked closely by Valve. Hopefully they can change that sometime though... But I highly doubt it. Even then, I still have to fix it because I found some way to break it. Something about random access violations.

was doing some more textures for fun

@Trempler

It looks great.

Anyways, starting to add in all the effects. Decided I'm gonna use VGUI for the HUD now. No more nasty sprites and that would free up some precaching limits I believe.

Just gotta get that done and the renderer, along with completing all of the weapons, for now...they're just fancy viewmodel displayers.

Also did the lazy-weapon from an old HLFX.ru tutorial. But there are flaws like waving the weapon up-and-down makes the viewmodel look STUPID. But that aside. Progressing well. Here are some test screenshots.

Well, just finished implementing the renderer. Needs a lot of fixing and cleaning up since it was written in 2006 and needs an old .dll that will """"break"""" it if it isn't there.

Wonder if I can ever set the depth-ranges without the .dll...or the stencil buffer and alpha buffer...

@Shepard62700FR
I saw a map on GameBanana which took 15 days to compile. Guess because of who? HlVis!
To be honest, I would be fine with letting my laptop compile a map as long as that, lol.

Interestingly, I have a Half-Life map, FILLED with these triangles (inside a 2048^3 area) and HlVis runs it all in under 4 minutes.

Well, I admit, it doesn't have very high-poly terrain. They're in the parts of the map. One part is very detailed, the other part isn't so detailed. I.e. one is higer-poly, and one is lesser-poly.

And this is where problems start...
Some triangles (even if they're covered with a non-null texture) still appear invisible.
But, other than that, I haven't had any major problems with triangular terrain.

Mmm, yeah. There's 1 additional problem. This long compile time is in fact very needy and greedy.
I compiled ts_untergrund with fast HlVis. triggers everyone
So, when I'm standing on one specific place, all the entities go invisible.

---

I only experienced these problems:

• Long compile time (although, I am patient and willing to wait :3)

Well, I have an almost-10-year-old laptop! Of course it takes forever. I wonder, though, how quick would the Core i3-6100 do the job. ;D
______________________

• Some missing faces (not a HlVis bug)

I don't know. Locate the brush and cover it entirely with non-null textures? I can always try.
______________________

• Invisible entities, if standing on a specific spot (fast HlVis)

This one could also be that the player exits the 4096^3 area, but I doubt that.
______________________

• Max clipnodes exceeded if I turn my terrain into a func_detail

So, the clipnodes one was fixed this way:
I selected it and turned on "passable". Then I copied the whole terrain on the same spot and covered the copied one in CLIP (only the top faces, the rest was in Bevel).
Yeah, much effort for a not-so-great improvement.
______________________

But still, us mappers can find a way out, most of the time. :3
Right?

As a Source level designer, I cry at the idea of VIS taking more than a fraction of a second, let alone 15 days.

I remember when i first started mapping in Source and it took 30 minutes to compile the map. That was bad enough, but 15 days? How complex is this map?

I was talking about GoldSource, not Source.
And it's true, compiling Source maps takes waaay less time than GoldSrc.

I was so so surprised that 1 simple room with 1 light took like 2 seconds to compile for Source. Meanwhile, it takes longer for GoldSrc.

And hey, I usually wait 5 or 10 minutes for VIS, and then 30 to 40 minutes for RAD, for GoldSRC.
I guess that's what happens when you have a 10-year-old laptop with a 2.4GHz dual-core processor with 2GB of DDR2 (Shepard gets triggered) memory.

As for the map itself, let me find it...
It's basically a map from Rainbow Six: Siege ported to CS 1.6.

I think the problem with GS compiling is that the compilers themselves are old and unoptimized. Basically built on top of quake compilers used in the first versions of GS.

Someone could really do a rewrite for them instead of making "yet another goldsource renderer"

And if someone could point me in the right direction that explains the whole process in detail i would appreciate it a lot.

I remember that one of my old CS maps (de_caceres) took 39 hours to compile on a P4 3.2 Ghz laptop with 1 GB Ram 400 mhz. The poor bitch was almost fried because of it!!

Wait, a Pentium 4 with 3.2GHz!? I only thought they were around 2GHz.

Yeah, I wonder what if someone makes a GoldSrc version, of the Source compilers? Then some people could easily take incorporate the Lightmap Scale option into a map editor, for example.

And, there's one thing I must say during compiling:
NEVER SET PRIORITY TO 'REALTIME' DURING COMPILING.
Always remember this. This applies to hlcsg, hlbsp, hlvis and hlrad.

Basically, the "realtime" priority is only for the mouse and the keyboard, i.e. the main input devices! If you choose to set the priority to real-time then your mouse, keyboard and the entire system might freeze.
It happened to me once. :3

I wouldn't recommend even -high, tested Tremplers Stalkfire on my i7-7700k, with compilers set at high i got only a 10 sec gain from compiling on -low (which is the default for vhlt) the PC was unusable during that time.

Yeah, I tried HlRad with -high.
My laptop was suffering, and I had to kill hlrad.exe.

So yeah, I guess that we came to a conclusion:
If you want a detailed, outdoors map, just be patient and wait until it finishes.

What jacksepticeye said: "Speed is key!" is false.

lightmap scale has nothing to do with the compilers or the editor, its in the engine

Huh, I didn't know that.

lightmap scale has nothing to do with the compilers or the editor, its in the engine

Lightmap scale do affect the compile time, since a lower lightmap scale requires more calculations on a single surface. Lightmaps can therefore be optimized where high quality lighting isn't required, or in low-contrast light areas.

lightmap scale has nothing to do with the compilers or the editor, its in the engine

Lightmap scale do affect the compile time, since a lower lightmap scale requires more calculations on a single surface. Lightmaps can therefore be optimized where high quality lighting isn't required, or in low-contrast light areas.

@rufee : if I had experience with multi-threading, GPU computing, CSG, BSP, VIS and RAD I would have looked at it.

Last time i looked into the compiler code i saw a lot of platform specific code using ancient APIs. You can redesign them from scratch more quickly than updating them.

Wow!, instead of ZHLT there will be PSCT!! (Power Source Compiling Tools).

I vote for: GPCT!
(Gold Polyhedron Compiling Tools)

Coming in 1st April, 2033, at 4:20 PM., exactly when Half-Life 3 releases. (OK, you could ignore these 2 sentences because it's a joke xD)

I don't know, it sounds cool!
BSP-based mapping (CSG should be appropriate, too) is basically about polyhedrons. So, I think it's OK.

Yeah, I was having a good look at the terrain capabilities in Source and trying to mimic them in Goldsource.

May have gotten way in over my head with this project. REALLY way in over my head.

But it did get me thinking.

Aside from the pain in the ASS that is PARANOIA's renderer and meaningless code in the old SDK. I decided to start having a look at the interface system Valve left in.

I also looked into Half-Life 2's code and saw the same thing...but for physics objects/collisions/terrain. What if we could mount the HL2 .dlls into Half-Life 1 and be able to do basic terrain or physics collisions. Kinda like what Solokiller is doing with VGUI2 in HLEnhanced? Is this possible? I think it would require a massive overhaul with Vectors and all that stuff...but maybe someday?

Say drag the .dll over and extract the interface version/names and use the CBaseGameInterface from HLEnhanced to hook the .dlls over and bring out the functionality to at least get something to work, like building a physics-mesh and seeing it or seeing displacements. Obviously implying it will have it's own interface file.

On another note, might have to ditch the renderer and wait for a better one. Or maybe switch to Trinity. Or at least the client-side entity manager.

EDIT: But we should have a cleaned-up version of VHLT that is optimized. Sure mappers could use that and get way better performance.

I don't think you can use HL2 DLLs within HL1

That'll never work because you'd need the engine to implement support for it.

Meanwhile, Source is just... there. To use. Like, for free.

But nah, why use Source for it's features when you can try to make a bastardized version instead

Im also kind of against all of these hacked up clone engines. But it is what it is.
We are just stuck in the past apparently

1000x this ^

I wouldn't exactly say were stuck in the past.

It's just fun to find out what we can do with an old engine.

Like 5 minutes after posting that I just had a look in the source and saw there were calls in the engine.

But if Valve stopped being lazy and released the engine already, then might it be possible? I wouldn't doubt it would require an overhaul and would be impractical, but maybe?

What if Valve secretly wants us to use Source and phase out GoldSource?

They've certainly neglected it at least.

Last Github commit: Latest commit 5d76170 on Dec 30, 2014. And I can't remember the last Steam update for it except the beta. And they say they are only fixing critical game-breaking bugs. If that.

Yes, but at some point the new updated engine would go too far out of scope to be even called GoldSource anymore.

I am a purist in this sense that i believe all the bugs, limitations and everything else is what GoldSource truly is and should not be messed with, if this is why Valve is not releasing the code then i applaud them. Even if they would what would happen? Suddenly all the bugs would be fixed? I doubt it, i can bet you Valve would be too lazy to release the updated version on Steam anyway. Last i checked unless you are a die hard Russian non-steam HL player whatever the majority of players are on Steam. Look at Id Software, they release all their old engine's, sure there's a ton of mods, but if someone plays them its probably the original game. Its the same here.

Even if i sound like a crusader for 1 engine i have nothing against all of you who do make these engines, it proves that you know what you are doing, but i believe your skills and talents are better put to use somewhere else.

I'm just gonna leave those here :

Server redirection exploit (AMXX example) - Reported 9 Feb 2014 - NOT FIXED

Recent Update: DayofDefeat crashes after some time with SegmentationFault (Linux) - Reported 20 Dec 2015 - NOT FIXED

Console command "speak *anysoundfile" will crash game - Reported 27 Oct 2015 - NOT FIXED

https://github.com/ValveSoftware/halflife/issues/1622 - Reported 25 May 2015 - PATCH STILL WAITING TO BE ACCEPTED FOR EVERYONE TO USE

Add all the dangling pointers, memory leaks, crashes tickets reported by Solokiller and you'll see that Gold Source is starting to be messy.

if this is why Valve is not releasing the code then i applaud them.

Quote from here :

Once a year someone talks about maybe pulling it together to open source it but once again there are not resources to do the actual work need to package it up. The Sven Co-op team was luck in that there was a package and someone to make it available to them, that does not exist today.

i can bet you Valve would be too lazy to release the updated version on Steam anyway

You are right, Valve can't monitor 540545640 versions of Gold Source. But developers can provide the changes as some kind of "unofficial patch/port" like ezQuake, Darkplaces does for QuakeWorld. Those who prefer to stick on standard Gold Source stick to Steam, those who want more stuff would look to these ports.

@Victor933: That is one lovely level crossing. My only nitpick is that the signal lights are wrong* ;P

While I was watching the video I heard a sweet distant train horn as the lights changed, I thought it was amazing sound work and went back to hear it again... and it wasn't there. Went back and forth several times and I couldn't find it. Turns out I heard an actual train in the distance out my window.

*Wrong means: The one on the left is red because duh, there's a train coming. But the one on the right should be green, signalling clear to the train, otherwise the train should stop right there or it would most likely crash onto another train that's either stopped ahead, or worse, coming in on the same track in the opposite direction.

@DiscoStu

My only nitpick is that the signal lights are wrong* ;P

The signals do change. They switch to yellow first, then green, then switch back to red as the engine passes.

In my defense I was too distracted by OMG TRAINS

Once a year someone talks about maybe pulling it together to open source it but once again there are not resources to do the actual work need to package it up. The Sven Co-op team was luck in that there was a package and someone to make it available to them, that does not exist today.

Someone made it available, who's that someone? 5 min question for Valve to ask internally. If Valve's intentions are to open source it and only sven has the code then get the code from sven... (Has no one thought about this?)

While the ability to execute commands on the client side is an ethical concern and should not be done. The command is there and therefore is a feature which can be used for things like redirecting players around or worse. Ive though many times to write a server reverse proxy for my needs.

I seem not to be able to stop derailing this WIP thread

Isn't it a little too late? VALVE/Sven team kind of lost the moment to open their sources because we now have:

• opensource Xash3D
• opensource ReHLDS
• unnamed opensource engine client implementation (not complete yet)
• opensource sp/mp/coop mod - XDM
• opensource tools
• alternative map editors

So, when (if) VALVe(r)(tm)(wtf)(gtfo) suddenly decides to open their crap, we won't be needing it anymore.

Valve doesn't like Xash3D for various reasons and I don't like Xash3D too.

I dislike VALVe and closed-source stuff a lot more.
Like it or not - Xash3D is currently the only working alternative to proprietary GS. And people working on its portability. You probably seen it working on ARM/Android.

I don't like Xash3D too

I like it because it overrides most of the limits of GS engine.

I did read a lot about Xash3D, and I am still wondering what did the Xash3D "steal" from Valve to make that company so angry. If we believe Valve, the HL code is 99% Quake source with less than 200 lines of new code, so, are those 200 lines of code what Xash3D team "steal"?. Well, I am simplifying it too much, sorry.

But, and this is other question, could the parts that are supposed to be "steal" code be developed through other ways apart of simply stealing the code?, is it proven that Xash3D guys did steal that code?. I am so confused, overall with the Quake part. I can not understad why an engine done with free software, as the Quake source is, is taken in a so low consideration if it´s done with code available for anyone who wants to put their hands on it.

Of course I understad that for many of you any kind of piracy-reverse engineering is like killing a dolphin with a spiked club or so, I don´t like this kind of things, don´t get me wrong, but I am not sure where to put Xash3D developers in that list of undesired persons.

Apart of this, there´s the fact that Valve don´t care a s***T about developers, and they don´t care about what they´re doing with GS (look how they ignore Solokiller´s E-Mails)... :/

I hope Solokiller release some day the PowerSource SDK along with the Powersource engine with VERY extended limits that will depend on actual hardware specs that are 100 times higher than in 1997.

been working on an On A Rail inspired DM map for a few days (get outta my head @Snehk)

HL code by far is not Quake code, yes its based on quake and quake2 a little, but is leaps and bounds ahead of what quake was at the time, with Valves additions to the code. Models with bones to name at least one thing.

If the code is not 1:1 what they supposedly stole it doesn't count as stealing. Unless there are patents involved, which serve to protect the idea and the realization technique behind it in this case code which as far as i am aware is not patented. And there are also licenses. Anyway code theft is kind of hard to investigate, because you can always claim to have stumbled upon a solution which just happens to be identically coded as Valves.

Piracy and reverse engineering are not the same, they go hand in hand because RE can be used to crack DRM games and such and that's why media makes it look like its a bad thing. Granted 80% of all licenses have a "No reverse engineering" clause which i believe also exists in Valves license.

Back when Valve were making the engine the quake engine was not free or open source and they bought (licensed) it from Id Software (makers of quake). And even to this day all the Id Software engines are free for non commercial use, meaning you can't make any money off selling a game with the engines code in it. That's why i believe Valve does not care about all the reverse engineering that's going on with the GS engine. All this interest in it just makes Valve more money in the long run.

Valve is a very closed company and its no surprise they don't reply to his or anyone else's e-mails for that matter. The fact that he did get a reply is sort of a miracle

In the end you are here because you like working with this engine, i don't see you modding for Quake or any other open source even totally free engines so who's the real winner here ? (psst it's Valve )

...what did the Xash3D "steal" from Valve to make that company so angry.

IIRC, Xash3D and other sorts of projects that use it had code from the 2003 HL2 leak. Which is deemed illegal to use by Valve, and for good reason.

EDIT: Also, Xash IMO is lego-work that crumbles if you touch it, I appreciate the effort that the developers put in, I just don't like the end-result.

Yes!, at least with me Valve is winning!!

But I never said that I don´t like GS, I say that Valve policy about independant developers is not very clear or helpful, and in the case of Xash3D, unexplainabily harsh; afaik, Xash3D people is not earning money for its engine, or are they? Maybe I must read more and investigate more. :/

Also, Xash IMO is lego-work that crumbles if you touch it, I appreciate the effort that the developers put in, I just don't like the end-result.

It works fine, except for sprites, it does extrange things (bad colors or sizes, or sometimes they even show up), but I think UnkleMike is working on that, at least I hope so.

I say that Valve policy about independant developers is not very clear or helpful

Factoring in everything, today it sounds like this: Do what you want as long as you don't make money off it.