Can I declare a variable of a type that's not in my package?

[PrinceOfFunky]

Can I declare a variable of a type where its class is not inside the same package of the actor declaring the variable?

I've these two packages.classes "Test1.Test" and "Test2.Test".

I tried declaring this variable inside the Test1.Test class:

Code: Select all

local Test2.Test OtherTest; 

But it gives me this error: "Error. Unrecognized type 'Test2'."

[Higor]

No

[JackGriffin]

You should explain it more Higor since this is a linchpin in the structure of OOP. I'll try but you could do a much, much better job for sure.

You are thinking of variables like classes and that's an easy thing to get confused. Iniquitous explained it to me and it made much more sense when he put it like this...

Think of a code class like an individual person. Multiple people (classes) all wear the same shirt and use the same unique language when they belong to the same package. You can take a marker and write on their shirts and these would be the variables and code. They each act according to what is written on their shirts. If two people with different shirts need to talk then some form of communication needs to be established because they can't directly talk without being in the same group. This is replication. Replication can be as simple as a custom mod telling the local computer what changes it makes in a single person game all the way up to a fully fleshed out entire gametype played across a packed server with 16 players.

This is Steve:

Steve is a red shirt and written on his shirt is the code for a

custom sniper rifle that does 150 damage per hit.

During the game there will be this exchange:
GameServer: Yo, Steve! I registered a hit by your player so how much damage do you do?
Steve: 150 across the board
GameServer: Thanks. <speaks to blue player>: You have been damaged beyond your health. You are dead and are now respawning. Please display default heath and weapon loadout.

That's a super simple example and there are hundreds (thousands) of these conversations going on all the time between the code, the engine, and the player(s).

[PrinceOfFunky]

Well, that's a sin :/ Anyway, thank you for the "Iniquitous ft. JackGriffin" explanation

[sektor2111]

And the trivia, probably for you is a S.F.

Many UT classes are based on Accesing already assigned variables from another package. Simply is not a need to declare something twice.
Relevant example ? Sure... ScriptedPawn - many variables from UnrealI are exchanged during a Game with UnrealShare, happens because a few creatures located there are child of ScriptedPawn and that's why they are using properties from an external package, to summarize let's see... GroundSpeed, WaterSpeed, etc. These are used by UnrealI creatures but are resident in ScriptedPawn so they don't need a redefinition.

You can acces some properties using direct calls:

Code: Select all

class 'Test2.Test'.bAboolean = TrueOrFalse; //presuming we don't have a Constant

The second way can be by using GetPropertyText - SetPropertyText
And maybe you wanna know a more powerful way but I'm guessing you should try first to deal with simple UScript things - and I REPEAT: READ MAIN ORIGINAL STUFF. Decompile everything from Editor and check classes - you might learn a lot.

[Higor]

You're seeing things from an incorrect point of view(?)

First things first: this isn't native code, it's a high level code when something called 'dependancy' exists.
Package dependancy in Unreal means that your package requires another package to be loaded, this has implications:
- Your package will fail to load if the other package can't be loaded.
- Your package will fail to load if what your package wants to find isn't on the package it wants to load.
- Servers running your package will automatically send all of the dependancies as well.
- If the dependancy becomes obsolete, your package will become obsolete as well >> version tying, dependancy upgrades, you must upgrade too every single time.

So, here is what you should ask YOURSELF
DO YOU WANT PACKAGE DEPENDANCY OR NOT?

Some points
- Package dependancy will make all code straightforward.
- Non-package dependant code will require a big array of workarounds and redesigns.
Sometimes you gotta see how your code leads you, sometimes you gotta plan a framework before you write your first line and enforce it no matter what.
Knowing what you want to achieve is a huge factor here, so what is it?

[MrLoathsome]

This is all good advice. Read it all twice.

Re: Dependency.

As sector points out, UnrealI has lots of examples of using classes or just even resources (sounds etc.)
that are defined in UnrealShare classes.
This is ok, as you know both packages will always be there.

In any case where I find I am even thinking about such a reference to classes in any non-default
package, it is then time to just include that code in the package I am working on.
Failure to do this can result in all the issues Higor points out, and probably others depending
upon what you are trying to do.

As mentioned, reading and then rereading the default source code will be helpful.
Don't assume the default source code is perfect either. When you start noticing errors in it, then
you are making progress.

[Chris]

The only way you can do it is by having the package preloaded in memory by the time the compilation of your class occurs.
Either by the parsing process of the compilation using #exec obj load file="yourfile"
or by adding it to the editpackages list before your own package.
then you wouldn't access it using Package.Class but only by the classname.
Such as:
MyPack.u
|___ MyBase

class MyClass expands Actor;
#exec obj load file="..\System\MyPack.u"

var MyBase BaseInstance;

P.S
You can only access defaults from classes.
class'MyPack.MyBase'.default.lifespan;
However as I understand it this is not even related to your question.
var MyBase BaseInstance would store a spawned instance of the class MyBase.
var Class<MyBase> MyBaseClass; would store it as a class.

Hope this helps.

Regards, Chris