Mesh thoughts

Discussions about Coding and Scripting
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Mesh thoughts

Post by sektor2111 »

Yeah, they went busy to even make a mess with those interpolations and no one could join there ever, dying all time, I'm giving names this time "KasarulTextures" or such. I was sending an e-mail to admin for removing that crap, but he was only restarting server and soon map was voted again by some maps hunter, doing the useless mess again, and to be more fascinating that was added in a public redirect for being more spread.
At moon chapter perhaps it needs a bit of love depending on usage else it will be like boulders from CTF-Face - nobody could figure them ON-LINE - Inoxx didn't know NET stuff anyway...
SC]-[WARTZ_{HoF}
Adept
Posts: 426
Joined: Tue Feb 21, 2012 7:29 pm

Re: Mesh thoughts

Post by SC]-[WARTZ_{HoF} »

I really love this conversation Nels. I actually skim through this forum to read your and Higor's posts mainly. Otherwise I just mark forum read on most everything else. I have enough knowledge to know who here actually knows what they are talking about.
Image
Image
Image
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Mesh thoughts

Post by sektor2111 »

I did a few checks using 2 monsters (from those borked) ON-LINE but with some changes using... "EditActor". Pupae doesn't not show with legs buried as it shows in default... so new pivot works properly... hmmm, now I'm sitting down to think at fixing method - probably by modifying defaultproperties some fixing execution and check needed are going to be excepted from being done VIA UScript, or prebeginplay is the response as I was thinking first time. I'll see what is more suitable.
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Mesh thoughts

Post by nogardilaref »

sektor2111 wrote:Comparing my posts with bullshit posted by some members "addicted" here I think I'm posting 100 times more properly and exactly - no offense just reality.
Yes, yes, you're better than everyone else, got it.
sektor2111 wrote: Except that "Super.Tick" thing probably your code will help - this is what I want to see not "explanations" as long as maps posted by Barbie are not added on my playground and they will never be there - there are things with no single net code which have no place ON-Line, yeah, trash out :agree1: . Else, because we have ROLE_DumbProxy we don't need simulated functions here, those are part of ROLE_SimulatedProxy. About Net stuff probably I don't have any concern, collisions are SERVER's job and "meshed" actors are replicated as said by server not by client. Yesterday I could see what RemoteRole does toward simulated/non-simulated functions while I was playing with some "dynamic lightning" mapping related problem - it will be time for showing something in the right moment not in this stage.
Yes, I am aware that you don't need it to be simulated considering that its current remote role is DumbProxy, however when I posted that code with simulated it was to imply that these functions should run in the client rather than the server, with a SimulatedProxy and perhaps a few other changes depending on how the rest of the class is set up (which I didn't really look at).

Having that said, most of the workload of anything should be put on the client rather than the server, whenever possible.
The server should only run the things which are actually authoritative and have a direct impact in the entire state of the game at any given moment. Relying on the server to replicate everything without a care in the world leads to a great waste of both bandwidth (not major in current connections, it's more about the limits of the engine itself) and CPU (there's a good amount of processing being done by the engine just to know what changed and what to replicate, to whom, and to even compress some of it to spare bandwidth).

Being a mesh, or having collision, or anything else, tells absolutely nothing about whether or not an actor should run on the client or the server, it all depends on what the actor actually does and represents in the game.
In this case, the only thing you "fix" here is a visual detail which is only relevant to the clients themselves, for the server it has no relevance whatsoever, thus the PrePivot should be changed and updated over time in the client alone.
Furthermore, PrePivot is a vector, and as such is compressed and looses precision, which might or not make a difference, so you would either have to send each axis as a float separately, or you simply update from the client.

In the case of Pawns however, it seems that the only problem is generally the offset in the Z axis, and Pawns generally never pitch or roll, they only yaw, so for these I guess it's OK to let the server set up the PrePivot and replicate it once per spawn, or just set it as a default in a subclass, as it doesn't need to get updated over time.

But extending and customizing the actor directly isn't the only way of doing it, you could also build some sort of manager which would update things by itself, which would be easier and more flexible, as you would only need to hold a list of stuff to fix, and it could just far more efficiently iterate over them, but it's tricky since you would have to always guarantee that the tick of the manager is always the last one to be called in some way, to avoid an update unsynced with the actual updates on the other actors themselves, causing visual lag in terms of positions or rotations.

The most basic trick is to simply spawn a tracking actor after the pawn, and let it send the events to the manager, and then let the manager handle the pawn that the tracking actor is referencing, due to the order by which Tick is called in each actor (actors added last are called last, I don't remember if there's a use-case where this isn't the case).
This manager would exist in both the server and the client (due to the first replication, and since new clients joining must become aware of it from the server), but the rest would be handled fully client-side (including the tracking actors).
sektor2111 wrote: For the rest of fire offset problems I'm still curious to see a solution not explanations about "why that wheel it's a square" because it looks ridiculous, and explanations are making things to be more ridiculous. In each map which I do I'm writing some personal stuff and this is the reason for doing/speaking about some fixes - I need them.
Again, if you just wanted fixes, your very opening post would be far different, as well as the rest of your posts.

But let's focus on the fixin' then: starting with the simple case of the Slith, there isn't much that can be done there since the value is hardcoded.
However, you have 2 possible solutions:

1 - The simplest, is to extend the class and override the ShootTarget function and set a property instead with the correct value by default. Cons: replacing the pawn class in existing maps may break stuff up.

2 - Another one would be to detect the moment the projectile is spawned (SpawnNotify perhaps), check if its owner is a Slith, and move it a bit ahead accordingly.
Since, from your description, the problem is only when they are moving, but the engine is single threaded so only one thing runs at a time, so the projectile itself should be able to spawn without touching the Slith at all, and you should be able to move it to where you find to be the best offset, and you're done. Replication and stuff only happen at the end of the tick, so by changing locations at this point is not a problem.

SC]-[WARTZ_{HoF} wrote:I really love this conversation Nels. I actually skim through this forum to read your and Higor's posts mainly. Otherwise I just mark forum read on most everything else. I have enough knowledge to know who here actually knows what they are talking about.
I don't think you do. I think you're more latching on someone you know over the fact that you don't actually understand anything they are talking about, making others wrong to you by default.
If I am wrong, feel free to contribute to this discussion in an actual meaningful way. :wink:
User avatar
papercoffee
Godlike
Posts: 10443
Joined: Wed Jul 15, 2009 11:36 am
Personal rank: coffee addicted !!!
Location: Cologne, the city with the big cathedral.
Contact:

Re: Mesh thoughts

Post by papercoffee »

Guys!! Calm down...
For me it's very interesting to see how the developer used short-cuts. Not necessary clean and nice (and farsighted) but regarding a merciless approaching deadline was it for sure the best solution. It worked somehow and that's what count for a developer. Nowadays it's not different.
Terraniux
Masterful
Posts: 717
Joined: Mon Jan 05, 2009 8:08 pm
Personal rank: Banished member

Re: Mesh thoughts

Post by Terraniux »

If this topic question is about meshes, is it ok to ask a quick question here ?

The ChaosUT proxy mesh, the funny guy in the helmet, is a mesh you can walk through (non-solid). Is there an option to make it solid in the editor? Or does that require a total new mesh?
This member can only post when permitted.
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Mesh thoughts

Post by nogardilaref »

Yes, you can simply assign a collision to it. But it's not a property of the mesh itself, a mesh is always non-solid (is just the 3D model itself), it's a property of an actor.
So, just like you set a collision radius and height in a BlockAll and other kinds of similar actors, you can simply go to the same properties and set the collision, and activate it (the bBlock... boolean properties).
Terraniux
Masterful
Posts: 717
Joined: Mon Jan 05, 2009 8:08 pm
Personal rank: Banished member

Re: Mesh thoughts

Post by Terraniux »

nogardilaref wrote:Yes, you can simply assign a collision to it. But it's not a property of the mesh itself, a mesh is always non-solid (is just the 3D model itself), it's a property of an actor.
So, just like you set a collision radius and height in a BlockAll and other kinds of similar actors, you can simply go to the same properties and set the collision, and activate it (the bBlock... boolean properties).
Thank you, will try that! :thuup:
This member can only post when permitted.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Mesh thoughts

Post by sektor2111 »

And now to summarize recent past - do not get mad right now :mrgreen: :
- PrePivot is replicated in actor but... is not that used - lol, Epic;
- Monsters doesn't need any real child - READ WELL, by using XC_Engine - actually my Titans are dropping rotating boulders ON-Line not the same borked sh!te as in 2000-2015 - also XCGE does the job - fascinating, these are not NEWs are done for a while already - yeah, I wrote new Titan things loaded by XCGE properly;
- Those null old projectiles can be brought to a never lived life by rewriting them and Conforming packages UnrealI UnrealShare and some stuff will go suddenly operational based on default replication. Yeah, I have done fixes to default ScriptedPawn with no mismatch and nothing rammed each small change which I did was checked at least 3 times. As a matter of fact, Schwartz knows some of these things because I send him some stuff and XC MonsterHunt is operational after all...

That's why I'm asking for tweaks and those "hard-coded" craps will not stop me to do run time changes with no issues because I have a very simple math: XCGE + ConformingPackages = ProperGame. No child classes are required, no map broken - those are OLD times which I forgot - I'm no longer using my MonsterReplacer.

The problem on discussion is exactly those simulated things which are not needed. Actor has a default replication and all authoritative stuff has to be done where it has to - Server, Epic was busy with simulations even where are not needed at all (some adjustaim craps crashing) and no simulations when it was a need (Boulder's PostBeginPlay). These simulation issues are subject for XCGE, the rest of non simulated authoritative borks are part of new packages - sanity checkers and correct values for ONLY Their Current Variables (speed, damage, etc.), so to speak you can do your own updates because Epic will never do that anyway. These are already changed and server is running stable a lot of time. As you see I'm in 21th century without wasting time with writing child classes, replacements, and pain with "Hard-Coded" functions. The most of these are "hard-coded" for other dudes not exactly for me :| .
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Mesh thoughts

Post by nogardilaref »

I completely forgot that you use XC_Engine for your stuff. In that case, there are plenty of fixes which are trivial to do, such as the fire offset ones.
Just replace the function through XC and you're done (theoretically, never used it myself, but I have read a bit about it).

Yes, PrePivot isn't used nearly anywhere in the game, but fortunately it works very well for what it is, unlike most unused things, which either do not work or are not implemented at all.
But it's not all rainbows and sunshine with PrePivot, it has problems as well depending on what you intend to do with it. For instance, for rendering purposes, the engine still treats the mesh location as being the same as the actor location, and this has implications on lighting and occlusion: if you give it a big enough PrePivot, and the actor is in one area with a lighting color, and the mesh is being rendered with this offset elsewhere, the lighting applied is still from where the actor actually is. The same for occlusion, if you completely turn around having the actor location in your back and the mesh rendered in front of you, it will disappear as well.

So, for "fixing" things, it must be a relatively small PrePivot change and not a big one. It works for the moon since it was offset to begin with, and for the pupae and pawns since the difference is actually minimal.

On the other hand, its shortcomings can actually be used to our advantage for other things. For instance, you can eliminate the current mesh occlusion problems, you can have a big mesh render completely regardless of the angle if in each tick you put the location of the actor in front of the local player, but the PrePivot calculated in such a way that it still appears stopped in the same place. This should be handled with care of course, and made sure that at a certain distance it stopped doing so to not render every single mesh in the entire level.
Another would be for effects: it would be possible to have colored meshes with a bit of imagination. :mrgreen:


Advancing from here, concerning the default packages and how Epic did things, it's indeed a fact that things do not work as good as they could have been, and it's indeed down to us to fix them up for a better experience.
This also means however that there's a lot of stuff they messed up of course, understandably so (as I have pointed out before), but still... and this includes the immense amount of stuff they have to process and replicate to the client, from the start to the ongoing game (god classes, ugghhh :omfg: ).
So, if things are getting fixed in some way, replication must be taken under special consideration as well, and optimized if possible.


As for the conformity of packages, I guess that what you did was to modify the existing packages but keep the same GUID to avoid mismatches?
Either way, it might work for your servers and all, but that's not something that legally you can actually do, and might actually cause problems on the long run.

First off, you cannot distribute it. If Epic finds out, they might still be nice about it and just send you a C&D letter and that's the end of it.
Plus, they're not letting anyone doing it either (on this specific subject they are actually being assholes). The only way this would work if there was a person or a group of people with Epic's blessing to patch the game, but do it properly (packages and natives alike), and the only guy close to being able to do that is at OldUnreal patching Unreal, and even he couldn't get a straight answer from them.

And there is also a problem of potentially breaking the game when the server packages start to deviate too much from the client ones. You say that you're doing it with care, and I actually trust you that you're doing so indeed, but the moment you do it, everyone will want a piece and contribute on their own, and then clueless server owners will incidentally starting to spread broken packages (as history has shown up until now).

So package conformity is something that, while it might work well for you and for those you privately distribute these to, it's not going to scale up well in the end.
There are far better chances in remaking a lot of this stuff in Unreal itself, or letting XC getting further ahead and giving us the ability to replace entire classes, or even entire packages by our own, which technically wouldn't be illegal and would not have these problems.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Mesh thoughts

Post by sektor2111 »

Conforming details are let's say a bit... not for public sharing because in 2 seconds some plonker player will load them as they did with other server updates messing up in servers with the same tweaking but different results. Else conforming is handy for ANY user and private things from servers are sitting happily there and no one is getting hurt.

Point 2 very important. As Engine 436 can join to 451 server any other such instance just works. But... at doing a server update is forbidden to implement new vars. Any fix should never include any new boolean or a new vector or anything else - trust me I did tests and ugly things occurs.
Original client must deal only with what knows else WC things happens - I know what I'm saying here. If new vars and reworked classes are needed then only XC might be helpful because we can replace execution not the entire bad class and dynamically mapping new packages on Levels needing them without making them permanent NsUTw3 un-shared yet by me is a mutator that needs only quoted because it is adding itself in packages and it does some different executions. Titan doesn't use original "SpawnRock" - will use another "Tw_SpawnRock" + new classes "packaged" properly. Issues are... NONE XCGE does the voodoo magic here.

Another benefits: Majority of "pawns" done (monsters mainly) doesn't include any MeleeDamageTarget (as a sample) fixed. You will not need to replace 1000 types with a nasty mutator, you can simply have "original" written properly - good bye accessed nones and then all child classes will work like a charm having a good parent on the back and excepting a million of lines written - fast and smoother action.

The mesh attack for MH purposes which I did has for Slith a simple fix but I was interested to do it even in other format. For now I copied something from Krall - Stop and fire, step, stop and fire - just adding "DesiredSpeed = 0" - one single line was enough to deal more properly - but this way in combat is not that super duper nice (they are an easy target when are stopping). I'll check then projectiles for not taking class in account, but INSTIGATOR - no new var is required just wrapping everything well.
Bad projectiles - the little good thing is they were having ROLE_DumbProxy. In conclusion if they are moved in server client can figure them. If they hit target doing an unknown damage for client, server will say "YOU are hurt" because damage is an authoritative thing so again client is not ruined with nothing just looking suddenly at projectiles which have never worked before.

This is one way, another admin might have another way. By releasing a ton of packages everything will go down-hill no one will know what is here and there and... I repeat, new things might not work together. Public Packages must stay clean - STOCK UNTOUCHED - private things are just private and by sharing them game do takes a bad damage.

Now my stupidity - these operations I'm sure right now that they were already executed by some admins, because whatever known exploits did no damage in those servers - so we have already "packages" but are PRIVATE - for years - Congratulations for those admins doing quality servers.

As for that UT V3 shared and delivering the same ID for a half of planet I did not see measures - so it's time to fix our servers with NO files released, but snippet type codes are helpful for everyone doing this task.

Edit: Things which I'm doubt to fix are Renders - player is just player, right now I have a small problem with a dynamic corona which... is part of another story in the right time and right topic. Probably belongs to me only but I will check it on other machine - it's a completely player side stuff but demanded by server.
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Mesh thoughts

Post by nogardilaref »

Well, if you build auxiliary packages in some way, you can effectively create new client vars, although there aren't many things they would be actually useful for in this context though.
But yeah, still, conformity packages are something to distribute privately at most, which means that even by fixing them you're still not fixing the game as a whole, we will need a better solution.

Some of it might indeed pass by XC_Engine and any derivations of it, although things seem to have been slowing down on Higor's side for the time being (I might be mistaken though), so it all depends on what is put out there in the future.

Renders are actually quite easy in comparison, since most of the things you can fix and implement anew are at the actual driver itself, so you can simply build a new one and have the player select it.
But then you need a fair amount of knowledge in either OpenGL, Direct3D or even something else (like Vulkan) along on how things are represented by the engine itself, in order to build something solid.
However things like dynamic coronas are actually a fairly easy thing to do, you don't really need a new render for it, UScript is enough to build a whole new system, and a better one than the current one.
Post Reply