IMHO:
The only thing you remove with upscaling is the aliasing effect. The texture itself does not get any more details. Only repainting those can bring more details. Also the higher resolution just blurs the image more and more, which doesnt look good for my feeling.
The thing in question: Does it pay the effort…?
Hello all,
i am trying to remove internal equipment similar like adding new equipment - so i use the server functions:
Server.ReqRemoveItem
and altering the shadowlist of the equipment.
Players[uiClientID].oShadowEquipDescList.remove_equipment_item
The players save file is correct and the items are removed as intented. But somehow this does first apply if i reload the whole char (means log off and login again).
I also have modified the equipments mount state before removing it (cause it still was shown in the cargo list) but to no avail.
Does anyone of you has a hint to what i need to look at to apply the removed equipment in time without the need to reload the char?
PS: I tried to replace the engine of a ship and in general it works that way, but as long as the char is not reloaded the two engines seems to be still alive - cause the ship speed is doubled at that time.
Hi,
i have a pretty strange behavior when using commands. For example, when i type into console
/s hi
```prints in system chat <name>: /: hi –> which is wrong, the /: are too many chars
But when i type in
/s hello
I tried to debug the SubmitChat and HkCb_SendChat functions. In SubmitChat the chat message is only what i type in the console. But in HkCb_SendChat the BinaryRDLReader extracts <name>: followed by what should be the chat message.
This behavior is different between debug and release dll, while in release it is not working, it does in debug. And in release its only working if i use 5 or more chars after the shortcut, e.g. /s. I looked through any changes within those two functions and others i made over the past months, but am not able to identify what could cause this strange behavior.
Now has anyone of you a clue where i could look for, and why shorter messages than 5 chars with shortcut commands are not printed correctly into the console.
Which routine adds the name to the extracted text from BinaryRDLReader in HkCb_SendChat while the name is not in the text in SubmitChat. Because i feel something in between those two is causing the misbehavior. Normally the extracted chat message in HkCb_SendChat does not contain the command itself again.
Any hints are welcome. I am really clueless right now and dont want to implement something in HkCb_SendChat to remove shortcuts if they are still detected within the chat message there.</name></name></name>Hm the exception offset seems to be:
0 e 063456f8 0001 (0001) 0:**** Common!BaseWatcher::set_pointer+0x40e8
There are various stack traces when i set this breakpoint. But most are related to:
# Memory ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00 054ac6b8 06284585 054ac6f0 0d195500 00000001 Common!BaseWatcher::set_pointer+0x40e8
01 38 054ac6f0 06284555 00957118 0d2a7e88 00000001 Common!PhySys::GetCenterOfMass+0x15
02 28 054ac718 06284585 47015706 c42058fa 06284466 Common!PhySys::GetRadiusR+0x1e5
03 00000000 00000000 00000000 00000000 00000000 Common!PhySys::GetCenterOfMass+0x15
As usual the BaseWatcher::set_pointer 
The set_pointer takes a Watchable struct pointer which could be everything. However when i try to get the symbol for that pointer then it is
054ac6f0 062844a5 Common!PhySys::GetRadiusR+0x135
As GetRadious takes an CObject pointer and a reference to a Vector (and a bool which doesnt play a role i guess) one of both seems to be null. As a reference cannot be null i assume its the CObject.
I am not sure whether this is of any useful information. I would assume its a timing issue, where for some players something is not yet constructed or destroyed or something like this.
Wow, nice work!
You dont really need milkshape at all. An image editing tool to create your icon. When saved as DDS you need to flip the image, saved as TGA can remain normal order.
You can use the model cloner tool to create a clone of an existing commodity icon, give it a unique new name, open up in UtfEditor, import the new icon and make sure the name and the node name match.
I just can confirm that. I also used to run own functions in different threads, not connected to the serverimpl namespace. This didnt worked and first after including them again resolved it
Further multithreading isnt really worth
ok reversed a bit more. Thanks Adoxa, the bool skip_autosave for me didnt work, at least it should be a BOOL - the bool takes no 4 bytes for me, hence i havent it in the following overview.
The costume seems to be twice - no idea why - but in for me both contain the same infos.
struct PlayerData
{
//long x000, x004, x008, x00C, x010, x014, x018, x01C, x020, x024, x028, x02C, x030, x034, x038, x03C;
//long x040, x044, x048, x04C,
wchar_t wszAccID[40];
long x050, x054, x058, x05C3;
//uint x060;
uint uiNumberOfCharacters;
//long x064, x068, x06C, x070,
//long x074, x078, x07C;
//long x080, x084, x088, x08C, x090, x094, x098, x09C, x0A0, x0A4, x0A8, x0AC, x0B0, x0B4, x0B8, x0BC;
//long x0C0, x0C4, x0C8, x0CC, x0D0, x0D4, x0D8, x0DC, x0E0, x0E4, x0E8, x0EC, x0F0, x0F4, x0F8, x0FC;
//long x100, x104, x108, x10C, x110, x114, x118, x11C, x120, x124, x128, x12C, x130, x134, x138, x13C;
//long x140, x144, x148, x14C, x150, x154, x158, x15C, x160, x164, x168, x16C, x170, x174, x178, x17C;
//long x180, x184, x188, x18C, x190, x194, x198, x19C, x1A0, x1A4, x1A8, x1AC, x1B0, x1B4, x1B8, x1BC;
//long x1C0, x1C4, x1C8, x1CC, x1D0, x1D4, x1D8, x1DC, x1E0, x1E4, x1E8, x1EC, x1F0, x1F4, x1F8, x1FC;
//long x200, x204, x208, x20C, x210, x214, x218, x21C, x220, x224, x228, x22C, x230, x234, x238, x23C;
//long x240, x244, x248, x24C, x250, x254, x258, x25C, x260;
char szCharFile[512];
uint uiShipArchetype;
float fRelativeHealth;
CollisionGroupDescList collisionGroupDesc;
EquipDescList equipDescList;
int uiRank;
int iMoneyNeededToNextRank;
//long x28C, x290, x294, x298, x29C, x2A0, x2A4, x2A8, x2AC, x2B0, x2B4, x2B8, x2BC;
struct structCostume
{
UINT head;
UINT body;
UINT lefthand;
UINT righthand;
UINT accessory[8];
int accessories;
};
structCostume strCostume1;
long x2C0, x2C4, x2C8, x2CC, x2D0, x2D4, x2D8, x2DC, x2E0;
//uint uiHead;
//uint uiBody;
//uint uiLeftHand;
//uint uiRightHand;
//long x2F4, x2F8, x2FC;
//long x300, x304, x308, x30C, x310, x314;
//long x2E4, x2E8, x2EC, x2F0, x2F4, x2F8, x2FC;
//long x300, x304, x308, x30C, x310, x314;
structCostume strCostume2;
uint uiReputation;
int iInspectCash;
int iCyclicRedundancyCheck;
long x324;
EquipDescList oShadowEquipDescList;
int iNumKills;
int iNumMissionSuccesses;
int iNumMissionFailures;
long x340;
//bool bSkipAutosave;
long x344;
uint uiOnlineID;
uint uiShipArchID;
Vector vPosition;
Matrix mOrientation;
FLString flStrWeaponGroup; // 0x10 bytes
long x3C0, x3C4;
ushort usLastEquipID;
ushort x3CA;
uint uiMenuItem;
long x3D0, x3D4, x3D8, x3DC;
uint uiSystemID;
uint uiShipID;
long x3E8;
uint uiBaseID;
uint uiLastBaseID;
long x3F4;
uint uiBaseRoomID;
uint uiCharacterID;
class CAccount *poAccount;
class CPlayerGroup *poPlayerGroup;
uint uiMissionID;
uint uiMissionSetBy;
long x410, x414;
};
Well this is most if not all about Freelancer here. Barely something different. And its quite OK this way. I am coming here to get some news on developments of others, also about the modding.
Social Frameworks dont improve anything. Users have to use them, and honestly i dont like them at all - they are mostly deactivated for data protection reasons. Rewards, well forum rewards are actually good for? The only reward someone needs is to see how many posts he has and how long someone is a member. I personally dont care if you have an uber cool name or icon showing what you are. Bas you are already talking with admins here - so where is the problem. If you have the need to talk to one of them, you can send them PMs 
Also this here is no game server forum. Each mod has that on its own. We had this discussion already in the past. TSP cannot offer that for certain reasons and it wouldnt be in their responsibility at all.
I prefer to come here for modding stuff. Thats what TSP should put its priority at. Or totally break and start something new. I wont visit TSP just if it becomes another game server site. Clearly news about Freelancer are lacking, but that again is not solely the fault of the admins. There is a community and moderators who could do that. Same as for the rest. If someone wants to make a global event, start it on your own or ask for help to start it. I dont see why this has to come from the TSP admin team in first place and why it should run to their expense.
Just my two cents.
I have found some more info on the the PlayerData struct, which i thought will represent so far.
struct PlayerData
{
//long x000, x004, x008, x00C, x010, x014, x018, x01C, x020, x024, x028, x02C, x030, x034, x038, x03C;
//long x040, x044, x048, x04C,
wchar_t wszAccID[40];
long x050, x054, x058, x05C3;
//uint x060;
uint uiNumberOfCharacters;
//long x064, x068, x06C, x070,
char szCharFile[16];
long x074, x078, x07C;
...
I am not sure whether the wszAccIdf is 40 or only 36 (x2) bytes big. At least the last 8 bytes from it were uninitialized cdcdcdcd pointers thought they belong to the account id field.
Also szCharFile was limited to 16 bytes from me, although it seems the other remaining bytes after it (496 bytes) are always 0 - could be that the char file was supposed to use 512 bytes at all, which makes no sense to me. The long after uiOnlineID seems to be the ShipArchID. And the right, left hand and head body addresses seems to be the
struct structCostume
{
UINT head;
UINT body;
UINT lefthand;
UINT righthand;
UINT accessory[8];
int accessories;
};
which would fit in.
I will try to verify that by further investigation, though if anyone else find stuff - could add it or correct it.
HM could you get the CShip anywhere from this entry? It contains
struct IObjRW * get_target(void)const ;
I am just thinking if this could be away, although i dont know how to get the CShip Object. And there is
IObjInspectImpl* HkGetInspect (uint x_uiClientID)
or
typedef bool (__cdecl _GetShipInspect)(uint &x_ruiShip, IObjInspectImpl &inspect, uint &x_ruiDunno)
But i suspect thats not what your are looking for. At least in the last case the x_ruiShipId can be retrieved from the DamageList as far as i understand it.
Isnt there the DamageList which you could use to obtain from whom the damge comes and who is suffering the damage?
Not sure why those global dmgto stuff is used there…
Or is that not your question?
OK, thanks, i will look for an error in our formation definitions. Thanks for the hints. If not i need to get deeper into debugging and set breakpoints at some addresses. Maybe i could track which of the formations is corrupt.
Ahoy, i am trying to figure out a crash thats happening quite often in the dacom and i have no idea how i can find out about the reaon, hence i am posting here. Maybe someone from you has an idea.
This is the crash data:
FAULTING_IP:
dacom!stricmp+c
065b5e6c 0fb60e movzx ecx,byte ptr [esi]
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 065b5e6c (dacom!stricmp+0x0000000c)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0a0f18e4
Attempt to read from address 0a0f18e4
DEFAULT_BUCKET_ID: INVALID_POINTER_READ
PROCESS_NAME: flserver.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 0a0f18e4
READ_ADDRESS: 0a0f18e4
FOLLOWUP_IP:
dacom!stricmp+c
065b5e6c 0fb60e movzx ecx,byte ptr [esi]
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: flserver.exe
FAULTING_THREAD: 00000ef4
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ
BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ
LAST_CONTROL_TRANSFER: from 062df4fb to 065b5e6c
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
0464823c 062df4fb 0a0f2010 0a0f18e4 ffffffff dacom!stricmp+0xc
00000000 00000000 00000000 00000000 00000000 Common!pub::StateGraph::get_state_graph+0x3b
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: dacom!stricmp+c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: dacom
IMAGE_NAME: dacom.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 3e401cd3
STACK_COMMAND: ~29s; .ecxr ; kb
FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_dacom.dll!stricmp
BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_dacom!stricmp+c
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/flserver_exe/1_0_1256_11/3ecbb13e/dacom_dll/1_11_0_173/3e401cd3/c0000005/00005e6c.htm?Retriage=1
Followup: MachineOwner
---------
0:029> .ecxr
eax=0000004e ebx=fffff8dc ecx=0a0f18e4 edx=0a0f2010 esi=0a0f18e4 edi=00000000
eip=065b5e6c esp=0464823c ebp=065b5e60 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
dacom!stricmp+0xc:
065b5e6c 0fb60e movzx ecx,byte ptr [esi] ds:002b:0a0f18e4=??
The stricmp compares NOTHING (which is at address 0a0f2010) with something and i cannot find out with what and why its not accessible. When i look at the disassembly for the last transfer this gives the following:
062df4d9 69c02c070000 imul eax,eax,72Ch
062df4df 8d5808 lea ebx,[eax+8]
062df4e2 a11cca3f06 mov eax,dword ptr [Common!FuseDB::m_FuseINIFiles+0x558 (063fca1c)]
062df4e7 33f6 xor esi,esi
062df4e9 8da42400000000 lea esp,[esp]
062df4f0 8d0c03 lea ecx,[ebx+eax]
062df4f3 51 push ecx
062df4f4 8d540608 lea edx,[esi+eax+8]
062df4f8 52 push edx
062df4f9 ffd5 call ebp
062df4fb 83c408 add esp,8 <<<<<< address of last transfer
062df4fe 85c0 test eax,eax
062df500 a11cca3f06 mov eax,dword ptr [Common!FuseDB::m_FuseINIFiles+0x558 (063fca1c)]
062df505 750a jne Common!pub::StateGraph::get_state_graph+0x51 (062df511)
062df507 8b4c2418 mov ecx,dword ptr [esp+18h]
062df50b 394c0604 cmp dword ptr [esi+eax+4],ecx
062df50f 7419 je Common!pub::StateGraph::get_state_graph+0x6a (062df52a)
062df511 8b0d18ca3f06 mov ecx,dword ptr [Common!FuseDB::m_FuseINIFiles+0x554 (063fca18)]
062df517 47 inc edi
062df518 81c62c070000 add esi,72Ch
So “NOTHING” is only contained in some mission files, as state_graph but i dont see why this is used here. And i have no idea where to start looking for an error, in zones, npcs, missions, fuses.
I am even not sure how i could avoid that crash with a server patch. So any info you might throw in is very much appreciated. If you need any more info i could contribute, dont hesitate to ask me.
Thanks in advance.
Sorry, no idea anymore, that topic is way too old for me to remember.
under linker options there is a setting for inputs there again a setting for the module file. The zone plugin comes with a common.def file. You need to reference it in the linker options, thus the linker can find and use it.
Command line:
/DEF:“Common.def”
remove the _stdcall before the function UserCmdHelp, UserCmdProcess and UserCmdCallback. Its not stdcall. Look at the function in Hook source and reference it the same way as its called there.
Looks very good! Nice piece of work you have done there.
you should not have, make sure you have a virtual destructor in all upper base classes available, so when you have derived1 and derived2 and derived inherits from derived1 then you also need a virtual destructor in derived1 and so on and so forth.
I am not so familiar with shared_prt but in principal you could use them too. But even shared_ptr wont solve the problem of eventual non-virtual destructors. It only takes over destructing if you forget to destruct your objects (as far as i know).
If your Base class has at least one virtual member function, make the base class destructor virtual. The result is undefined when you delete a pointer of a base class, pointing to one of the derived classes.
Also for iterators its better to have a pre increment rather than a post increment.
And use initializer lists for classes rather than to assignment in the constructors body.