Messages

maar dan zijn we nogsteeds niet van die stomme arbitraire ID's af... Verder gaat dat natuurlijk mis bij nieuwe blokken . Nouja we zien wel wat we hieraan gaan doen.

Het was slechts een snel idee, item frames zijn raar wat dat betreft.. het zijn niet helemaal blocks, maar dit lijkt me zaak voor al 1.8 ook daadwerkelijk uit is .

Oh right idd, dan moeten we er maar boeken van maken ofzo

OH OH OH ik ben er een vergeten: .sqlite!

Op dit moment is de lijst gewoon in java gespecificeerd, en wel hier. Het speciale alleen is dat items die geen extra datavalues kunnen hebben dus ook geen nieuwe entry in de intmap krijgen. Per 1.8 of 1.9 ofzo gaan id/datavalue paren er uberhaubt uit en worden ze vervangen door strings die items aangeven. Het is dan ook niet meer zinvol om een reader te bouwen die die items leest vanuit een xml/json/yaml/ini/dat/cfg/python pickle/obj serializable/wathebbenwenogmeer file want als het goed is gaat binnenkort de bukkit Material enum eruit en dan kunnen we eens naar een meer duurzame (en minder zeurbare ) aanpak kijken.

Als je code wijzigingen wil maken, check dan dat je op de datavalue_config branch zit, de andere zijn blijkbaar steenoud .

Nou zie je, soms in deze wereld houden twee zwamkoeien gewoon niet van elkaar, ze willen allebei wel maar de klik is er niet .

TC2 zit een beetje aan de lifesupport, wij (= ik en Edoxile) coden er wat aan als we er zin in hebben. We zijn allebei druk dus kunnen niets beloven, we zullen er (misschien dus ) naar kijken >

Mijn moeder kan niet programmeren, helaas.

En @Ji E, ik zal er eens naar kijken

Even de lastige devver uithangen: ik heb begrepen dat ieder block-ID moet worden toegevoegd aan de sourcecode van TC2. Waarom is dit?

Zo te zien heeft de klasse org.bukkit.Material een lijst met alle materialen die Bukkit kent, is het niet mogelijk om hieruit te halen wat je nodig hebt?

Half, alle blokken gaan er precies op die manier in ja, maar het gaat mis als een blok meerdere varianten (dus data) heeft, daar hebben we nog niet de juiste bukkitcalls voor gevonden.

TC2 lijkt problemen te hebben met de twee nieuwste houtsoorten.
Acacia en dark oak respectievelijk ID's 162 en 162;1.
Wanneer deze door een cart langs kisten worden vervoerd worden ze beiden in de eerste de beste kist gedropt waar item ID 162 of 162;1 op staat.
Ik heb verschillende bordjes gebruikt met verschillenden opmaak en zelf de ignore functie.
Met de ignore functie wordt het gehele ID 162 genegeerd.

Idd, die houtsoort staat nog niet op het tweakcart menu...

Een vraagje: Ik wil in mijn storage een autocrafter voor blocks als diamond enzo zetten, maar ik wil natuurlijk niet dat ie 4 diamond daarin pleurt als ie er maar 4 heeft, en dan die dingen laat verdwijnen. Kan ik met carts zorgen dat de cart alleen 9 diamonds in een kist dropped? Met @ geprobeerd, maar dan pakt ie er ook minder dan 9. Dus eigenlijk, if amount => 9 collect 9, else do nothing.

Dat kan tweakcart idd niet, je kan natuurlijk wat met trapped chests enzo prutsen, wees vooral creatief daarmee

[-]

moet het bordje onder het blok staan of er tegen aan of maakt dat niet uit?

Ik heb zojuist een testje gedaan, op de volgende plekken wordt het bordje gelezen:

-	√	-
√	_	√
√	#	√
-	-	-

_ = rails
# = niet beschikbaar
√ = wordt gelezen
- = wordt niet gelezen


Feature request: ook de onderste rij doorzoeken (of in ieder geval het block onder #), zodat de bordjes wat mooier weggewerkt kunnen worden.

Iets als dit heb ik al meer dan een jaar geleden gepost, over de signs links en rechts boven de rail, met screenshots en alles op github. Maar omdat het op de "verkeerde plek" gepost was is er nooit wat mee gedaan
Verder bedoel ik er niks mee natuurlijk 

En er is een reden dat het niet geimplementeerd is, stel dat iemand zijn storage zo opgebouwt heeft dat links en rechts boven de rail er extra tracks liggen en wij zouden een update uitbrengen dat de bordjes links en rechtsboven opeens ook meegenomen worden dan gaat zijn storage stuk. Weinig zoeklocaties is vervelend om weg te werken, maar veel zoeklocaties betekend dat je geen ultracompacte storages kan maken. Er zijn nu 5 zoeklocaties, dat lijkt me atm genoeg. Het is altijd een trade-off.

[-]

moet het bordje onder het blok staan of er tegen aan of maakt dat niet uit?

Ik heb zojuist een testje gedaan, op de volgende plekken wordt het bordje gelezen:

-	√	-
√	_	√
√	#	√
-	-	-

_ = rails
# = niet beschikbaar
√ = wordt gelezen
- = wordt niet gelezen


Feature request: ook de onderste rij doorzoeken (of in ieder geval het block onder #), zodat de bordjes wat mooier weggewerkt kunnen worden.

Leuk: een blok onder het blok onder de rail wordt ook gezien als goed, dus je moet het gold/iron-blok op een van de volgende plekken plaatsen

-	-	-
-	_	-
-	√	-
-	√	-

[goud]

Dat is correct, daar wordt nog geen rekening mee gehouden... Het probleem is dat al die datavalues (dus bijvoorbeeld voor gekleurde glass panes) handmatig in de broncode gezet moeten worden, dus dat loopt altijd even achter, zullen we binnenkort even fixen



Dan komen we op een veel leuker onderwerp: nieuwe features!

• Speed Control

Het is nu mogelijk een cart een snelheid te geven die deze vast moet houden voor maximaal 16 blokjes, zo kan je ervoor zorgen dat een cart voor 16 blokken niet vertraagd! Hiervoor moet je een blok goud onder de rail plaatsen, en een bordje met een bepaalde syntax.

Op het bordje moet bovenaan "speed control" staan, de regel eronder moet een percentage bevatten, dit percentage geeft aan hoeveel de cart moet versnellen. Optioneel kan je ook aangeven hoeveel blokken de cart de snelheid vast moet houden, bijvoorbeeld "@12"

Voorbeelden:

Code Select Expand


speed control
150%

Versnel 50% en hou die snelheid 16 blocks vast

Code Select Expand


speed control
50%@12

Vertraag 50% en hou die snelheid 12 blocks vast

• Ejector

Soms is het handig een player uit een minecraft te verwijderen. Plaats een iron block onder de rails met een bordje ernaast, syntax volgt.

Code Select Expand


ejector
west

Eject players aan de westzijde van het spoor

• Notice

Met notice kan een berichtje naar een speler gestuurd worden, hier is geen waardeblock voor nodig

Code Select Expand


notice
hoi

stuurt hoi naar degene in de minecart waar overheen gereden wordt

Kan er ook iets komen voor quartz pillars? Gewoon hetzelfde als bij wood?

Is dit mogelijk?

Ja het is mogelijk, maar daar heb ik nou geen tijd voor , het staat nou ergens in mijn geheugen

Bukkit is nog niet geupdate naar 1.7, en veel clientmods ook nog niet