#there are some changes but it did all

1 messages · Page 1 of 1 (latest)

molten roost
#

because, if so, this does not make sense.

#

public class PathNode

#

note that it does not implement any interfaces and does not derive from anything

#

the tutorial must have something like that

#

and the GridSystem declaration must have some kind of constraint on the generic type

verbal thistle
#

public class GridSystem<TGridObject>
{

private int width;
private int length;
private float height;
private int floor;
private float floorHeight;
private TGridObject[,] gridObjectArray;



public GridSystem(int width, int length, int floor, float floorHeight, Func<GridSystem<TGridObject>, GridPosition, TGridObject> createGridObject)   that still looks the same
#

the gridobject script seems unchanged aswell

molten roost
#

public abstract class GoesOnGrid {
  public GridPosition gridPosition;
}

public class GridSystem<T> where T : GoesOnGrid { }
#

it has to look something like this

#

so that anything you store in the GridSystem is guaranteed to have a gridPosition field

verbal thistle
#

do you mean the part where my gridsystem gets instantiated?

molten roost
#

No, I'm talking about the definition of GridSystem.

#

The point of generics is to let you pick a type to use, rather than being forced to use a single specific type

#

Sometimes, there are no limitations on what type you use

#

List<T> lets you use whatever you want

verbal thistle
#

yeah i get that part of generics, but how its implemented here i really dont get

molten roost
#

However, that means that List can't really do anything with objects of the generic type

#

because they could be literally anything

#

your GridSystem needs to actually do things with its contents

#

notably, it tries to get gridPosition out of the objects

#

if you just define it like this

#
public class GridSystem<T>
#

then you can't do that, because maybe T is an int or something

#

you can't write 3.gridPosition

#

so you get an error

molten roost
#

Whatever T is, it must be compatible with GoesOnGrid

#

that means that if you have an object of type T, you can get gridPosition from it

#

because T has been constrained to be compatible with GoesOnGrid

verbal thistle
molten roost
#
public abstract class GoesOnGrid {
  public GridPosition gridPosition;
}

public class GridObject : GoesOnGrid {
  public int health;
  public string label;
}

public class GridPathfindingInfo : GoesOnGrid {
  public bool passable;
}

public class GridSystem<T> where T : GoesOnGrid { }
#

GridSystem<GridObject> and GridSystem<GridPathfindingInfo> would both be valid

#

and GridSystem would be able to access gridPosition from

#

one of two things is possible:

  • the tutorial never tries to access anything from the things the GridSystem is tracking
  • the tutorial constraints the type of things that GridSystem can track
verbal thistle
#

the gridobject does not hold stats like you typed, it holds the unit that holds the variables + the gridpositions

molten roost
#

sure, i just made some stuff up

verbal thistle
#

guess ill try asking the guy directly what functions exactly the Tgridobjects serve, otherwise ill try without them

molten roost
#

i'm still having a lot of trouble understanding what you are trying to do here

#

let me put it this way: does GridSystem ever need to access any fields or methods on GridObject?

#

I'm pretty sure you were trying to do that in your original question

#

i think most of my issues come from that my old gridobject.gridposition does not work anymore

verbal thistle
#

i use gridobject.gridposition all the time, its for accessing all the x,y,z and floor data thats stored in my gridpositions inside the gridobjects

molten roost
#

but does GridSystem need to do that?

#

does it care about the gridposition field?

verbal thistle
#

yeah, since the grid is created in this script, other scripts access the positions here thorugh functions such as create debugobjects() and getgridposition()

molten roost
verbal thistle
#

are you checking from before my refactor or after?

molten roost
#

I noticed that it has generics in it, though, so I'm not sure that's from before the refactor...

verbal thistle
#

thats from before the refactor, the original code that worked

molten roost
#

ok, so now you are trying to access a member of TGridObject

verbal thistle
#

this is from my current script

molten roost
#

which does not work, because TGridObject could be anything

verbal thistle
#

i noticed that in this refactor, some of the other scripts where still referencing the old gridobject instead of a tgridobject, is the difference that the normal gridobject holds the current data and tgridobject something else?

molten roost
#

TGridObject is just whatever type you choose to use with GridSystem.

#

It has nothing to do with GridObject whatsoever

#

GridSystem should not reference GridObject anywhere if you want to be able to use GridSystem with many different types.

verbal thistle
#

private List<GridSystem<PathNode> < i took this from the pathfinding script. im guessing he's reusing the gridsystem functions( dimensions) here to make a copy of the grid but fill it with pathnodes instead?

#

so aTgridobject could be either a gridobject or a pathnode

molten roost
#

Right.

#

I would rename TGridObject to just T

#

it has no relationship to GridObject

verbal thistle
#

that would clear some confusions yeah, ill try doing that

#

thanks for all the help btw, sorry i cant explain it better

molten roost
#

the idea is to add just enough constraints to do the work you need to

#

and nothing more

#

a too-extreme constraint would be

#
public class GridSystem<T> where T : GridObject
#

that would not allow you to use PathNode

#

a too-loose constraint would be

#
public class GridSystem<T>
#

T is too vague

#
public abstract class OnGrid {
  public GridPosition gridPosition;
}

public class GridSystem<T> where T : OnGrid
#

that's the sweet spot

verbal thistle
#

i guess i would have to add my units aswell to that ongrid class if i understand it correctly?

#

or can different T's take different amount of parameters?

#

@molten roost first time using a thread, i guess it doesnt ping automatically

molten roost
#

OnGrid will define what everything that goes on the grid must provide

#

GridSystem will only be able to see members of OnGrid

#

however, the users of GridSystem will be working with the specific type they want

#

if I have a GridSystem<GridObject>, it will give me GridObject, and I'll have access to everything on GridObject

verbal thistle
#

allright ty

molten roost
#

So, GridSystem will have to stick with the common functionality of all of the types it supports

#

like how List<T> can't really do anything with its items

verbal thistle
#

@molten roost made a screenshot so you could see the error here im trying to acces the gridobjects instead of the T now, but it seems since the [,][] array gets declared as a T i cant acces it here anymore

molten roost
#

Yes, since that array holds T.

#

You can't assume it holds GridObject anymore. It could be anything compatible with the generic type

verbal thistle
#

so for a function that wants to acces the gridobjects. how can i make that distinction?

molten roost
#

does it really need GridObjects

#

or does it just need to know about all of the things this GridSystem is tracking, and their grid positions?

#

it sounds like the latter to me

#

you may also need to change GridDebugObject to reference an OnGrid instead of a GridObject

#

(assuming you called that abstract class OnGrid)

verbal thistle
#

i can convert it to use T instead cause the dimensions are the same but than i cant acces the gridobject.gridpositions anymore

molten roost
#

if T can be anything, then you can't do anything with it

verbal thistle
molten roost
#

without a constraint, the compiler cannot assume anything about T

#

this isn't like c++ templates, where you just kinda substitute stuff in when you use it

#

(meaning that you'd get an error when you try to use a T that doesn't have a gridPosition field)

#

you must constrain T so that it has everything you need

#

does GridDebugObject need anything other than the position of something?

#

you use SetGridObject to tell it about a specific GridObject

#

If it only cares about the position of something, then it can also be changed to use an OnGrid

verbal thistle
#

@molten roost sorry didnt notice your messages here i managed to clear all the errors in the gridsystem. now im left with how all the other scripts are calling it

verbal thistle
#
public abstract class OnGrid
{
    public GridPosition gridPosition;
    public GridObject [,][] gridObjectArray;
    public Unit unit;
   
}
``` ive added gridobject to the abstract class but the errors persist
molten roost
#

I don't understand your design.

#

OnGrid is an abstraction of what used to be GridObject, but now OnGrid contains GridObject?

#

please explain what these things mean

verbal thistle
#

i added it in an attempt to figure out what was causing the errors in the picture i send above

molten roost
#

you can't just add stuff at random..

#

OnGrid only contains things that everything on a grid needs

#

If a field or method isn't needed by GridSystem, then it does not belong on OnGrid

verbal thistle
#

i used to call it with a gridobject, im guessing that should still be the case for all my current scripts, i followed ティナ's advice i just got and my game compiles now

molten roost
#

"used to call it with a gridobject"?

molten roost
#

Only GridSystem should really need to use the OnGrid type.

verbal thistle
#

ティナ told me gridobjects should inherit from ongrid and that fixed the errors i was getting

molten roost
#

each of these various classes derive from OnGrid

verbal thistle
#

@molten roost how can i properly thank you guys? the help is really appreciated a lot and i feel bad i dont always understand the solutions you guys give me

molten roost
#

by making your game :p