Typ statt Integer verwenden.... wie?

Bryan Fury

Hallo Leute,
vorab muss ich erstmal sagen, dass ich von C# in etwa so viel verstehe wie die Kuh vom melken. Ich bin lediglich GM auf einem Freeshard und normaler Weise verlustigt sich unser Developer mit so etwas, aber der is grad im Skiurlaub. Ich versuche jetzt einmal kurz in Laiensprache das Problem zu erklären:
Das folgende Script erzeugt ein Item, welches man im Spiel aufrufen kann:

using System;

namespace Server.Items
{
	public class DecRock : Item
	{
                public override TimeSpan DecayTime { get { return TimeSpan.FromMinutes( 1.0 ); } }

		[Constructable]
		public DecRock() : base( 0x1773 )
		{
		        Weight = 1.0; 
		        Name = "melted wall remains";
                        Hue = 1161;
			Movable = true;
                        LootType = LootType.Regular; 
		}

		public DecRock( Serial serial ) : base( serial )
		{
		}

		public override void Serialize( GenericWriter writer )
		{
			base.Serialize( writer );
			writer.Write( (int) 0 );
		}

		public override void Deserialize( GenericReader reader )
		{
			base.Deserialize( reader );
			int version = reader.ReadInt();
		}
	}
}

Das einzig Interessante für mein Problem im obigen Script ist, dass es ein Item erzeugt welches auf den Namen "DecRock" hört und die ItemID "6003" hat. So weit so gut, im Spiel kann ich das Item auch probemlos mit unserem Konsolenbefehl [add DecRock hinzufügen. Jetzt gibt es ein Script, welches Items anhand ihrer ItemID spawnt. Siehe Codeschnipsel:

public class DesCityWallSouth : DamageableItem
	{
		[Constructable]
		public DesCityWallSouth( int, int, class )
			: base( 641, 631, 6003 ) 
                // 6003 = ItemID vom DecRock, 641 & 631 sind ItemIDs von anderen Items
		{

Nun kommt aber der besondere Fall das ich das 2te Script dahingehend abändern muss, dass es das Item nicht per ItemID sondern über den Typ implementiert. Ändere ich den Code allerdings um in:

public class DesCityWallSouth : DamageableItem
	{
		[Constructable]
		public DesCityWallSouth( int, int, class )
			: base( 641, 631, DecRock() )
		{

dann geht garnix mehr. Ich muss der Funktion also quasi sagen, dass nur an den beiden ersten Stellen eine integer eingelesen wird, das aber an der dritten Stelle jetzt der Typ benutzt wird. Ich hab aber nicht die geringste Ahnung wie???? Bitte helft mir, ich werd hier noch wahnsinnig.

Firefighter

Naja so richtig Schlau werd ich aus deinem Code und deinem Problem nich wirklich aber vielleicht suchst du ja das hier:

public class DesCityWallSouth : DamageableItem
    {
        [Constructable]
        public DesCityWallSouth( int, int, class )
            : base( 641, 631, typeof(DecRock) )
        {

Unix-Tom

DecRock() ist eine Klasse

Es wird aber ein INT erwartet.
DecRock() gibt aber kein INT zurück.

Bryan Fury

Ich hab aber eben mal mit unserem Developer telefoniert und der meinte der Aufwand sei gigantisch, da sich der Murks nicht auf die geposteten Zeilen des zweiten Skripts allein beschränkt, sondern sich auf mehrere weitere Skripte ausdehnt. Ich werd also warten bis der Sack aus dem Urlaub zurück ist, sonst müsste ich hier etliche Skripte hochladen und die durchzusehn kann ich niemandem zumuten. Ganz davon abgesehn, das das ohne runuo-server auch noch eine brutale Trockenübung wäre. Dennoch vielen Dank für die gezeigte Hilfsbereitschaft.

Falls es jemanden aus reiner Neugierde interessiert wie das Problem genauer gelagert war dann versuch ich den Murks mal näher zu erklären. Sagen wir mal Du hast ein Item (In unserem Fall einen Stein). Dieser hat verschiedene Eigenschaften und eine bestimmte Optik. Die Optik wäre noch recht egal aber mit den Eigenschaften des Steins kann man nicht viel anfangen, deshalb muss ein neuer Stein her, der aber wie der alte aussieht, oder zumindest nur mit einer anderen Farbe versehen. So einen "neuen" Stein kann mann ganz einfach in einem Miniscript erzeugen (siehe das erste von mir gespostete Script).
Das neue Item lässt sich danach auch über den gewählten Namen (in unserem Fall DecRock) mit dem Konsolenbefehl [add des Gameservers prima ins Spiel integrieren. Schaut man sich mit dem Konsolenbefehl [probs beide Items an sieht man schön die Unterschieder der beiden Items. Soweit wäre alles in Butter. Will man jedoch so ein Item per script einbinden geht das nur über den Namen des Items und nicht über die ID, weil die bei beiden Steinen gleich ist (die ID referenziert immer auf die verwendete Grafik). siehe:
http://www.pictureupload.de/originals/pictures/020210192937_WallRemains.jpg
Ich wollte nun den NEUEN Stein in ein bestehendes Skript integrieren, das jedoch nur mit den ItemID Nummern arbeitet.
Wie gesagt vielen Dank für die gezeigte Hilfsbereitschaft, aber das ganze Projekt schieb ich auf bis unser Dev wieder da ist.

hustbaer

Naja der Murks ist, dass es überhaupt Items mit gleicher ItemID und unterschiedlichen Eigenschaften gibt. Behaupte ich mal.

Athar

hustbaer schrieb:

Naja der Murks ist, dass es überhaupt Items mit gleicher ItemID und unterschiedlichen Eigenschaften gibt. Behaupte ich mal.

Naja, es kann für einige Eigenschaften Sinn machen, diese nicht an die ItemID zu koppeln. Tausendmal denselben Gegenstand mit unterschiedlichen Farbtönen zu erstellen macht nicht so viel Sinn.
Man darf dann aber keine Funktionen erstellen, die eigentlich ein Item brauchen, aber nur eine ItemID als Parameter haben.

mogel

Bryan Fury schrieb:

Ich hab aber eben mal mit unserem Developer telefoniert und der meinte der Aufwand sei gigantisch,

Euer Developer hat keine Ahnung ... schon zu C Zeiten wurden ID's generell mit #define bzw. enum gemacht

zu C# Zeiten kann man das ganze noch viel schöner erledigen - OOP machts möglich

public class GameObject { }
public class Item : GameObject { }
public class Stone : Item { }
public class StoneGray : Stone { /* graues Aussehen festlegen */ }
public class StoneRed : Stone { /* rotes Aussehen festlegen */ }

wenn Euer Developer es richtig designt hätte, so würde er nur das GameObject anfassen und das GameObject würde sich selber um seine Darstellung kümmern ... unterm Strich wäre ein neuer Stein in 30 Minuten erstellt

hand, mogel

PS: Signatur beachten - ich weis zur Abwechslung mal wovon ich rede

endline

mogel schrieb:

Bryan Fury schrieb:

Ich hab aber eben mal mit unserem Developer telefoniert und der meinte der Aufwand sei gigantisch,

Euer Developer hat keine Ahnung ... schon zu C Zeiten wurden ID's generell mit #define bzw. enum gemacht

zu C# Zeiten kann man das ganze noch viel schöner erledigen - OOP machts möglich
public class GameObject { }
public class Item : GameObject { }
public class Stone : Item { }
public class StoneGray : Stone { /* graues Aussehen festlegen */ }
public class StoneRed : Stone { /* rotes Aussehen festlegen */ }
wenn Euer Developer es richtig designt hätte, so würde er nur das GameObject anfassen und das GameObject würde sich selber um seine Darstellung kümmern ... unterm Strich wäre ein neuer Stein in 30 Minuten erstellt

hand, mogel

PS: Signatur beachten - ich weis zur Abwechslung mal wovon ich rede

Ach Unsinn. Der Stein bleibt derselbe, die Eigenschaft 'Farbe' aendert sich doch nur. Und als solche muss man die Eigenschaft auch einsetzen.

public class Stone : Item 
{ 
    public Stone(Color c) { ...}
}

Dann dauert es auch keine 30 Minuten, einen Stein mit einer neuen Farbe zu erstellen.

Siraja

Es kommt darauf an wie viele verschiedene Farben bei 3 Farben die alle regelmäßig benutzt werden kann es schon Sinn machen auch 3 verschiedene Objekte zu erzeugen

Bryan Fury

mogel schrieb:

Bryan Fury schrieb:

Ich hab aber eben mal mit unserem Developer telefoniert und der meinte der Aufwand sei gigantisch,

Euer Developer hat keine Ahnung ... schon zu C Zeiten wurden ID's generell mit #define bzw. enum gemacht

zu C# Zeiten kann man das ganze noch viel schöner erledigen - OOP machts möglich
public class GameObject { }
public class Item : GameObject { }
public class Stone : Item { }
public class StoneGray : Stone { /* graues Aussehen festlegen */ }
public class StoneRed : Stone { /* rotes Aussehen festlegen */ }
wenn Euer Developer es richtig designt hätte, so würde er nur das GameObject anfassen und das GameObject würde sich selber um seine Darstellung kümmern ... unterm Strich wäre ein neuer Stein in 30 Minuten erstellt

hand, mogel

PS: Signatur beachten - ich weis zur Abwechslung mal wovon ich rede

Das Problem ist, das der RunUO Emulator schon mit ein Paar tausend vordefinierten Items daherkommt und ich nur versuche eines davon zu verändern. Unser Dev hat die Items nicht designed, die waren schon vorher da.

hustbaer

Athar schrieb:

hustbaer schrieb:

Naja der Murks ist, dass es überhaupt Items mit gleicher ItemID und unterschiedlichen Eigenschaften gibt. Behaupte ich mal.

Naja, es kann für einige Eigenschaften Sinn machen, diese nicht an die ItemID zu koppeln. Tausendmal denselben Gegenstand mit unterschiedlichen Farbtönen zu erstellen macht nicht so viel Sinn.
Man darf dann aber keine Funktionen erstellen, die eigentlich ein Item brauchen, aber nur eine ItemID als Parameter haben.

Ich meine bloss: wenn man schon sowas wie eine ItemID hat, dann macht es wohl Sinn, diese 1:1 auf Klassen zu mappen.

Wenn man dann irgendwas in verschiedenen Farben haben will, dann bekommt die Klasse halt zusätzlich Parameter oder so.
Und wenn das die Game-Enginge nicht kann, dann würde ich wirklich eher alles über die ItemID machen, anstatt hier zweigleisig Name vs. ItemID zu fahren.