Pol 98 auf Pol 99 upgraden

Ahoy da mates.

Momentan haben wir einen Linux x64 Pol 98 x86 Server, und würden diesen gerne auf Pol 99 x64 upgraden, was an sich gelungen ist. Doch bekommen wir dort keinen client zum laufen.
In der Console bekommen wir sogar folgende Meldung:
client connected from 192.168.18 (interne ip)
clkient connected (Total: 1)


Jemand eine Idee?

Mitglied-3353 hat geschrieben:Ahoy da mates.

Momentan haben wir einen Linux x64 Pol 98 x86 Server, und würden diesen gerne auf Pol 99 x64 upgraden, was an sich gelungen ist. Doch bekommen wir dort keinen client zum laufen.
In der Console bekommen wir sogar folgende Meldung:
client connected from 192.168.18 (interne ip)
clkient connected (Total: 1)


Jemand eine Idee?

Hallo,

ich kann eventuell ein paar Tipps geben, wenn ihr etwas mehr Info rausrückt ;-)

Also: Ihr habt derzeit auf Linux x64 (Debian?) POL laufen. Der hat ja wohl geklappt, davon gehe ich mal aus.

Bei POL 099 hat sich einiges geändert was clients und Versionen anbelangt. Checkt eventuell mal das ChangeLog des POL Cores. Welchen Client verwendet ihr?
Generell gibt es eine uoclient.cfg, wo der Port und die Encryption eingestellt wird.

Der Port dürfte okay sein, da die Conn erkannt wird. Das Login danach klappt aber nicht, offenbar.

Beachtet dazu:
Der Client muss korrekt eingestellt sein, hängt von der Version ab: UoFeatureEnable ansehen.

Hier einige Sachen aus den core-changes, die eventuell nicht okay sind. Ich kopiere sie hier rein, bitte sucht nach dem Datum im File core-changes.txt:

12-16-2009 Turley:
Added: Encrypted Client support - Tomi
Changed: uoclient.cfg Listener::Encryption and pol.cfg ClientEncryptionVersion now support
ignition = uorice = none, 2.0.0x and due to autocalculation major.minor.build (no patch)
e.g. 7.0.4 for latest client 7.0.4.1
default for both is "none"
Note: Till OSI changes the encryption type pol now supports every encrypted client without
updating the core (last change was 2.0.4)

12-04-2009 Turley:
Removed: deprecated pol.cfg entries "MasterKey1","MasterKey2","ClientVersion","KeyFile" - Tomi

Beachtet dabei, dass einige Einstellung aus pol.cfg in die uoclient.cfg gewandert sind.

12-02-2009 Turley:
Added: 0xF3 packet is send instead of 0x1A for clients >= 7 or UO:SA clients - Tomi
Added: polcfg MaxTileID 0x3FFF / 0x7FFF (default 0x3FFF)
since client 7.0.0.0 item graphic can be definied up to 0x7FFF - Tomi
Added: "SA" for expansion type. This includes sending 0x187DF with packet 0xB9. - Tomi
Added: support of new map TerMur - Tomi
Note: uoconvert param:
realm=termur mapid=5 width=1280 height=4096
uoconvert.cfg new stairs since SA:
0x1de0 0x1de1 0x1de2 0x1de3 0x1de4 0x1de5 0x1de6 0x1de7 0x1de8 0x1de9 0x1dea 0x1deb
Added: Gargoyle support (race = uo:RACE_GARGOYLE)
Note: graphics are:
UOBJ_GARGOYLE_MALE 0x029A
UOBJ_GARGOYLE_FEMALE 0x029B
UOBJ_GARGOYLE_MALE_GHOST 0x02B6
UOBJ_GARGOYLE_FEMALE_GHOST 0x02B7
Added: support of UO:KR/SA char create packet 0x8D
Added: new gargoyle hair & beard 0x4258-0x425F & 0x42AD-0x42B0
Added: UO:KR/SA face support
Added: ssopt.SupportFaces 0/1/2 (default 0)
set it to 1 to support basic faces
set it to 2 to support roleplay faces (sets 0x2000 flag in 0xB9 packet)
Note: Faces are normal items (like hair/beard) with layer 15, objtype 0x3B44-0x3B57
roleplay faces 0x3B4E-0x3B57

Es macht Sinn, die Accounts zu checken, ob die richtige Type (SA, ML,...) für die Client-Version eingestellt ist. Siehe auch gleich unten

08-19-2009 Turley:
Added: r/o member character.uo_expansion_client client sends this flag at packet 0x5D charselect and 0x00 createchar
Note: values are:
FLAG_T2A = 0x00,
FLAG_RENAISSANCE = 0x01,
FLAG_THIRD_DAWN = 0x02,
FLAG_LBR = 0x04,
FLAG_AOS = 0x08,
FLAG_SE = 0x10,
FLAG_SA = 0x20,
FLAG_UO3D = 0x40, // ?
FLAG_RESERVED = 0x80,
FLAG_3DCLIENT = 0x100 // 3d Client


Alle weiteren Einträge im core-changes.txt sollten zumindest kurz gelesen werden, da sich doch einiges geändert hat.

Mit etwas mehr Info (genaues Verhalten, Log-File-Ausgaben, usw.) kann ich eventuell mehr Tipps geben. Ich vermute, dass beim Login was schief geht, weil eine Einstellung nicht stimmt. Eventuell schaut mal im pol.cfg nach und setzt LogLevel=10 und DebugLevel=10. Dann erhält man zwar eine Menge unnützer Ausgaben, aber gerade bei der Umstellung hilft das schon.

Horus

Vorab schonmal vielen Dank für die ganzen Tipps Horus!

Wir haben gerade schnell noch den LogLevel auf 10 gesetzt, und bekommen (nur) folgende Meldung:

Code:

client#1: message 0x80

Mein Kollege glaubt es hängt an einer dieser datein:

UOclient.cfg

Code:

General
{
Strength Strength
Intelligence Intelligence
Dexterity Dexterity

Hits Life
Mana Mana
Stamina Stamina

MaxSkillID 51
}

Protocol Protocol
{
EnableFlowControlPackets 0
}

Listener
{
Port 5003
Encryption 7.0.15.1
AOSResistances 0
}

Accounts.txt

Code:

Account
{
Name admin
Password admin
PasswordHash f6fdffe48c908deb0f4c3bd36c032e72
Enabled 1
Banned 0
DefaultCmdLevel test
UOExpansion SA
CProp LastLogin i62255
CProp job_options a2:i0i0
CProp lastlogon i61650
CProp sell_options a9:i0i0i0i0i0i0i0i0i0
}

Pol.cfg

Code:

#############################################################################
## Basic Configuration
#############################################################################

#
# Port and encryption settings now handled in UOCLIENT.CFG
#
ListenPort=0
ClientEncryptionVersion=none

#
# UoDataFileRoot: where the UO client files are located
#
UoDataFileRoot=C:\MUL

#
# RetainCleartextPasswords: If you select this, the server will save plain passwords
# in the accounts.txt file. If you set it to 0, all will be erased. You can get them back
# by changing this back to 1 and successfully logging into the account (for each account)
#
RetainCleartextPasswords=1

#############################################################################
## Logon and Logoff
#############################################################################

#
# MinCmdlevelToLogin: Only characters with this command level or higher
# log in. (0=player,5=admin)
#
MinCmdlevelToLogin=0

#
# InactivityWarningTimeout: Time in minutes until the user gets a "you are
# about to be disconnected: message
#
InactivityWarningTimeout=330

#
# InactivityDisconnectTimeout: Idle Time in minutes before the user is
# disconnected.
#
InactivityDisconnectTimeout=360

#
# MaximumClients: Sets the total number of clients allowed to connect at
# one time.
MaximumClients=300

#
# CharacterSlots: Sets the maximum number of characters per account.
# Default is 5. Some clients support 6.
#
CharacterSlots=6

#
# MaximumClientsBypassCmdLevel: Sets the character command level that bypasses the
# MaximumClients limiter
#
MaximumClientsBypassCmdLevel=1

#############################################################################
## System Profiling and Performance
#############################################################################

#
# WatchRPM: display the RPM counter to console every minute
#
WatchRpm=1

#
# WatchSysload: display the Sysload counter to console every minute
#
WatchSysload=1

#
# LogSysLoad: log sysload to pol.log every minute
#
LogSysload=1

#
# LogScriptCycles: Write profiling information on scripts to pol.log on exit
#
LogScriptCycles=1

#
# RunawayScriptThreshold: a script executing this many instructions without
# sleeping will be reported as a runaway script
RunawayScriptThreshold=20000

#
# ReportRunToCompletionScripts: Print "run to completion" scripts that are running
#
ReportRunToCompletionScripts=0

#
# ReportCriticalScripts: Print "critical" scripts that are running
#
ReportCriticalScripts=0

#
# MaxCallDepth: Maximum function call depth for scripts
#
MaxCallDepth=100

#############################################################################
## Debugging
#############################################################################
EnableDebugLog=1
DebugLevel=10
LogLevel=10
#
# CacheInteractiveScripts: if 0, always load interactive scripts from disk
# Useful for script development
#
CacheInteractiveScripts=1

#
# EnableAssertions: For Linux build only, enable core assertions
#
EnableAssertions=1

#
# EnableDebugLog: Enable the script debug log (formerly known as pol.lg2)
#
EnableDebugLog=0

#
# DebugPort: TCP/IP port to listen for debugger connections
#
DebugPort=5001

#
# DebugPassword: Password for debugging
# If none is specified, no password is required.
DebugPassword=123456789

#
# DebugLocalOnly: Only allow access from localhost
#
DebugLocalOnly=1

#
# MiniDumpType: type of crash dump created. values: small (default) or
# large.
# Case sensative.
#
MiniDumpType=small

#############################################################################
## Integrated Web Server
#############################################################################

#
# WebServer: in multithread mode only, run the internal web server
# This may be a security risk. It's susceptible to DoS attacks.
# If someone knows a little about TCP/IP, they could cause you
# trouble if it's enabled.
#
WebServer=0

#
# WebServerPort: What TCP/IP port to listen for web requests
#
WebServerPort=5000

#
# WebServerLocalOnly: Only allow access from localhost
#
WebServerLocalOnly=1

#
# WebServerDebug: Print trace information about http requests
#
WebServerDebug=0

#
# WebServerPassword: username/password required for access to the web server.
# if not specified, no password is required.
#
WebServerPassword=

#############################################################################
## System Load and Save
#############################################################################

#
# CheckIntegrity: check for duplicate objects on startup
#
CheckIntegrity=1

#
# IgnoreLoadErrors: force load to continue even if object creations fail
# or containers cannot be found.
#
IgnoreLoadErrors=0

#
# InhibitSaves: Don't ever save world state
#
InhibitSaves=0



#############################################################################
## Features
#############################################################################

#
# RequireSpellbooks: Require spellbooks for casting (in hand or in pack)
#
RequireSpellbooks=1

#
# EnableSecureTrading: if you enable this, see changes.txt regarding an entry
# that MUST be added to config/itemdesc.cfg
#
EnableSecureTrading=1

#############################################################################
## Experimental Options - Modify at your own risk
#############################################################################

#
# ExpLosChecksMap - prevents stuff like arrows from going through the 'black'
# areas in dungeons.
#
ExpLosChecksMap=1


#############################################################################
## Obsolete options - do not modify these
#############################################################################
#
# Keyfile - contains crypto constants for a given client version
#
#Keyfile=crypto/v1_26_1.key

#
# Multithread: use multiple threads to lower CPU usage
# If you are using Linux 2.4.*, set this to 1.
#
Multithread=0

#
# SelectTimeout: I/O sleep time
# Set to 0 for a dedicated server.
# Set to 10 for a non-dedicated server.
# Has no effect in multithread mode
#
SelectTimeout=0

Danke für die Info - folgendes fällt mir dazu ein:

UOClient.cfg - sieht okay aus. Wir verwenden dzt. einen client 5.06a, und clients Version 6.x klappen auch, das ist getestet. Aber soweit ich es beurteilen kann, muesste es auch mit eurem client gehen.

accounts.txt - sieht eigentlich auch normal aus. Trotzdem ein Vorschlag: Versucht es mal mit euren Scripts, aber einem komplett leeren Worldfile, und nur mit einem Account im accounts.txt. Ein leeres Worldfile sollte bei den Scripts dabei sein, wenn ihr die Script-Distro verwendet.

pol.cfg - ist eigentlich auch in Ordnung. Den Pfad zu den MUL-Files könnt ihr lassen, der wird nicht mehr verwendet, die beiden Einträge (ListenPort, ClientEncryptionVersion) habe ich bei uns komplett gelöscht (bzw. auskommentiert). Der Rest sieht gut aus.

Die Log-Meldung 'client message 0x80' zeigt, dass irgendwas mit dem Login nicht klappt, denn 0x80 ist die Anforderung des client zum Einloggen. Wenn es danach nicht weiter geht, haut irgendwas nicht hin. Encryption dürfte aber passen, denn wenn die Encryption nicht klappt, bekommt man eine Meldung 'unbekanntes Paket'.

Ich vermute, dass es an der Einstellung für 'SA' liegt. Habt ihr diesen client auch schon mit POL 098 verwendet? Oder ist der client auch neu? Wenn ja, dann testet bitte mal zuerst mit dem älteren client, da sollte es klappen. Ansonsten bleibt nichts anderes übrig, als die core-changes.txt zu durchsuchen und alle Änderungen bei Packets zu untersuchen, denn wenn es mit 098 und diesem client gelaufen ist, geht es ganz sicher auch mit 099. Dann habt ihr irgendwo ein Problem bei den Einstellungen.

Ich habe noch keine Erfahrungen mit Clients > 6.x. Seid ihr sicher, dass die Client-Version 7.0.15.1 schon SA ist? Laut core-changes.txt (siehe mein Post oben, Eintrag von 12-02-2009 Turley) gibts da offenbar Unterschiede für SA.
Auch solltet ihr mal schauen, ob ihr custom items habt, die im Bereich von 0x0-0x7fff liegen, denn ab SA sind die UO-Items (die dabei sind) nicht mehr auf den Bereich 0-0x3fff beschränkt, sondern gehen eben bis 0x7fff. Dazu kann man eigene Items 'mappen', also sie verschieben, was der core macht, wenn man im itemdesc.cfg den Eintrag 'OldObjtype' nutzt: Man muss dann die alte ID des Items unter OldObjtype angeben und verwendet oben die neue ID. Das sollte auch alle im Spiel befindlichen Sachen mappen. Allerdings löst das nicht das Problem, dass unter Umständen der verbleibende Bereich 0x8000-0xf000 nicht ausreicht, dazu kann der core die Obergrenze von 0xffff höher schieben (siehe core-changes.txt fuer Details). Falls ihr das alles schon unter 098 verwendet habt, wird dieses Problem wohl nicht existieren, wenn ihr aber beides, den client und den core upgedatet habt, dann ist das sicher ein Thema.

Generell wäre es gut, wenn ihr mal möglichst ohne Ballast beginnt: Falls ihr diesen client schon verwendet habt, sollte er auch unter 099 laufen, wenn der client aber neu ist, solltet ihr entweder mit dem alten client und euren Scripts experimentieren oder aber den neuen client und ggf. die Distro-Scripts verwenden, und dann umstellen.

Es gibt ja einige Dinge, die auch Script-Änderungen verursachen werden: ZB. die Spellbooks sind anders, es ist kein Container mehr, der Scrolls enthält, sondern nun ein Sonderitem, wo die eingetragenen Spells markiert sind. Es hat sich richtig viel geändert seit 098 - siehe core-changes.txt. Idealerweise verwendet man für die ersten Tests völlig neue Accounts, ganz neue Chars und ein Worldfile ohne NPCs oder Items.

Ihr könnt auch mal mit dem 'UOExpansion SA' im accounts.txt experimentieren, und dort mal etwas anderes eintragen, zB SE. Idealerweise erstellt ihr ein accounts.txt mit genau einem Account und habt ein Save ohne Chars, NPCs und Items. Dann sieht man gleich, was passiert und erstellte Chars kann man dann vergleichen, usw.

Beachtet auch die Datei 'servers.cfg' im config-Verzeichnis: Wenn man dort einen Fehler hat, kann man auch nicht einloggen:

Code:

GameServer
{
Name Shard-Name
IP --IP--
Port 5003
}
GameServer
{
Name Shard-Name-LAN
IP --lan--
Port 5003
IPMatch 10.0.0.0/255.0.0.0
IPMatch 192.168.0.1/255.255.0.0
IPMatch 127.0.0.1/255.255.0.0
}

Hinweise dazu:
Der erste Eintrag sollte die IP selbst finden, jedoch kann ein Router mit NAT das verhindern. Die Adresse ist dann unklar. In dem Fall trägt man statt '--IP--' die korrekte IP ein. Falls der Server derzeit nicht am Netz hängt, kann man den Eintrag so lassen.
Der zweite Eintrag ist die LAN-Adresse, falls der Server direkt am Internet hängt (Rechenzentrum), ist der Eintrag irrelevant, weil es kein LAN gibt. Trotzdem kann man dort auch statt --lan-- direkt die LAN-IP eintragen.

Was passiert: Es kommt eine conn herein, und im Fall von NAT wird das auf eure LAN-Adresse umgeleitet. Allerdings muss der Server wissen, wo er die Antwort hin senden soll - dazu muss die IP (erster Eintrag) klar sein. Arbeitet ihr nur lokal im LAN, ist der erste Eintrag egal, aber es muss klar sein, dass der 2.Eintrag gilt. Hier kann man Probleme haben, ich bevorzuge bei ersten Tests das direkte Eintragen der korrekten IPs. Wenn der Server startet, sieht man ganz oben sofort nach dem Start auch, welche Interfaces (IPs) aktiviert sind und wo auf Verbindungen geachtet wird.
Bei den Port-Einträgen trage ich immer den korrekten Port ein, auch wenn es angeblich ignoriert wird.
Wenn ich daheim (Server=mein PC) etwas teste, und ein Kollege möchte vom Internet aus einloggen, passiert nämlich genau das, was bei euch passiert: Ich sehe ihn ankommen, aber er taucht nie im Spiel auf. Erst wenn ich die korrekte Internet-IP im ersten Eintrag hinschreibe (und neu starte), kommt das durch. Vorher weiß der Server nicht, wo er Antwort-Pakete hinsenden soll.

Auch die Dateien 'servspecopt.cfg und servspecopt.local.cfg' sind zu beachten. Die Datei mit 'local' ist zum Ändern gedacht, die andere erstellt defaults.

Hier unsere 'servspecopt.local.cfg':

Code:

##
## servspecopt.cfg - Server Specific Options
##
## Options relating to gameplay
##
## NOTE: It is recommended that you copy this file to 'servspecopt.local.cfg'
## and set your settings there; new distributions will not overwrite
## your changes to servspecopt.local.cfg
##

#
# StartingGold - Amount of gold the core gives a character on creation.
# In the distro it is created in the newCharacter package.
#
StartingGold=0


#
# UseTileFlagPrefix - Determines if core adds A/AN as a prefix to item names
# based on their tiles.cfg settings.
#
UseTileFlagPrefix=0


#
# DefaultDoubleclickRange - doubleclick range if DoubleClickRange isn't
# specified for an objtype in itemdesc.cfg
#
DefaultDoubleclickRange=2

#
# DoubleClickWait - Number of seconds that must pass before a player can
# double click an object again.
#
DoubleClickWait=0

#
# DefaultLightLevel - Default light level for regions with no level defined.
#
DefaultLightLevel=5

#
# EventVisibilityCoreChecks - If enabled, the core will not send system events
# to NPCs unless they are visible to the source.
# Visibility is based on:
# Source is logged in
# Source is not hidden / concealed
#
# If disabled, you will do the checks yourself in the scripts.
#
EventVisibilityCoreChecks=1

#
# MovementUsesStamina - stamina cost per movement will be enforced, using
# weight and carrying capacity.
#
MovementUsesStamina=1

#
# AllowSecureTradingWhileInWarMode - 1 or 0, to allow or disallow it.
#
AllowSecureTradingInWarMode=0

# AllowMovingTrade: 0 Disables moving more than 4 tiles away with an open trade window, cancels trading window.
AllowMovingTrade=0

#
# TotalStatsAtCreation - 65 for older clients, 80 for newer.
# Accepts any value you like, but those are the
# important ones. Accepts lists and ranges, for
# instance: 65,80,90-95,100
#
TotalStatsAtCreation=65,80

#
# DecayItems - Determines if the core's decay system is enabled or not.
#
DecayItems=1

#
# DefaultDecayTime - minimum number of minutes before movable items decay (are destroyed)
#
DefaultDecayTime=10

#
# DefaultContainerMaxItems, DefaultContainerMaxWeight
# These values will be used for containers that do not define "MaxItems" and "MaxWeight"
# in their itemdesc.cfg entries.
#
DefaultContainerMaxItems=65535
DefaultContainerMaxWeight=65535

# UO Feature Enable: Packet 0xA9 Dword, used by newer clients to enable
# specific features or configurations.
# NOTE this value will not be used in packet 0xB9
# (specific UO expansion enable), best to send that
# In login/reconnect.src. BE VERY CAREFUL WITH THIS
# SETTING, VERY POSSIBLE IT IS HARMFUL. I would
# also not expect any of these to work, but they're here
# for completeness. Set to 0x00
# if you don't know what you're doing.
#
# Values courtesy of LordBinary, and darkstorm
#
# 0x02 = send config/req logout (IGR?)
# 0x04 = single character (siege)
# 0x08 = enable npcpopup menus
# 0x10 = unknown
# 0x20 = enable common AOS features (tooltip thing/fight system book, but
# not AOS monsters/map/skills (0xB9 controls))
#
UOFeatureEnable=0x1a0


#
# HiddenTurnsCount
# This will define whether or not turns made while hidden will count as a "move".
# It defaults to 1, which is the way POL has always previously operated. If set
# to zero, then if you are hidden and make a turn, it will not count against your
# stealth steps, nor will it unhide you if you are not stealthing. If set to one,
# turns while hidden do count against stealthsteps, and will unhide you if you
# are not stealthing.
#
HiddenTurnsCount=0

#
# InvulTag
# This will define whether or not to display the Invul tag for mobs, and if so, HOW
# to display them. It defaults to 1, which is the way POL has always previously operated.
# If set to zero, then there will be no way to tell invuls from not by single click, etc.
# If set to 2 (only use this if your shard is for 3.x+ Clients!) it will remove the
# invul tag on their name, and make them highlightable as Yellow/Gold instead!
#
InvulTag=1

#
# MaxPathFindRange
# This will define the maximum distance between the start and destination points
# which pathfinding will be performed on. If PathFind is called on points greater
# than this value, an error result will be returned with "Beyond Max Range." as
# the errortext. Default value for this is 50.
#
MaxPathFindRange=50

#
# ItemColorMask
# It is a bitmask of what colors should be considered valid. For example, with an
# ItemColorMask of 0xFFF, any color from 0 to 4095 is considered a valid color.With
# an ItemColorMask of 0xFF, this would be reduced to a range from 0 to 255. It was
# left a mask instead of given as a range in order to allow specifying certain bits
# to be on. So, for instance, with the newer clients, a mask of 0x4FFF will allow
# the third bit (value 4) of the most significant nibble to be turned on, but no
# others in that nibble. This allows for newer clients to use the "transparent
# animation" feature, which allows equipped mounts to be transparent(ie, ethereals).
# Bear in mind, older clients may well crash if you set colors to be outside of the
# non-default mask of 0xFFF, so this is strictly at your own risk to use it. But
# for those of you wishing ethereal beetles and other mount animations to be
# ethereal, you will have to set the mount piece to be color 0x4001 and then equip
# it. And in order to do that, you will need an ItemColorMask of 0x4FFF.
ItemColorMask=0x4FFF

# On Windows enable the low fragmentation heap
UseWinLFH=1

# CoreHandledTags: bitfield to determine which tags are displayed on singleclick, current used bits are:
# 0x1 [title_guild]
# 0x2 [frozen]
# 0x4 [paralyzed]
# 0x8 [squelched]
# 0x10 [deafened]
# CoreHandledTags=0xffff

# SpeechRange: definies the range of normal speech (default 12)
# SpeechRange=12
# WhisperRange: definies the range of whispered speech (default 2)
# WhisperRange=2
# YellRange: definies the range of yelled speech (default 25)
# YellRange=25

# SpeedhackPrevention : 1 activates the intern SpeedHackPrevention system
SpeedhackPrevention=0

# CoreSendsSeason: Determines if the core should send season packet on char
# creation/logon/reconnect and realm change based on the season entry in realm.cfg (Default 1)
# CoreSendsSeason=1

# PrivacyPaperdoll: If enabled Paperdoll gives only char name for others.
PrivacyPaperdoll=0

# CoreSendsCaps: makes POL send attribute cap information in the Send Skills (0x3A) packet (default 0)
CoreSendsCaps=0

# SendStatLocks: makes POL send stat lock message (Client version > 3) (default 0)
SendStatLocks=0

# ForceNewObjCachePackets: Forces to only send new ObjectCacheInfos for Tooltips (since 5.0.0)
ForceNewObjCachePackets=0

# SupportFaces : 0 disables faces support, 1 basic faces support,
# 2 roleplay faces (sets 0x2000 flag in 0xB9 packet) (KR/SA feature)
SupportFaces=0

Wichtig sind folgende Einträge:
UOFeatureEnable=
Hier haben wir UO-ML eingestellt, aber nach dem Tipp oben im Kommentar kann man da auch 0 setzen. Schaut euch das mal an, das ist recht wichtig auch beim Login.
Die Spezial-Einträge am Ende (Faces, etc.) solltet ihr eventuell deaktivieren, wenn das nicht der Fall ist. Einschalten kann man sie immer noch. (UseWinLFH wird unter Linux ignoriert).
CoreSendsSeason ist bei uns auskommentiert, weil wir das extra gescriptet haben. Sonst würde ich es auf default lassen. Allerdings sollte das den Login nicht verhindern, denke ich.

So - das ist vorerst mal alles, was mir dazu einfällt: Viel Glück, ihr schafft das. Bitte berichte wie es weiter geht :wink:

Horus

Mahlzeit :)

Erstmal Danke an Horus! dein Text hat ungemein geholfen :)

Ich bin der Arme Hund der "Kramphaft" versucht den 99er POL aufzusetzen.
Das Problem mit dem Login habe ich gelöst bekommen (lag an der pol.cfg), nur wenn man jetzt auf den Server Connected, Freezet der Server und gibt Folgendes aus.

Code:

No clock movement in 30 seconds. Dumping thread status.
*Thread Info*
Semaphore PID: 4028
Scripts Thread Checkpoint: 0
Last Script: pkg/foundations/hooks/regen.ecl PC: 5630
Escript Instruction Cycles: 4919081097
Tasks Thread Checkpoint: 1
Active Client Thread Checkpoint: 116
Current Threads:
164 - Decay_home
700 - Main
728 - Decay_britannia
1476 - Reap
1864 - Decay_malas
2168 - UO Client Listener Port 5003
2800 - Decay_ilshenar
3420 - ThreadStatus
3504 - Scripts
3636 - AuxService
3664 - Decay_tokuno
3908 - Tasks
4028 - SocketClientThread
4040 - ClientTransmit
4056 - DbgListn
Child threads (child_threads): 14
Registered threads (ThreadMap): 15

Das regen script hab ich schon gegen die Standard Datei ausgetauscht und testweise mal für alle Werte ein return 1; getauscht, alles ohne erfolg.
Egal welcher Client 5/6/7 alle bringen den Server zum einschlafen.
Sämtliche Datafiles wurden komlett neu erstellt, keine items oder änliches vorhanden.
Beim Normal einloggen mit Char sieht man die Welt (Server friert Sofort ein), beim erstellen eines neuen Chars kommt man erst garnicht bis zum Aufbau der Map (Server friert hier ebenfalls ein). Gibts da evntl. hilfreiche Tips?

edit sagt:
Problem gelöst, Server läuft. Irgendwo kommt 99 nicht mit unserer logon klar :D möge die Lustige Fehlersuche beginnen :)
dennoch besten dank für die Hilfe!!!

Momentan testen wir Pol99 noch, aber ein Fehler bereitet uns noch Kopfschmerzen. Und zwar haben wir auf Pol99 keine verschliessbaren Truhen. Man kann nichts abschliessen. Irgend eine Idee?

Momentan stehen wir vor folgendem Problem;

Wir haben uns die aktuellen Pol-OpenSource Files runtergeladen und wollten etwas experimentieren, bzw. auf unserem Pol-Shard immer die neuste Pol-Version nutzen. Diese aber muss man ja selbst compilieren. Hat jemand eine Idee, wie diese am besten zu compilieren ist, mit welcher VS-Version, usw.. Mit Visual Studio 2013 Express (die kostenlose Version) hatten wir keinen Erfolg. Wir können uns auch eine andere Version besorgen.
Über jegliche Hilfe wären wir sehr dankbar.

Mitglied-3353 hat geschrieben:Momentan testen wir Pol99 noch, aber ein Fehler bereitet uns noch Kopfschmerzen. Und zwar haben wir auf Pol99 keine verschliessbaren Truhen. Man kann nichts abschliessen. Irgend eine Idee?

Hat das unter 098 geklappt? Wenn ja, dann bitte mal die itemdesc.cfg durchsehen und alle als Container definierten Items checken. (Bei allen diesen Sachen ist die POL-Docu auf der POL-Seite sehr nützlich)
Wenn ein Container korrekt definiert ist, dann kann man ihn auch per Script versperren. Jedes Containeritem hat ein Prop dazu (.locked). Aber es ist etwas Scriptaufwand nötig. Wenn das schon unter 098 geklappt hat, dann sollte nicht viel fehlen. Einige Definitionen bei den Containern könnten fehlen bzw. falsch sein.

Horus

Mitglied-3353 hat geschrieben:Momentan stehen wir vor folgendem Problem;

Wir haben uns die aktuellen Pol-OpenSource Files runtergeladen und wollten etwas experimentieren, bzw. auf unserem Pol-Shard immer die neuste Pol-Version nutzen. Diese aber muss man ja selbst compilieren. Hat jemand eine Idee, wie diese am besten zu compilieren ist, mit welcher VS-Version, usw.. Mit Visual Studio 2013 Express (die kostenlose Version) hatten wir keinen Erfolg. Wir können uns auch eine andere Version besorgen.
Über jegliche Hilfe wären wir sehr dankbar.

Das ist eine größere Sache, den Core zu kompilieren. Es ist natürlich möglich, aber ehrlich gesagt würde ich niemals die jeweils letzte Version einfach kompilieren und nutzen. Die Frage ist also, wozu...

Aber egal, hier einige Hinweise:

Allgemein: Wir verwenden eine alte 099 Version, und haben einige der neueren Features nicht, weil wir sie auch nicht brauchen. (Alle unsere Scripts sind selbst geschrieben, und alle klappt. Ich hab keine Lust, nach jedem Core-Update 20 Scripts zu ändern, und Fehler zu suchen, die es vorher nicht gab).
POL nutzt als C++ Programm die Sdtlib. Ganz ursprünglich wurde die von Microsoft verwendet. Weils einfach heiter ist, hier der uralte Eintrag dazu:

Code:

06-05 Syzygy
The .NET build now uses STLport 4.5.3 instead of MS's crappy implementation.
It seems to be a bit faster now.
Some comparison sysload numbers, using Xandros' huge shard data:
.NET old: 100(33018), 100(16326), 100(62705), 100(64700), 100(66679), 100(67030), 100(67030), 93(53725), 5(0), idle
VC6 05-24: 98(33533), 100(18338), 25(1519), 0(0), idle
.NET now: 35(19292), 6(1), idle

Tatsächlich hat der Core massiv an Stabilität gewonnen und wurde deutlich schneller, als man auf STLPort (eine open source stdlib) umgestiegen ist. Diese STLPort-Library wurde vor einiger Zeit entfernt, aber wir nutzen sie unter Windows noch, eben wegen der älteren Version. Da wir früher einen Windows-Server hatten (was ca. 30% meiner sarkastischen Kommentare zu Microsoft erklären sollte), haben wir den auch als Server verwendet und nicht nur zum Testen daheim. Lief sehr stabil und gut.

Statt der STLPort-Lib wird nun die moderne und vielseitige Boost-Lib genutzt, sie ist sowohl unter Windows als auch unter Linux nutzbar. Frühere Linux-Versionen haben weder STLPort noch Boost genutzt, sondern einfach die ausgezeichnete stdlib von GNU zum C++ Compiler. Die nutze ich derzeit auch, da auch unter Linux unsere Version eingesetzt wird.

Die Boost-Lib ist riesig, und daher sind eigene Schritte zum Kompilieren nötig, die aber dokumentiert sind. Wichtig ist, dass man immer denselben Kompiler verwendet.

1) Windows: Hier kann man die Sourcen elegant holen und verwalten mit Tortoise-SVN. Das kann ich nur empfehlen. Wir verwenden das auch für unsere Scripts in einem eigenen SVN.
Holt erstmal den kompletten SVN-Tree. Unter trunk/devmachine findet ihr Hinweise, ebenso gibt es Scripts.
Es gibt für Visual Studio 2012 und 2013 .sln Files, die eigentlich fertig sind. Also sollte das laufen...
ABER: Das ist jeweils für die Vollversionen, wenn ich mich recht erinnere. Da fehlen leider einige Teile, was aber nicht tragisch ist, da diese Teile nicht gebraucht werden.
Hier ein Link (http://forums.polserver.com/viewtopic.php?f=20&t=3414&p=16755&hilit=compile+POL+core#p16755) zu einem alten Post, das einiges erklärt. Allerdings passt es auch zu einer älteren Version von POL. Beachtet vor allem, was zum Thema V-Studio-Express versus V-Studio gesagt wurde...

Mit VS2013 hab ich es nicht versucht, mit VS2012 sollte es klappen (bitte sehr darauf achten, dass man mit VS2012 auch das richtige (pol-2012.sln) öffnet, denn ansonsten beginnt Microsoft in bekannter Intelligenz zu 'wandeln' und Unmengen an sinnlosen bzw. unverständlichen Meldungen auszugeben. Am Ende steht ein Verzeichnis, in dem gar nicht mehr geht.)

Auch mit Boost sollte das klappen, einfach das volle SVN-Verzeichnis holen und Hinweise und Scripts lesen, da kommt man nicht herum...

2) Linux: Sourcen kopieren oder holen (besser holen). Ich mache das in einer VM mit Linux unter WIndows. (Am Server kompilieren setzt voraus, dass alles mögliche Zeugs dort installiert ist, was unnötig ist).
Bei Linux braucht man STLPort nicht, und bei unserer Version auch Boost (noch) nicht. Da gibt es auch einen Script bzw. ein makefile dazu.
WICHTIG: Bei unserer alten Version war ein 64-bit-core noch nicht vorgesehen. Er kompiliert zwar und laeuft auf den ersten Blick tadellos, hat aber seltsame Fehler, die man nicht sofort bemerkt. Deswegen kompiliere ich als 32-bit-Version. Ich verwende die static gelinkte Version (also eine Version, die keine Laufzeitbibliotheken nutzt). Diese Version läuft ohne irgendwelche Mucken nun seit Monaten stabil auf einem Linux-x64-Server. Die Kompilierung ergibt auch keine Fehler.

Das Core-Team verwendet allerdings eine eigene buildmachine (siehe POLSVN/trunk/devmachine/.., basiert auch auf einer VM), und mit neueren Versionen klappt auch x-64-build. Über die Stabilität kann ich nichts sagen, da ich bisher eben unseren alten 099-core verwende.

Wenn ihr euch das also antun wollt, empfiehlt es sich:
1) Legt ein POLSVN-Verzeichnis an und baut jeweils den Build-Prozess auf, einmal für Windows, wenn nötig und einmal unter Linux. Ich empfehle hier VM-Player und eine VM mit Linux, das klappt gut. Hinweise findet man in den diversen Verzeichnissen, trunk/... des POLSVN.
2) Falls ihr selbst mal was fixt in den Sourcen, macht das nichts. Ihr könnt es natürlich nicht commiten, aber die Änderungen werden beim SVN-Update nicht überschrieben, und wenn es Konflikte gibt, werdet ihr darauf hingewiesen.
3) Plant durchaus einige Tage ein, bis das sauber läuft, es ist einiges einzurichten, es ist nur dann auf Knopfdruck, wenn ihr es exakt so macht, wie das core-Team. Man braucht auch etwas Erfahrung, es ist einfach ein riesiges Programm, und es werden ja auch ecompile und die Tools übersetzt. Wenn man die Sourcen nicht wenigstens lesen und teilweise verstehen kann, sollte man sich das nicht antun...
(Anmerkung: Falls ihr unter Linux seltsame Probleme mit den Realms von UO habt, das ist ein core-Bug, ich hab nen Fix dafür. Aber möglicherweise wird der in neueren Versionen nicht mehr gebraucht).

Ehrlich gesagt empfehle ich, dass ihr die letzte Version, die offiziell verteilt wurde nutzt, und nur dann umsteigt, wenn ihr ein neues Feature wirklich haben wollt. Selbst Kompilieren macht nur Sinn, wenn man Bugs findet und rasch beheben will. Ich habe mit dem Kompilieren in erster Linie deswegen begonnen, weil damals (2011) keine wirklich neue vorkompilierte Version vorhanden war und weil ich beim Test mit 099 echt üble Bugs gesehen habe (die hab ich damals gemeldet und Fixes gepostet, die inzwischen im core drin sind). Aber nun, da ich eigentlich alles habe, was ich brauche, nehme ich mir lieber die Zeit für andere Dinge.
Das Problem mit dem ständig neu Kompilieren ist, dass man dann plötzlich Bugs hat, von denen man nicht weiß, woher sie kommen. Noch dazu treten die dann selten auf, und es dauert eine Weile, bis sie auffallen. Dann geht die Suche los, zuerst die Scripts, dann der Core usw. Ich glaube nicht, dass es das wert ist, speziell wenn die dazu gekommenen Features nicht wirklich gebraucht werden. Aber das ist nur meine persönliche Meinung dazu...

Horus

So, wir hatten uns für die neuste Core Version entschieden da im aktuellem Compiled-Core der Bug war, das Container jeglicher art nicht lockable waren.
Nach einigem hin und her mit Ubuntu, haben wir es schliesslich hinbekommen den neuen Core zu compilen. Bis jetzt verliefen alles Tests fehlerfrei und der Server läuft ohne Probleme. Hoffen wir das der Langzeittest uns weitere Probleme ersparrt. Bis jetzt läuft der Server 1a.
Danke nochmals für die ausführlichen und hilfreichen Tips :)

Mitglied-3360 hat geschrieben:So, wir hatten uns für die neuste Core Version entschieden da im aktuellem Compiled-Core der Bug war, das Container jeglicher art nicht lockable waren.
Nach einigem hin und her mit Ubuntu, haben wir es schliesslich hinbekommen den neuen Core zu compilen. Bis jetzt verliefen alles Tests fehlerfrei und der Server läuft ohne Probleme. Hoffen wir das der Langzeittest uns weitere Probleme ersparrt. Bis jetzt läuft der Server 1a.
Danke nochmals für die ausführlichen und hilfreichen Tips :)

Urghs. Heißt das, dass im offiziell verteilten Core 099 (die Version, die als 'pol-linux-xXXbin-099-2013-09-03-ubuntu.tar.gz' angeboten wird) ein derartiger Bug vorhanden ist?
Das fände ich schlimm, da kompilierte Releases recht selten rauskommen...

Horus

Jap, wurd auch schon im Polforum angesprochen und zur kenntnis genommen.
http://forums.polserver.com/viewtopic.php?f=46&t=5195&p=20851&hilit=locked#p20851

Hmm - die brauchen einen Release-Engineer, der nichts anderes tut als Versionen in Absprache mit den Entwicklern zu übersetzen, intensiv zu testen und dann in Abständen raus zu geben.

Freiwillige vor :?

*schmeißt mal den sorgfältig gespeicherten aber noch ungetesteten Core aus dem Download weg...*

:twisted:

Horus