Some questions about inventory items (pickups)

Discussions about Coding and Scripting
nullbyte
Novice
Posts: 27
Joined: Sat Sep 03, 2016 3:40 am

Some questions about inventory items (pickups)

Post by nullbyte »

Hey all, I am trying to create a simple pickup actor which makes the player get smaller when they pick it up. When the player gets killed, I want to return the player to their regular size.

I have some problems:

1. I can't see the pickup when I summon it online (it is running as a ServerActor) even though it uses standard Botpack mesh. When I add it to ServerPackages also, I can see it, but I want to run it only as a ServerActor.

2. I don't know how to get the pickup's owner - Pawn(Owner) - inside the code.

3. I can't find a function which runs when the player dies (or their inventory is cleared). I tried using the "Destroyed()" event but this just doesn't work.

Here is my code:

Code: Select all

class ShrinkVial extends Pickup;

auto state Pickup {
	function Touch(actor Other) {
		local Pawn P;

		if (ValidTouch(Other)) {
			P = Pawn(Other);
			P.DrawScale = 0.3;
			P.ClientMessage("You are small now"); // THIS WORKS!
		}
	}
}

// THIS DOES NOT WORK WHEN THE PLAYER DIES
event Destroyed() {
	// How to get player owner inside this function?
	// Owner.DrawScale = 1;

	// This doesn't appear in the log
	Log("Player should be back to normal size now");
}

defaultproperties {
	RemoteRole=ROLE_SimulatedProxy
	PickupViewMesh=LodMesh'Botpack.Vial'
	PickupSound=Sound'Botpack.Pickups.UTHealth'
	Mesh=LodMesh'Botpack.Vial'
}
Thank you!
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Some questions about inventory items (pickups)

Post by nogardilaref »

nullbyte wrote: 1. I can't see the pickup when I summon it online (it is running as a ServerActor) even though it uses standard Botpack mesh. When I add it to ServerPackages also, I can see it, but I want to run it only as a ServerActor.
Any "resource" you want the client to see, must be sent to the client or it won't see it.
And everything in a package is a "resource", including classes themselves.
The moment you create a new class, and you want the client to be able to see that class, you really have to send the package, there's no way around it (it would be impossible otherwise).
nullbyte wrote: 2. I don't know how to get the pickup's owner - Pawn(Owner) - inside the code.
To get it, Pawn(Owner) is actually the way to do it, as you can see it used that way throughout the Inventory class source: http://uncodex.ut-files.com/UT/v436/Sou ... ntory.html
nullbyte wrote: 3. I can't find a function which runs when the player dies (or their inventory is cleared). I tried using the "Destroyed()" event but this just doesn't work.
The Destroyed event is indeed the one you want to use, and the owner is still assigned when it happens.
Now, if it's not being called at all, this means one of 3 things:
1 - The actor is not actually being destroyed at all.
2 - The actor is being destroyed, but it's in a state where the Destroyed event is implemented while you're overriding one from another state (even global).
3 - The event is disabled.

In this case, it's the first case, it's not being destroyed at all, even because it's not even adding it to the player's inventory list at all, given that you're not taking care of actually calling up the Super version of the functions you're overriding, thus breaking the pickup completely.

I would suggest you to take a look at the actual source of inventory and pickup for reference:
http://uncodex.ut-files.com/UT/v436/Sou ... ntory.html
http://uncodex.ut-files.com/UT/v436/Sou ... ickup.html
and you will see you're disabling functionality by not calling "Super.Destroyed()" and "Super.Touch(Other)".

Even so however, overriding the Touch function in the Pickup state is not the correct thing to do at all.
As you will notice after checking the code, the pickup class has an empty function called PickupFunction, and empty functions are functions which do not run any code by default since the implementation should actually be done by a subclass, such as yours.

In other words, to avoid breaking stuff, call the Super version of the functions you override (even if at the end of the function), and use PickupFunction instead of Touch.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Some questions about inventory items (pickups)

Post by sektor2111 »

Other notes:
- shrinking player method is borked there. There is needed collision cylinder as well to be in account;
- by resizing player perhaps some moves are screwed up;
- this shrink looks like a CHEAT - owner is harder to hit;
- I think I spoke somewhere about serverpackages VS serveractor.
viewtopic.php?f=15&t=12187 - it is YOUR TOPIC.
- such a player modifier doesn't means that you have to reinvent the wheel. You need to work SIMPLE. In term "simple", I mean LOOK at ScubaGear or at Flashlight - they turn player to normal when charge is exhausted - of course their code is not perfect but it can be used as a base anytime. I thought that you were checking those "mods with public source-code" which you have asked for or UT resources themselves - if NOT, is your loss.
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Some questions about inventory items (pickups)

Post by nogardilaref »

sektor2111 wrote: - shrinking player method is borked there. There is needed collision cylinder as well to be in account;
If I recall correctly, that's actually not the case when dealing with pawns.
Whenever you modify the drawscale of a pawn, its collision adjusts accordingly natively. Trying to recalculate the collision is actually what you should not do in this case.
sektor2111 wrote: - by resizing player perhaps some moves are screwed up;
- this shrink looks like a CHEAT - owner is harder to hit;
The U4E mod has a shrinking gun, which perhaps he can check to see if they accounted for something not obvious at first.
Siege also had a shrinking pickup, and while it made players much harder to hit, it had a fairly short duration and it could be used to get into small spaces which would otherwise not be possible, and it was a rather expensive build. It was removed later on though since players complained a lot about it.
User avatar
OjitroC
Godlike
Posts: 3605
Joined: Sat Sep 12, 2015 8:46 pm

Re: Some questions about inventory items (pickups)

Post by OjitroC »

sektor2111 wrote:- this shrink looks like a CHEAT - owner is harder to hit;
Surely it is no more of a cheat than any of the Relics are? Every player has a chance to pick it up in the course of the game. It could be quite interesting but it might have disadvantages such as limited step and jump height (don't know about that)?
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Some questions about inventory items (pickups)

Post by sektor2111 »

nogardilaref wrote: Whenever you modify the drawscale of a pawn, its collision adjusts accordingly natively. Trying to recalculate the collision is actually what you should not do in this case.
MORE THAN FALSE :loool:
Pawn is adjusting collision ONLY ONCE in PreBeginPlay - if DrawScale is modified later it won't suffer any collision modification.
I have coded a lot of MH sh!t so you cannot tell me what a Pawn does, even if it's in human format.
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Some questions about inventory items (pickups)

Post by nogardilaref »

sektor2111 wrote:
nogardilaref wrote: Whenever you modify the drawscale of a pawn, its collision adjusts accordingly natively. Trying to recalculate the collision is actually what you should not do in this case.
MORE THAN FALSE :loool:
Pawn is adjusting collision ONLY ONCE in PreBeginPlay - if DrawScale is modified later it won't suffer any collision modification.
Just went to the source to check it, and you're right:

Code: Select all

event PreBeginPlay()
{
    ...

    if ( DrawScale != Default.Drawscale )
    {
        SetCollisionSize(CollisionRadius*DrawScale/Default.DrawScale, CollisionHeight*DrawScale/Default.DrawScale);
        Health = Health * DrawScale/Default.DrawScale;
    }

    ...

}
But I wasn't completely off though, unlike you're implying. A pawn does change its collision depending on its drawscale, it's the "when" and "how" parts I was mistaken about.
sektor2111 wrote: I have coded a lot of MH sh!t so you cannot tell me what a Pawn does, even if it's in human format.
Hold on there.
I cannot really say if you're joking or not, but if you're not, let me say that whatever you think you know, there's always someone else who knows something you do not, and this applies to everyone without exception.

In this specific case, I started with "if I recall correctly" (which you conveniently left out when quoting me), meaning that I was replying out of the top of my head without confirming, and it happens it's been several years since I last looked into Pawn code, so things might indeed be a bit fuzzy in my head atm.
Even for my initial reply in this very topic I had to recheck the source to see what he was doing wrong and what he needed to do instead.

But who knows, given enough time to recover the knowledge I had before, I might actually ending up having one or another thing to teach you, even about Pawns, just like you might have one or another thing to teach me. :wink:
That's one of the goals of a community after all, so there's no need for such an elitist attitude. :tu:
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Some questions about inventory items (pickups)

Post by sektor2111 »

nogardilaref wrote:so there's no need for such an elitist attitude. :tu:
Nope, it's not that, it's about posting valid information otherwise some people are taking it in a wrong way, as for the rest, I'm curious about things as well... that's why I read the forum.
nullbyte
Novice
Posts: 27
Joined: Sat Sep 03, 2016 3:40 am

Re: Some questions about inventory items (pickups)

Post by nullbyte »

nogardilaref wrote:The moment you create a new class, and you want the client to be able to see that class, you really have to send the package, there's no way around it (it would be impossible otherwise).
OK, so I didn't understand this correctly. I thought that as long as I used a base mesh or texture which already exists on the client machine that the player wouldn't need to receive any new packages. I thought it was only if you were using brand new resources in your class that the player needed to receive them?

And does this rule only apply to the things that players can *see*, like meshes etc., or does it apply to other things within the class code as well? What I mean is... if I run my code as a ServerActor (with no ServerPackage lines), then my code still works and still does everything I want it to do on the client (i.e. it shrinks the player). All that's missing is that I can't see the object.

Also, I'm sure I've seen people discussing mods which they've made specially to run on the server-side only, so that no packages have to be sent to the clients. So I assume it's possible to run mods entirely from the server, but only ones which don't require the client to see objects?
nogardilaref wrote:To get it, Pawn(Owner) is actually the way to do it, as you can see it used that way throughout the Inventory class source: http://uncodex.ut-files.com/UT/v436/Sou ... ntory.html
Thank you. I did look through all the parent classes looking for a place where "Owner" is instantiated, but I couldn't find it. Is it actually defined in a class somewhere or is it somewhere hidden inside the engine code? The fact that the engine code is not open source makes things very confusing sometimes.

I'm used to object oriented code like in C# or PHP where global variables simply wouldn't carry over into classes or subclasses directly. So instead of just typing "Pawn(Owner)" I would be more used to seeing something like "(Pawn) $this->getOwner()".
nogardilaref wrote:In this case, it's the first case, it's not being destroyed at all, even because it's not even adding it to the player's inventory list at all, given that you're not taking care of actually calling up the Super version of the functions you're overriding, thus breaking the pickup completely.
Yes this was correct, and now it works, cheers.
nogardilaref wrote:Even so however, overriding the Touch function in the Pickup state is not the correct thing to do at all.
As you will notice after checking the code, the pickup class has an empty function called PickupFunction, and empty functions are functions which do not run any code by default since the implementation should actually be done by a subclass, such as yours.
Thanks, PickupFunction works nicely. I based my code on another pickup class like JumpBoots or HealthVial (I don't remember which) and that's where I got the idea to use the Touch function. When would you recommend using the Touch event rather than the PickupFunction, then?
sektor2111 wrote:Other notes:
- shrinking player method is borked there. There is needed collision cylinder as well to be in account;
- by resizing player perhaps some moves are screwed up;
- this shrink looks like a CHEAT - owner is harder to hit;
- I think I spoke somewhere about serverpackages VS serveractor.
viewtopic.php?f=15&t=12187 - it is YOUR TOPIC.
- such a player modifier doesn't means that you have to reinvent the wheel. You need to work SIMPLE. In term "simple", I mean LOOK at ScubaGear or at Flashlight - they turn player to normal when charge is exhausted - of course their code is not perfect but it can be used as a base anytime. I thought that you were checking those "mods with public source-code" which you have asked for or UT resources themselves - if NOT, is your loss.
- Yes collisionheight is needed. This simple code was just to get me started.

- It's definitely not a cheat. This is for some new BT maps I am making with a friend. I'm worried if such cheats are so easy to make however!

- The ServerActor vs ServerPackage thread was helpful, yes, however obviously I am still not fully understanding why you can't use a ServerActor with resources like Botpack meshes which already exist on the client.

- Believe me, I looked through many of the engine classes for several hours before posting here. I traced the Destroy() event back to the parent class Actor and thought it should work. My code was almost correct, in fact, except some mistakes and things which are not clear.

It's also difficult because there is obviously no UScript documentation. Usually these "callback functions" or "events" as they would be called in JavaScript would be documented somewhere in a big list. So you would be able to look up "Inventory -> Events" and find "PickupFunction()" listed as an event with a nice helpful description.

Finally as I said above I am more used to mature object-oriented languages so it's difficult to grasp the concept of having to search for random events to hook into with UScript.

If we were developing this mod in a modern language, it might look something like this:

Code: Select all

var shrinkVial = new Pickup({
	"collected" => function(owner) {
		owner.setDrawScale(0.3);
		owner.clientMessage("You are small now");
	},
	"destroyed" => function(owner) {
		owner.setDrawScale(1);
		owner.clientMessage("You are normal sized");
	});

nullbyte
Novice
Posts: 27
Joined: Sat Sep 03, 2016 3:40 am

Re: Some questions about inventory items (pickups)

Post by nullbyte »

Here is the latest code, by the way.

Two things I need to solve now:
1. I want to get rid of the message "Snagged an item" but I assume this is just PickupMessage property
2. The small player is left holding a very large weapon. However using "set SuperShockRifle drawscale 0.3" does not make the held weapon any smaller - it only changes the first-person-view weapon size. I need to find out what class the held weapon is and change its scale also.

Edit: one more question...

3. Do you always need to call the function using "Super.FunctionName()"? For example in my code below, should I be calling Super.PickupFunction(Other) ?

Code: Select all

class ShrinkVial extends Pickup;

function PickupFunction(Pawn Other) {

	if (Pawn(Owner) != None) {
		Pawn(Owner).DrawScale = 0.3;
		Pawn(Owner).CollisionHeight = 8;
		Pawn(Owner).ClientMessage("You are small now");
	}

}

event Destroyed() {

	if (Pawn(Owner) != None) {
		Pawn(Owner).DrawScale = 1;
		Pawn(Owner).CollisionHeight = 22;
		Pawn(Owner).ClientMessage("You are back to normal size now");
	}

	Super.Destroyed();

}

defaultproperties {
	RemoteRole=ROLE_SimulatedProxy
	Mesh=LodMesh'Botpack.Vial'
	PickupViewMesh=LodMesh'Botpack.Vial'
	PickupSound=Sound'Botpack.Pickups.UTHealth'
	bAlwaysRelevant=True
	bNetTemporary=False
	bHidden=False
	bRotatingPickup=True
	RespawnTime=0.100000
}
User avatar
Barbie
Godlike
Posts: 2792
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Some questions about inventory items (pickups)

Post by Barbie »

nullbyte wrote:I thought that as long as I used a base mesh or texture which already exists on the client machine that the player wouldn't need to receive any new packages.
This is true, but you created a new object named "ShrinkVial" that uses resources that are already loaded at client - but the object itself is not know on client. (Hint: resources are only available if they are loaded. Of course they only can be loaded if they exist. So existence of resources only does not mean it can be used.)
nullbyte wrote:if I run my code as a ServerActor (with no ServerPackage lines), then my code still works and still does everything I want it to do on the client (i.e. it shrinks the player).
As far as the code is not declared as "simulated", it is only executed on server. The clients only receives the results, if replicated.[/quote]
nullbyte wrote:Also, I'm sure I've seen people discussing mods which they've made specially to run on the server-side only, so that no packages have to be sent to the clients. So I assume it's possible to run mods entirely from the server, but only ones which don't require the client to see objects?
I often divide things into server side only part and server & client side part. It has the advantage that new versions of server side only parts can be installed without having clients involved. An example of server side only thing is not simulated code; some examples of client side thing are resources like music, sound, simulated code, actors with changed bStatic properties.
nogardilaref wrote:I did look through all the parent classes looking for a place where "Owner" is instantiated, but I couldn't find it.
Have a look in Actor.uc:

Code: Select all

//=============================================================================
// Actor: The base class of all actors.
// This is a built-in Unreal class and it shouldn't be modified.
//=============================================================================
class Actor extends Object
	abstract
	native
	nativereplication;
...

var         const Actor   Owner;         // Owner actor.
nogardilaref wrote:When would you recommend using the Touch event rather than the PickupFunction, then?
When the decision is to make what should happen if an object is touched (toucher may explode, may be given the item, may teleport, the item may disappear, whatever).
nogardilaref wrote:Do you always need to call the function using "Super.FunctionName()"?
Call it if the code there should be executed. Sometimes it must be executed before, sometimes within your code, sometimes after your code is executed - this depends. If you want complete other behaviour, don't call parent's methods.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
nullbyte
Novice
Posts: 27
Joined: Sat Sep 03, 2016 3:40 am

Re: Some questions about inventory items (pickups)

Post by nullbyte »

Excellent, thanks a lot Barbie.

I'll definitely need to read more about replication, because I can't wrap my head around why the client can't see the mesh of the object but can still interact with it.

The way I've been testing this is by entering the server, logging in as admin, and using "summon ShrinkVial.ShrinkVial". That obviously summons the ShrinkVial actor in front of me. When I run it without the ServerPackage line, it's invisible (I don't see the mesh) but I (and other players) can still touch the invisible actor and it still causes us to shrink.

If I understand correctly, the server knows that a ShrinkVial actor has been placed at co-ordinates (X,Y,Z). So, does this mean that the client knows nothing about the actor at all? Is the server simply triggering the event when the client player's location enters the collision radius of the ShrinkVial? Or does the client know that the actor is there at (X,Y,Z) and is sending the server a message saying "Trigger this event please"? And if it is the second case, if the client receives some information about the actor, such as its co-ordinates, why can't it also receive the name of the mesh and attempt to load it?
nogardilaref
Masterful
Posts: 577
Joined: Tue Jun 20, 2017 1:00 pm
Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋

Re: Some questions about inventory items (pickups)

Post by nogardilaref »

In order for the client to know what's happening in the server, the server sends data about some (not all) of its objects to the client (replication), however none of this data is an actual object in itself, the server does not replicate the actual objects over the network, what it replicates instead is the following:
  • values from properties which are marked as being replicable (set in the replication block at the top of the class or natively set as such in the engine), but only when they are changed.
  • function calls (also set in the replication block at the top of the class or natively set as such in the engine).
  • the necessary details to make an object of a specific class to be spawned, referenced or destroyed.
and a few other things depending on whether or not the object should be kept in sync with the server or not (such as specific "network id" of sorts), but that's another subject altogether.

In other words, when an object is spawned in the server and is set to be replicated to the client, what the server does is telling the client "hey, please spawn an object of class X from package Y at this location with this rotation with this owner ...".
However, if the client does not have such a class, since it doesn't even have the package installed where it resides, the client cannot spawn the object the server wants it to spawn.

From there, I don't remember what happens anymore in that case (I think it will either be assigned None in the client or it will fallback to the nearest parent class), but someone else may clarify this better for you.
But, bottom line, the client won't ever be able to spawn a class it does not have.

Also, everything is pretty much a "class" or "object" inside a package in one way or another: textures, sounds, music, meshes, etc..., so when the server says "assign texture X from package Y to actor Z", the server is not actually sending the texture itself, same thing.



Now, how can an object, such as a custom pickup, interact with the player in a way that is visible in the client, without the client having the package the pickup class resides in?

The first thing to understand here is that the server and client are completely independent environments, and they manage their own objects.
They are only synchronized solely through replication of data as I mentioned above, and as shown above it happens pretty much as a "conversation" between the server and the client rather than "transportation" of actual objects over the network, and both the client and server are free to do whatever they see fit with the data they receive afterwards.

This is why we have things like "roles" (ROLE_None, ROLE_DumbProxy, ROLE_SimulatedProxy, ROLE_AutonomousProxy and ROLE_Authority), to describe what the object is in the context of a server or a client, but that's also another subject I won't get to describe in detail here.
Case in point, each one runs its own Tick event (even at different rates as it's often the case), process their own Touch events, process their own physics, etc...

As a consequence, this also means that the player exists as an object (PlayerPawn) in both the client and server, at the same time, but the client still handles its own PlayerPawn independently from the server, and all that connects both is this "network id" I mentioned.
When you press a key to move your player, your intent runs in the client PlayerPawn, and then it replicates this to the server PlayerPawn, but each PlayerPawn will move on its own in each environment, and the server might even send back some movement corrections when you're too astray from where the server thinks you should be, as the server is the authority and is the one to ultimately decide where things are, how they behave and what effects they have on other things including the players themselves.

With that in mind, in the case of a pickup, for example, even if the client is completely unaware of it (by not having the package to begin with), the server itself knows everything about that pickup, including what to do when the player touches it, since the server is where the pickup is loaded in the first place.
So, when the server PlayerPawn touches the pickup, what happens is that the Touch function of that pickup is called, but is called in the server alone.

What happens next however, is that if you affect the PlayerPawn in that function in some way (the one who touched the pickup), such as changing its DrawScale for example, since the DrawScale is a property of the PlayerPawn, which exists in the client and has its own version of a PlayerPawn object and is in sync with the server version of it, then what you see in the end is the replication of this change to the client PlayerPawn, and thus you are simply seeing from the client perspective are the effects of "something" that just happened in the server through the change of a property in an object you have loaded in your side already (the client PlayerPawn).

In other words, the client PlayerPawn never touched the pickup on its side to begin with, since it does not even exist there so it's absolutely clueless on what is going on, the server PlayerPawn did however, and it affected other objects which also already existed and were synchronized in the client.


Perhaps a bit lengthy and confusing, but hopefully this clarifies a bit on how this stuff works. :)
Last edited by nogardilaref on Mon Aug 07, 2017 1:00 pm, edited 2 times in total.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Some questions about inventory items (pickups)

Post by sektor2111 »

Eh...
Simulated or not simulated, if this is part of a "serveractor" client has no clue about it if it not resides as a "ServerPackage". But you might have some exceptions. Have you guessed ?

Code: Select all

ServerActors=BotPack.UT_Eightball
In this case we have a "ServerActor" working in client because of package Botpack mainly automated by game-type - it does spawn at LevelInfo location, if map has that location available in a playable area, it will be even usable being replicated natively.
nullbyte wrote:If we were developing this mod in a modern language, it might look something like this:
UScript is able to create more pain if you don't read about it as simple as it is, UScript is not Java. And you can quit thinking at "consolecommand" if you don't know a real good meaning for that, it's just screwing actor class. Believe or not, even other advanced programmers were messing up things at UScript as basic and raw as it is because UScript is too simple for a complex way of thinking. More practice is required.
Another fact:
Why this ServerActor sudden affinity ? Do you want this protected/unshared ? UT is done for sharing, these are methods, a new item has to exist in client even if have known resources used else it won't be figured by client. I cannot say that you cannot encrypt and setup some conditions but sooner or later it will go disassembled heading to some useless protection.

Hint for hiding/protecting
Your item can spawn a VIAL, known in client but VIAL ruined correctly for not be touched exactly in location of your item. Given that Vial is around, player thinks is picking up the Vial but he will suddenly shrink. Or you can use another sort of "vial-like" shared in ServerPackages and your real item will be ServerActor HIDDEN with no display. Parent ServerActor will spawn a "Fake-VIAL" from Serverpackages which can be even a Keypoint (this is spawning usually with any matter). Client thief will get package from cache and will never know WTF is wrong. Scenario accordingly:
Thief wrote: In that server I was shrinking, now this looks like an empty sh!t with no code. What do I do now ?
:lol2: This might be a method for items that have only a Server-Side job - but you can notice client with a fake actor from ServerPackages.

Can I tell you something ? If you really want, you can make ALL Teleporters Visible not only that "VisibleTeleporter" using above method...
nullbyte
Novice
Posts: 27
Joined: Sat Sep 03, 2016 3:40 am

Re: Some questions about inventory items (pickups)

Post by nullbyte »

@nogardilaref:
So it's like the first way I mentioned:
the server knows that a ShrinkVial actor has been placed at co-ordinates (X,Y,Z). So, does this mean that the client knows nothing about the actor at all? Is the server simply triggering the event when the client player's location enters the collision radius of the ShrinkVial
You mentioned that if the client is asked to spawn a class it does not have, it might fall back to the parent class. Does this mean if I made my ShrinkVial extend a default class like HealthVial, it might spawn a visible HealthVial on the client?

@sektor2111:
The only reason I want no ServerPackage is because I don't like having to download tons of extra packages when joining a server. I did think about spawning a "dummy actor", like HealthVial as you suggested. It's a good idea. In this case I will probably just use a ServerPackage.

Thank you both, I have a much better understanding now.
Post Reply