Page 3 of 4

Re: CTF-Blice (Release)

Posted: Sat Sep 05, 2020 7:29 pm
by EvilGrins
Feralidragon wrote:
Sat Sep 05, 2020 1:20 pm
I do intend to eventually release a beta with some performance improvements and the cloud zone fix, but only after 469 is publicly released, that's why I never actually ended up doing it just yet.
Do you mind if I do some work on it in the meantime? As is, minus the hungry clouds of flag eating, it plays great. Just needs some fixing.

Re: CTF-Blice (Release)

Posted: Sat Sep 05, 2020 10:03 pm
by Feralidragon
You can do whatever you want with it. :)

But, I don't think you will be able to do much unless you use UEd 2.2, which is currently part of 469 and Unreal 227j, both unreleased, since those editors are the only ones which are able to build this map without crashing.

So if you want to edit it, you will need to ask access to 469 at least.

Re: CTF-Blice (Release)

Posted: Sat Sep 05, 2020 10:05 pm
by Red_Fist
I think you can do as you like, just don't upload it anyplace.

Painzones are,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,such a pain :roll: :loool:

Going to check it out, I never did understand "bloom" I always turn it off for other games because I just don't see what is so good looking about it, what is it, supposed to look like, or accent.? :noidea

Re: CTF-Blice (Release)

Posted: Sat Sep 05, 2020 11:01 pm
by Feralidragon
To put it simply, the "bloom" effect is just the glow you see around light sources, for example:

It just so happens that many games overuse it to the point that you see bloom everywhere, including from things which are not light sources.
UT has a rendering mod which is able to apply bloom to everything, making everything look like it's emitting light, which for me just looks awful and may even lead to headaches.

But when used well, namely only on things which are supposed to emit light, and moderately so (not on too many places, and not too strongly), it's an amazing visual effect that makes light look like actual light, like energy.

Normally bloom is achieved through the renderer itself (through a fragment shader), and is a fairly simple thing to implement.
In UT however you don't really have this, so in this map I tried to approximate to the real bloom effect using my own dynamic corona system from a package I developed years ago.

Trivia: some older engines with "bloom" support did exactly what I did here, like the engine used in Fallout NV.

Re: CTF-Blice (Release)

Posted: Sat Sep 05, 2020 11:41 pm
by Red_Fist
Thanks for that, seems like bloom would be good around control panels or electronic screens. Or around windows while your inside some building.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 12:19 am
by EvilGrins
Feralidragon wrote:
Sat Sep 05, 2020 10:03 pm
So if you want to edit it, you will need to ask access to 469 at least.
I already put Warlords on it just to test... worked fine, and I don't have that.

Will alert the "team" just in case.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 12:40 am
by Feralidragon
If you're just adding stuff like that, then there's no problem, you can do it in the current UEd.

But if you do anything that requires either a BSP or lighting rebuild, that's where you're going to have issues in the current editor.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 9:36 am
by sektor2111
UGold227 can re-build map (in steps, as I usually do), but I don't think this is needed unless are done major changes at geometry and lightning, 4716 Lights :? .
And this is LITE version...

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 10:46 am
by Buggie
v436 able rebuild map. Just need set 1/60 options for BSP and switch all viewports to planar view before rebuild.

Also BSP here is hell. Not because high count of brushes. 4663 big count but not fatal. I worked on map with 7468 brushes and it run fine.
BSP hell here because of bsp cuts which intersect everything mostly everywhere.

I think if work with BSP and proper adjust solidity and other stuff, then count of nodes reduces significantly.
Of course I speak not about Lite version.
Even simple merge polygons get great result.
On left result from rebuilt map in v436 as is as.
On right result from rebuilt map after select all brushes and apply merge polygons command.
On map present some movers which works as semisolid. Possible better convert it to semisolid, because Movers out of BSP and can not be optimized at build.
For fix CloudZone eating Flag need set bPainZone to true and DamagePerSec to 1.
It fix issue for most cases. But sometimes flag not return to base somehow. In any case it is better from nothing.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 1:46 pm
by Feralidragon
Feel free to do any optimizations you want for investigation purposes, but again, this is meant as a benchmark map, so everything you see there has a good reason for having built that way.
So I will just explain some of the decisions made so you and others understand the reasoning for everything there.

To start with the BSP itself, I will actually defend my own map by saying that everything is exactly right where it's supposed to be BSP-wise.
While some optimizations can certainly be made, all the applied BSP solidity is exactly how is supposed to be: anything that can be a semi-solid is semi-solid, and everything else is either solid or non-solid, whichever one they must absolutely be.

Maybe you can shift a bit how the BSP is built by turning one or another semi-solid into a solid, but that's something I will personally always refuse to do, because I wanted to end with the kind of map which could be improved over time, as in changing the BSP around and rebuild it, not for optimization purposes, but just for improvements in the map itself.

That is to say that if optimizations are possible by changing the solidity of BSP, then those optimizations should come from the actual BSP builder, similarly to how you expect a good compiler to apply the right optimizations into your code without forcing you to apply your own assembly, since a developer's or mapper's primary concern should be maintainability, and not optimization, since maintainability is far more important, and far more expensive over time.

A lot of improvements both in the BSP builder and lighting builder in the 2.2 editor came from exactly this sort of thing, which will lead to far more stable maps in "normal" cases.
Which again, is the whole point of using this map as a benchmark for improvements, similarly to how you had to improve your UZ in order to be able to compress this map.

Also, a lot of the BSP intersects because the map is BSP intensive, featuring both major and minor details everywhere you look, because it's actually meant to be that way as well, so the "BSP hell" you're mentioning is perfectly normal and expected, but is not out of control (again, benchmark material).

Absolutely everything you see was planned for, which of course includes the movers themselves.
Normally they should indeed be semi-solids, but in this case they really must be movers: as you can tell, the map also features a dynamic corona system of mine, which is able to simulate something close to a "bloom" effect from more modern engines.

I wanted this system to be able to render these coronas across transparent surfaces (like glass), but it's currently impossible to detect whether a surface is transparent.
So instead I made it so that you can set coronas to be able to be rendered across movers, since that's something that can be distinguished from normal static BSP, and that's why movers were used where you see them.

Of course, I could instead detect the surface texture, and treating some textures as "glass", in the same fashion I already do so in NW3 for example, and that way I could use static BSP instead, but the whole system was developed in just 2 days (and several years ago), and it would be less efficient and bound to whether decals are enabled or not.
Not a big problem though, might do it that way in the future if I ever create a better package.

And as a last note: the number of brushes in a map say absolutely nothing about its compexity.
This entire map could be just 1 single brush (which would be dumb, but it's possible).

That is to say that the only reason you "only" see about 4.6k brushes is because I actually merged most of them together.
If you click and check each brush, you will notice that there is a ton of brushes merged together as a single brush, like all the trims around, rails, etc, etc, meaning that if you compare this map to another map in brush count size, that comparison won't be very accurate, since 99% of the mappers do not merge their brushes at all (and I have seen many many maps), meaning that the real number of brushes originally may actually be about 3x that value, so likely maybe around 14k brushes total if I never merged anything there.

So be careful, never judge a map by the number of brushes, especially from a mapper that merges a lot of BSP together as single more complex objects.
Which, btw, these merges were meant to establish the map fundamental "parts" if you will, just like nowadays maps are built out of static meshes put together, but developed in parts, I applied a similar concept while building the BSP, so when you select the brush of a rail, you select the whole rail and not just a tiny part of it, which would be a nightmare to manage.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 2:19 pm
by Buggie
Solution for fix CloudZone eat Flag:

Code: Select all

// MyFlagBase.
class MyFlagBase expands FlagBase;

function SpawnFlag() {
	local CTFFlag myFlag;

	bHidden = false;
	if ( Team == 0 ) {
		myFlag = Spawn(class'RedFlag');
	} else if ( Team == 1 )
		myFlag = Spawn(class'CTFFlag');

	myFlag.HomeBase = self;
	myFlag.Team = Team;
	CTFReplicationInfo(Level.Game.GameReplicationInfo).FlagList[Team] = myFlag;

	myFlag.SetTimer(0.1, false);

auto state Checker {
	if (CTFReplicationInfo(Level.Game.GameReplicationInfo).FlagList[Team] == None || 
		CTFReplicationInfo(Level.Game.GameReplicationInfo).FlagList[Team].bDeleteMe) {
Test map included.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 5:58 pm
by sektor2111
I think this code is more simple and short.

Code: Select all

class MyCloudZone expands CloudZone;

event ActorEntered(actor Other)
	if ( CSMCXActor(Other) != none || Decoration(Other) != None )
It should not "swallow" Flags anymore... and if zone is set as a damaging one, Flag is automatically sent at its home place.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 6:18 pm
by Buggie
Short but not general. What if Flag destroy something else? Like TriggeredDeath + bDestroyItems = true?
IDK what else can destroy Flag else but possibility exists. my solution is bullet-proof against any destroy Flag. Even from bad custom code.

Try this:
TriggeredDeath is red light.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 7:03 pm
by Feralidragon
Actually, you're both right.

On one hand, the flag base should be prepared to respawn the flag if it gets destroyed for any reason at all.

On the other hand, CloudZone should not destroy everything that enters it, it should at least not try to destroy some types of actors, and have the necessary flexibility so the mapper can configure what it can and cannot destroy on top of that.

In the case of this map, it's pretty meaningless which one to apply, both ways fix the problem with this map.
Engine-wise, both sides should be fixed.

Re: CTF-Blice (Release)

Posted: Sun Sep 06, 2020 7:53 pm
by TexasGtar
Super cool map. I gave it a few runs last night. Ran fine on my machine.
The map itself is just really nice. I think I felt warmer as soon as I left the snow blowing outside areas. lol
Very nice ambiance. Not sure what this structure's purpose is, but it's great to look at and I just really enjoyed the entire visual platform.
I have a fantasy draft tonight, but after that I plan to play some matches and see how it handles full load of teams. I just basically ran around and got a feel for the areas.
The glow-y neon lights inside is a really cool looking corona effect. I really don't have any complaints. Well done.
Great map and I don't see why this is not designed to be played. Maybe it's designed to push the limits or test stuff, but it is still a solid map and it will get played.

Thanks. I just can't think of enough nice things to say about it. I just really enjoyed it. It has a straight forward layout and plenty of eye candy.
For those that haven't tried this map yet, bring your hand warmers. :)