writeField Function (adding and editing PT fields)

[Vormav]

Write Field is a function that helps with adding and editing maps in PristonTale client and server.

Write Field by Vormav is licensed under a

You must be registered to see links

.

You are free:

to Share — to copy, distribute and transmit the work
to Remix — to adapt the work
to make commercial use of the work


writeField versions:
1.18.7
1.17.6
1.17.4
1.17.2
1.16.1
1.0.0


PRE AoR/Morion PristonTale maps:
new fixed names with prefix old_

You must be registered to see links

writeField tutorial:
LINK


0) Download:
- Newest version of writeField
-

You must be registered to see links

-

You must be registered to see links

-

You must be registered to see links

1) Open writeClientField.cbp (Code::Blocks). In writeClientField.h you will find those addresses and small tutorial how to find them:

//----- Those addresses change with each version of Priston Tale
LPSTR fieldField                    =  (LPSTR)[COLOR=Magenta]0x007CFFF8[/COLOR];
LPSTR fieldMap                      =  (LPSTR)[COLOR=Magenta]0x007D0078[/COLOR];
LPSTR fieldTitle                    =  (LPSTR)[COLOR=Magenta]0x007D0038[/COLOR];

void *firstFieldPointer             = (void *)[COLOR=Magenta]0x007D00B8[/COLOR];
PBYTE firstField                    =  (PBYTE)[COLOR=Magenta]0x007D00B8[/COLOR];
PBYTE lastField                     =  (PBYTE)[COLOR=Magenta]0x009190D4[/COLOR];


/*  Example from kPT version 1.98.9
 *
 *  [...]
 *
 *  00432DE0  /$ 51             PUSH ECX
 *  00432DE1  |. 53             PUSH EBX
 *  00432DE2  |. 56             PUSH ESI
 *  00432DE3  |. 8B35 34825C00  MOV ESI,DWORD PTR DS:[<&KERNEL32.lstrcpyA>]    ;  kernel32.lstrcpyA
 *  00432DE9  |. 57             PUSH EDI
 *  00432DEA  |. 68 90CC5C00    PUSH game.005CCC90                             ; /String2 = "field\"
 *  00432DEF  |. 68 18F17A00    PUSH game.007AF118         [B]<---[/B] [COLOR=Magenta]fieldField[/COLOR]     ; |String1 = game.007AF118
 *  00432DF4  |. FFD6           CALL ESI                                       ; \lstrcpyA
 *  00432DF6  |. 68 84CC5C00    PUSH game.005CCC84                             ; /String2 = "field\map\"
 *  00432DFB  |. 68 98F17A00    PUSH game.007AF198         [B]<---[/B] [COLOR=Magenta]fieldMap[/COLOR]       ; |String1 = game.007AF198
 *  00432E00  |. FFD6           CALL ESI                                       ; \lstrcpyA
 *  00432E02  |. 68 74CC5C00    PUSH game.005CCC74                             ; /String2 = "field\title\"
 *  00432E07  |. 68 58F17A00    PUSH game.007AF158         [B]<---[/B] [COLOR=Magenta]fieldTitle[/COLOR]     ; |String1 = game.007AF158
 *  00432E0C  |. FFD6           CALL ESI                                       ; \lstrcpyA
 *  00432E0E  |. 33C0           XOR EAX,EAX
 *  00432E10  |. B9 001F0500    MOV ECX,51F00
 *  00432E15  |. BF D8F17A00    MOV EDI,game.007AF1D8      [B]<---[/B] [COLOR=Magenta]firstField[/COLOR] [B]/[/B] [COLOR=Magenta]*firstFieldPointer[/COLOR]
 *  00432E1A  |. F3:AB          REP STOS DWORD PTR ES:[EDI]
 *  00432E1C  |. 33DB           XOR EBX,EBX
 *  00432E1E  |. 33C9           XOR ECX,ECX
 *  00432E20  |. B8 F4057B00    MOV EAX,game.007B05F4
 *  00432E25  |> 8908           /MOV DWORD PTR DS:[EAX],ECX
 *  00432E27  |. 05 7C140000    |ADD EAX,147C
 *  00432E2C  |. 41             |INC ECX
 *  00432E2D  |. 3D F4818F00    |CMP EAX,game.008F81F4     [B]<---[/B] [COLOR=Magenta]lastField[/COLOR]
 *  00432E32  |.^7C F1          \JL SHORT game.00432E25
 *
 *  [...]
 *
 */

- find this code in your game.exe and put those addresses in you writeClientField.h file
- if build target is not set to Release than change it. Rebuild (ctrl + F11) your .dll and copy it (bin\Release) to PristonTale main folder.
- you might need to do same thing for writeServerField.h if for some reason your addresses are different


2) Open game.exe with CFF explorer, in CFF Explorer go to import adder, check Create New Section and press Add. Select writeClientField.dll and press Open. Select function:
- writeClientField
and press Import By Name, press Rebuild Import Table. Save your changes.
- do same thing in server but use writeServerField.dll


3) Open game.exe with OllyDbg, find code posted in .h file. Select top of code (00432DE0 /$ 51 PUSH ECX) and press ctrl + R.
- select CALL and press ENTER
- change this CALL to "CALL writeClientField"
- if there is more than one CALL than change them too
- do same thing in server but use "CALL writeServerField"


4) This point is optional, you can remove (NOP) function that where creating field in PT (and some sub functions that are called only by this function) it will give you some space to assemble other things.


Congratulations you added Write Field to your client and server!

___________________________________________________________________________________

Some things that you should know but you are afraid to ask:

Here is quick functions overview:

- field function:

        // field function
        field((char *)fore_3,                 // field start
              "forest\\fore-3.ase",           // file_path\\file_name.ase
              (char *)"fore-3");              // short title name, 0 = no title

First and always needed, look at comments to understand parameters, nothing more to say about it.


- animation function:

    // animation function
    animation((char *)fore_3,                 // field start
              (char *)"forest\\3ani-01.ASE",  // file_path\\file_name.ase
              0);                             // 0 = ON, 1 = OFF

This function is loading your animated parts of map.


- field cmd fnction:

     // /field <field_number> command function
     fieldCmd((char *)fore_3,         // field start
              -16419,                 // X
              -7054);                 // Z

Admin cmd function, to understand how XYZ in PT works look at tutorial, for PristonTale Z is Y in admin HUD.


- respawn function

      // respawn function, if don't exist than fieldCmd is a respawn
      respawn((char *)fore_3,         // field start
              -10585,                 // X
              -11810);                // Z

Location of your respawn after you die or login to game. If there is no respawn function than fieldCmd function take respawn place.


- teleport function:

    // teleport function
     teleport((char *)fore_3,         // field start
              -16638,                 // X
              -6737,                  // Z
              267,                    // Y
              64,                     // length
              32,                     // width
              55,                     // teleport level, if player level >= teleport level than player can us it
              0);                     // 0 = no animation, 1 = teleport animation, 2 = teleport list

Function making filed that will teleport you to desired location on map. This function is always followed by teleportTo function.


- teleportTo function:

   // teleportation to X Z Y coordinates function
   teleportTo((char *)fore_3,         // field start
              (char *)tcave,          // tcave field
              119112,                 // X
              26028,                  // Z
              510);                   // Y

Function is creating exit location.


- fieldLoad function:

    // Load next field function
    fieldLoad((char *)fore_3,         // field start
              (char *)fore_2,         // fore-2 field
              -8508,                  // X
              -10576,                 // Z
              0);                     // Y

This function will load field that is near.

- sounds function:

        // sounds on field function
        sound((char *)fore_3,         // field start
              -13819,                 // X
              226,                    // Y
              -8950,                  // Z
              100,                    // range
              sndT_watermill_1);      // sound type (use name or number from 0 to 29)

This will put sound on map. Pay attention to XYZ, this is only function that have this order, look at tutorial to understand XYZ of PristonTale


- environment function:

  // environment function
  environment((char *)fore_3,         // field start
              fldT_forest,            // field type (use name or number, fT_forest = 512)
              skyT_forest_day_4,      // day sky (use name or number, skyT_forest_day_4 = 2)
              skyT_forest_evening_5,  // evening sky (use name or number, skyT_forest_evening_5 = 3)
              skyT_forest_night_6,    // night sky (use name or number, skyT_forest_night_6 = 1)
              bgmT_forest_darkwood,   // background music (use name or number from -1 to 12)
              0,                      // 0 = monsters spawn all the time, 1 = monsters spawn only at night
              1,                      // field lvl
              1);                     // skills block

This function control environment on map.




//----- changeLog.txt:

1.18.7
- added new map "sod-2"
- remodeled "Fall_Game" code for new version of "Fall_Game"

1.17.6
- fixed problem with placing NPC on field
- names of old pre AoR fields have old_ prefix

1.17.4
- license changed to Creative Commons Attribution 3.0 Unported License
- IDE changed to Code::Blocks
- C code compile as C++

1.17.2
- added "changeLog.txt" file to source
- added new map "mine-1"

1.16.1
- added 16 new maps from PRE AoR/Morion PristonTale
- bit more clear license statement

1.0.0
- server version created and merged with client version
- fixed missing music in some places
- fixed some sounds
- added new comments


Special thanks for bobsobol.


HAVE FUN WITH IT!!

 

[SheenBR]

Re: PT writeField Function (adding field easy way with source code)

Amazing guide. I'll take a look at the functions :B


--edit---

Really AWESOME. I wish I knew as much as you do in C++.
If you want, I can try to compile them in VC++ 6.0.

---------- Post added 05-02-11 at 12:25 AM ---------- Previous post was 04-02-11 at 10:50 PM ----------

If you permit, I did a few "changes". My few knoledge in C++ doesn't allow me to do much.

I have added:

// map types
#define m_town 256
#define m_forest 512
#define m_desert 768
#define m_ruins 1024
#define m_dungeon 1280
#define m_iron 1536
#define m_office 2048
#define m_ice 2304
#define m_castle 2560
#define m_minigame 2816

It is better for me to understand what I am adding.
Vormav, if you like, I can "re-release" it. If not, well ok, I'll keep it to me.

 

[bobsobol]

Re: PT writeField Function (adding field easy way with source code)

Fantastic. This is exactly the sort of development I hoped would appear when I released the guide

You must be registered to see links

.

Awesome work, and very well done. I'm sure I will have some "patch" files for updating it too.

Really AWESOME. I wish I knew as much as you do in C++.
If you want, I can try to compile them in VC++ 6.0.

I can probably make "project" files to build in VC++ 6 to 9, and maybe even a GNU make file.

I have added:

[COLOR=Green]// map types[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_town                         [COLOR=Red]256[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_forest                       [COLOR=Red]512[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_desert                       [COLOR=Red]768[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_ruins                        [COLOR=Red]1024[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_dungeon                      [COLOR=Red]1280[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_iron                         [COLOR=Red]1536[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_office                       [COLOR=Red]2048[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_ice                          [COLOR=Red]2304[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_castle                       [COLOR=Red]2560[/COLOR]
[COLOR=DarkOrchid]#define[/COLOR] m_minigame                     [COLOR=Red]2816[/COLOR]

This should be:-

[COLOR=Blue]enum[/COLOR] wF_MapType
{
  wFm_town = [COLOR=Red]256[/COLOR],
  wFm_forest = [COLOR=Red]512[/COLOR],
  wFm_desert = [COLOR=Red]768[/COLOR],
  wFm_ruins = [COLOR=Red]1024[/COLOR],
  wFm_dungeon = [COLOR=Red]1280[/COLOR],
  wFm_iron = [COLOR=Red]1536,[/COLOR]
  wFm_office = [COLOR=Red]2046[/COLOR],
  wFm_ice = [COLOR=Red]2304[/COLOR],
  wFm_castle = [COLOR=Red]2560[/COLOR],
  wFm_minigame = [COLOR=Red]2816[/COLOR]}

This allows later code to only accept parameters of type wF_MapType and nothing else, and makes the code more self-documenting and parameter safe.

Spoiler

well, not following the standard should produce a warning rather than break the build, but you know what I mean

There are other points where this method should be used, like the SkyBox parameter. I believe these should live in a .h file.

Vormav, if you like, I can "re-release" it. If not, well ok, I'll keep it to me.

I would consider that bad etiquette. IDK how Vormav feels, but what we should do to help him is submit a

You must be registered to see links

for him to synchronise with his own source and update his release.

You could post them here, and he can update, or you could PM him, as I did Ávila with the changes I made to his PreAOR cSelect files.

Spoiler

can't diff those as they are binaries, you'd need a binpatch or such, and they aren't so common, or standardised

 

[Vormav]

Re: PT writeField Function (adding field easy way with source code)

Really AWESOME. I wish I knew as much as you do in C++.
If you want, I can try to compile them in VC++ 6.0.

Thank you, no need to do something like that, at lest not for now.
And they will not work if you just compile them some modifications need to be done.

Vormav, if you like, I can "re-release" it. If not, well ok, I'll keep it to me.

Re-release? But what? Your code reach that advance lvl? If its only added enum fieldType than its just a small patch that anyone can add at any time.

Fantastic. This is exactly the sort of development I hoped would appear when I released the guide

You must be registered to see links

.

Awesome work, and very well done. I'm sure I will have some "patch" files for updating it too.
I can probably make "project" files to build in VC++ 6 to 9, and maybe even a GNU make file.

Thank you.
What with that C++ mania?

I think Dev-C++ is good one and you can set your output directly to PT folder so your edited dll will end up in PT and you are ready to go.

This should be:-

[COLOR=Blue]enum[/COLOR] wF_MapType
{
  wFm_town = [COLOR=Red]256[/COLOR],
  wFm_forest = [COLOR=Red]512[/COLOR],
  wFm_desert = [COLOR=Red]768[/COLOR],
  wFm_ruins = [COLOR=Red]1024[/COLOR],
  wFm_dungeon = [COLOR=Red]1280[/COLOR],
  wFm_iron = [COLOR=Red]1536,[/COLOR]
  wFm_office = [COLOR=Red]2046[/COLOR],
  wFm_ice = [COLOR=Red]2304[/COLOR],
  wFm_castle = [COLOR=Red]2560[/COLOR],
  wFm_minigame = [COLOR=Red]2816[/COLOR]}

This allows later code to only accept parameters of type wF_MapType and nothing else, and makes the code more self-documenting and parameter safe.

Good idea. But what wFm stand for? writeFieldmap? I think it should be
fieldType_town = 256 etc.

Numbers are faster and after a while everyone will know whats in 1st, 2nd, 3rd etc parameter is.
But idea itself is very good

There are other points where this method should be used, like the SkyBox parameter. I believe these should live in a .h file.

Sky types will be hard to name... you might end up with something like that day1, day2, night1, meteorShower etc. same goes for music and sounds on field.

But I would love to have "standards" so anyone can use number or name.
If we end up with using names than we can't change them later! So its something we all need to decide!

I would consider that bad etiquette. IDK how Vormav feels, but what we should do to help him is submit a

You must be registered to see links

for him to synchronise with his own source and update his release.

I released code so anyone can add or edit field without any problems. Everything you add do it should be open source. If anyone will add his modifications and keep it for him self than whats the point in me releasing it?

I don't want to have 20 versions of same code I want to have 1 with all modifications in one place and 1 standard for names etc...


Thanks again and I hope this is something useful that we where lacing for long time =P



PS. If I or my naming sounds funny in code than tell me about it =P
If you don't understand something ask, there are many things that I did not explain yet.

PS2. as I said SEVER version coming soon

 

[SheenBR]

Re: PT writeField Function (adding field easy way with source code)

what do you think of a Delphi version of it?

 

[bobsobol]

Re: PT writeField Function (adding field easy way with source code)

Good idea. But what wFm stand for? writeFieldmap? I think it should be fieldType_town = 256 etc. Numbers are faster and after a while everyone will know whats in 1st, 2nd, 3rd etc parameter is. But idea itself is very good

Well, that's why I made the prefix simply wFm. An attempt to avoid name conflicts, but the longer it becomes, the more effort it is to type, and remember. It's more important in #defines than enums as the enum declares what "kind" it should refer to, but you get "ambiguity" warnings from the compiler if there is a conflict with another type of the same name.

Spoiler

Windows Messaging, Sheens #define way

Spoiler

#define WM_ACTIVATE                     0x0006
#define WM_APPCOMMAND                   0x0319
#define WM_CHAR                         0x0102
#define WM_HOTKEY                       0x0312
#define WM_KEYDOWN                      0x0100
#define WM_KEYUP                        0x0101
#define WM_KILLFOCUS                    0x0008
#define WM_SETFOCUS                     0x0007
#define WM_SYSDEADCHAR                  0x0107
#define WM_SYSKEYDOWN                   0x0104
#define WM_UNICHAR                      0x0109

Windows Virtual Key codes, the #define way

Spoiler

/* Virtual key codes */
#define VK_LBUTTON          0x01
#define VK_RBUTTON          0x02
#define VK_CANCEL           0x03
#define VK_MBUTTON          0x04
#define VK_XBUTTON1         0x05
#define VK_XBUTTON2         0x06
/*                          0x07  Undefined */
#define VK_BACK             0x08
#define VK_TAB              0x09
/*                          0x0A-0x0B  Undefined */
#define VK_CLEAR            0x0C
#define VK_RETURN           0x0D
/*                          0x0E-0x0F  Undefined */
#define VK_SHIFT            0x10
#define VK_CONTROL          0x11
#define VK_MENU             0x12
#define VK_PAUSE            0x13
#define VK_CAPITAL          0x14

#define VK_KANA             0x15
#define VK_HANGEUL          0x15
#define VK_HANGUL           0x15
#define VK_JUNJA            0x17
#define VK_FINAL            0x18
#define VK_HANJA            0x19
#define VK_KANJI            0x19

/*                          0x1A       Undefined */
#define VK_ESCAPE           0x1B

#define VK_CONVERT          0x1C
#define VK_NONCONVERT       0x1D
#define VK_ACCEPT           0x1E
#define VK_MODECHANGE       0x1F

#define VK_SPACE            0x20
#define VK_PRIOR            0x21
#define VK_NEXT             0x22
#define VK_END              0x23
#define VK_HOME             0x24
#define VK_LEFT             0x25
#define VK_UP               0x26
#define VK_RIGHT            0x27
#define VK_DOWN             0x28
#define VK_SELECT           0x29
#define VK_PRINT            0x2A /* OEM specific in Windows 3.1 SDK */
#define VK_EXECUTE          0x2B
#define VK_SNAPSHOT         0x2C
#define VK_INSERT           0x2D
#define VK_DELETE           0x2E
#define VK_HELP             0x2F
/* VK_0 - VK-9              0x30-0x39  Use ASCII instead */
/*                          0x3A-0x40  Undefined */
/* VK_A - VK_Z              0x41-0x5A  Use ASCII instead */
#define VK_LWIN             0x5B
#define VK_RWIN             0x5C
#define VK_APPS             0x5D
/*                          0x5E Unassigned */
#define VK_SLEEP            0x5F
#define VK_NUMPAD0          0x60
#define VK_NUMPAD1          0x61
#define VK_NUMPAD2          0x62
#define VK_NUMPAD3          0x63
#define VK_NUMPAD4          0x64
#define VK_NUMPAD5          0x65
#define VK_NUMPAD6          0x66
#define VK_NUMPAD7          0x67
#define VK_NUMPAD8          0x68
#define VK_NUMPAD9          0x69
#define VK_MULTIPLY         0x6A
#define VK_ADD              0x6B
#define VK_SEPARATOR        0x6C
#define VK_SUBTRACT         0x6D
#define VK_DECIMAL          0x6E
#define VK_DIVIDE           0x6F
#define VK_F1               0x70
#define VK_F2               0x71
#define VK_F3               0x72
#define VK_F4               0x73
#define VK_F5               0x74
#define VK_F6               0x75
#define VK_F7               0x76
#define VK_F8               0x77
#define VK_F9               0x78
#define VK_F10              0x79
#define VK_F11              0x7A
#define VK_F12              0x7B
#define VK_F13              0x7C
#define VK_F14              0x7D
#define VK_F15              0x7E
#define VK_F16              0x7F
#define VK_F17              0x80
#define VK_F18              0x81
#define VK_F19              0x82
#define VK_F20              0x83
#define VK_F21              0x84
#define VK_F22              0x85
#define VK_F23              0x86
#define VK_F24              0x87
/*                          0x88-0x8F  Unassigned */
#define VK_NUMLOCK          0x90
#define VK_SCROLL           0x91
#define VK_OEM_NEC_EQUAL    0x92
#define VK_OEM_FJ_JISHO     0x92
#define VK_OEM_FJ_MASSHOU   0x93
#define VK_OEM_FJ_TOUROKU   0x94
#define VK_OEM_FJ_LOYA      0x95
#define VK_OEM_FJ_ROYA      0x96
/*                          0x97-0x9F  Unassigned */
/*
 * differencing between right and left shift/control/alt key.
 * Used only by GetAsyncKeyState() and GetKeyState().
 */
#define VK_LSHIFT           0xA0
#define VK_RSHIFT           0xA1
#define VK_LCONTROL         0xA2
#define VK_RCONTROL         0xA3
#define VK_LMENU            0xA4
#define VK_RMENU            0xA5

#define VK_BROWSER_BACK        0xA6
#define VK_BROWSER_FORWARD     0xA7
#define VK_BROWSER_REFRESH     0xA8
#define VK_BROWSER_STOP        0xA9
#define VK_BROWSER_SEARCH      0xAA
#define VK_BROWSER_FAVORITES   0xAB
#define VK_BROWSER_HOME        0xAC
#define VK_VOLUME_MUTE         0xAD
#define VK_VOLUME_DOWN         0xAE
#define VK_VOLUME_UP           0xAF
#define VK_MEDIA_NEXT_TRACK    0xB0
#define VK_MEDIA_PREV_TRACK    0xB1
#define VK_MEDIA_STOP          0xB2
#define VK_MEDIA_PLAY_PAUSE    0xB3
#define VK_LAUNCH_MAIL         0xB4
#define VK_LAUNCH_MEDIA_SELECT 0xB5
#define VK_LAUNCH_APP1         0xB6
#define VK_LAUNCH_APP2         0xB7

/*                          0xB8-0xB9  Unassigned */
#define VK_OEM_1            0xBA
#define VK_OEM_PLUS         0xBB
#define VK_OEM_COMMA        0xBC
#define VK_OEM_MINUS        0xBD
#define VK_OEM_PERIOD       0xBE
#define VK_OEM_2            0xBF
#define VK_OEM_3            0xC0
/*                          0xC1-0xDA  Unassigned */
#define VK_OEM_4            0xDB
#define VK_OEM_5            0xDC
#define VK_OEM_6            0xDD
#define VK_OEM_7            0xDE
#define VK_OEM_8            0xDF
/*                          0xE0       OEM specific */
#define VK_OEM_AX           0xE1  /* "AX" key on Japanese AX keyboard */
#define VK_OEM_102          0xE2  /* "<>" or "\|" on RT 102-key keyboard */
#define VK_ICO_HELP         0xE3  /* Help key on ICO */
#define VK_ICO_00           0xE4  /* 00 key on ICO */
#define VK_PROCESSKEY       0xE5

/*                          0xE6       OEM specific */
#define VK_PACKET           0xE7
/*                          0xE8       Unassigned */
/*                          0xE9-0xF5  OEM specific */

#define VK_ATTN             0xF6
#define VK_CRSEL            0xF7
#define VK_EXSEL            0xF8
#define VK_EREOF            0xF9
#define VK_PLAY             0xFA
#define VK_ZOOM             0xFB
#define VK_NONAME           0xFC
#define VK_PA1              0xFD
#define VK_OEM_CLEAR        0xFE

/* MapVirtualKey translation types */
#define MAPVK_VK_TO_VSC     0
#define MAPVK_VSC_TO_VK     1
#define MAPVK_VK_TO_CHAR    2
#define MAPVK_VSC_TO_VK_EX  3
#define MAPVK_VK_TO_VSC_EX  4

In any event, enums and #defines are essentially global scope consts. So you have to be careful.

You must be registered to see links

has a funny parable about getting this wrong, and concludes with a method of class member enums in C++ so you could allow:-

environment(newfield     /* Field start (new field every 5244)*/,
    MapType::Town,
    DaySky::Two,
    EveningSky::Three,
    NightSky::One,
    Music::Pilgrim,
    False, // All day spawns
    True,  // Night time spawns
    True); // Skills blocked

If that looks more pleasing?

Spoiler

False = 0 and True = 1 according to Windows.h. Though I frequently disagree, believing that True should = -1.

I'm just making names up within the classes, as I haven't checked out all the possible legal values.

It's important to note that enums (and #defines) aren't strongly type-safe. But in C++ you should at least be warned that what you are doing is questionable with an enum, where you won't get anything from a #define.

You must be registered to see links

has many possible methods and their various pitfalls.

If we end up with using names than we can't change them later! So its something we all need to decide!

You can change them... but that breaks the standard you have already defined.

I don't want to have 20 versions of same code I want to have 1 with all modifications in one place and 1 standard for names etc...

This is why I suggest we send you patch files. You can decide on the ultimate standard, and "cherry pick" from the improved / extended methods we come up with.:

You must be registered to see links

is very good for adding bits from this implementation, and bits from that, and it can make Diff patch files too I believe. But *we* should supply you with separate patches for individual features or improvements... so you shouldn't need do too much.

The standard Microsoft Diff tool(WinDiff) is of course a nasty GUI affair, but you may like that (IDK) and the most common official download source is

You must be registered to see links

. It has lots of other stuff in it too... other people have re-distributed WinDiff separately. Google it.

It takes a little going through, but the other alternative is setting up a repository... and TBH, I don't see that as any easier when it comes to merging forks, unless it's

You must be registered to see links

, and you trust your fork trunk managers very well.

You are now original developer, and lead project manager. tt1:

 

[SheenBR]

Re: PT writeField Function (adding field easy way with source code)

I dont remember how to make an emu. I dont see a point to learn C++, I mean, VS C++ 2010 uses .net, am I right? If yes, it is now a ManagedCode.

And, between C++ Managet(IDK it) and C# ( Yes, I'm pretty good with it) I prefer to stay in C#.

Dev Cpp doesnt have that Forms thing, so everything goes with API codes.
The same with MFC, but MFC does has that Forms window, where you can add a textbox and stuff, but still, C++ 6.0 is old, I'd like to learn C++2010, but I think it is managed code. If I am wrong, pleasea correct me.

**This is DEFINATELY NOT a critic to anything that Vormav does.**

 

[bobsobol]

Re: PT writeField Function (adding field easy way with source code)

Largely OT, and pretty much a direct response to Sheen

Spoiler

I dont remember how to make an emu. I dont see a point to learn C++, I mean, VS C++ 2010 uses .net, am I right?

No. I'm sorry, you are wrong.
Correctly, it can build to .Net "Managed Code", but if you do that you throw away all the advantage of using C++, tie one hand behind your back because you can't properly utilise the .Net framework and generally waste a lot of time. The only good reason to build to .Net in VC++ is if you are still in the throws of converting classic C++ code to a .Net framework managed application.

If yes, it is now a ManagedCode.

Optionally. And it's a bad option to take, unless you are porting from unmanaged to managed solution... and then only until you have completely ported to C#... which is actually easier to do that fix C++ code to work in the .Net framework most of the time. It's works so long as your C++ isn't based on any other framework at all. No ActiveX, COM, DCOM, COM+, MFC, ATL, STL, QT etc. etc. etc. If your C++ includes and uses any of these, you may as well throw it in the bin and translate the whole lot of a C# namespace.

And, between C++ Managet(IDK it) and C# ( Yes, I'm pretty good with it) I prefer to stay in C#.

Dev Cpp doesnt have that Forms thing, so everything goes with API codes.

Yes, it's more professional than Visual C. XD

The same with MFC, but MFC does has that Forms window, where you can add a textbox and stuff, but still, C++ 6.0 is old, I'd like to learn C++2010, but I think it is managed code. If I am wrong, pleasea correct me.

You have pretty much solved your own dilemma. Going MFC or ATL or some variant of COM or WinForms is "Event Driven" programming. C, and C++ are not designed to be used like this. They are meant to be "Process Driven" taking all input on the command line before the program starts, and then producing output without interacting with the user constantly while it runs, and returning to the command line when finished. Or, waiting only on simple command inputs. Ther only place you would find a GUI, or WIMP (Windows, Icons, Menus and Pointer) when C++ was conceived was an Apple Lisa.

Windows is not designed not to be used like this, and no other operating system is very good with Event Driven systems, which are usually bolted on as an after thought. Even on a Mac which preferred the old Objective C to C++. (except, possibly the old Amiga OS, which is happy either way, but prefers C or BCPL.)

"Event Driven" or "Forms Based" programming is considering programming for people who don't know how to write proper programs. Because the first think you are taught is that you don't design a program from the point of view of it's user interface, but from it's function. You design the functionality, then program it, then test it, then you consider what user interface you might like to have to control it's operation. Design that, implement it, test it, and finally attach it to the program you already have, which you already know works.

Less scathingly it's referred to as a RAD system. (Rapid Application Development) This is strongly pushed by Borland with Delphi, Kylix and C++ Builder. KDE and QT are also, finally pushing this method of working for other platforms. But it is still thought of as "cutting corners", and fine for prototyping an idea... but you should then scrap all your "WinForms" or VCL code and start again, this time doing it properly.

My greatest problem with such systems, is that I can't see why they have to be so exclusive. You can use C++ Builder without VCL or even OWL in order to build C++ programs, you can use Visual C++ with MFC or ATL or neither... or you can "plug-in" STL, KDE, QL, GTK or wxWidgets, OpenGL, SDL, OSS etc to Microsoft, GNU, Borland, Digital Mars, Watcom or any other C++ compiler... but the dialect is considerably changed by the interfaces you have imported.

So porting C++ from ATL to MFC or from VCL to WinForms or wxWidgets is far more work than porting from Pascal to C++. (I'm not kidding, I've done both).

**This is DEFINATELY NOT a critic to anything that Vormav does.**

Quite right.

 

[SheenBR]

Re: PT writeField Function (adding field easy way with source code)

I didn't know you can use .net vc++ to build a unmanaged c++ code. Thats awesome. But I dont have a clue of how to do it. But thanks bob.

And again, what do you think of a pascal version of it?

 

[ChUs]

Re: PT writeField Function (adding field easy way with source code)

realmpt dll do same like this

 

[bobsobol]

Re: PT writeField Function (adding field easy way with source code)

And again, what do you think of a pascal version of it?

I think the idea is fine... but Pascal (like Basic) has never been standardised in terms of it's syntax. (there are a couple of ISO standards which changed so rapidly they where never seriously adhered to)

Spoiler

C, and C++ have ISO and ANSI standards, and most compilers can be passed switches to conform to one or the other of those, as well as any native syntax extensions (Microsoft have theirs, Borland their own, Watcom have some too, as does the GNU GCC Suite, for which Bloodshed Dev-CPP is just one of several IDEs). C and C++ also allow for the make script or "project" to set defines outside the code, so you can write code which looks up the CPU type, OS platform, which compiler make and version and what core libraries etc. the executable is going to be built from and for, and perform conditional compilation using #if pre-compiler statements. These are usually passed as parameters to either make or configure scripts during the build process, or as switches in the "target" options for your IDEs "project". There is no "standard" way to do that in Pascal, so where you can write C98 / C99 code and know it doesn't matter if it is being compiled for Windows, Mac, Linux, BSD, CP/M, iOS, Android etc. on GCC, MSVC, Borland Turbo C, DJGPP, Digital Mars, LCC, Watcom or what-ever.

Conversely, if you write Delphi 4.5 code it won't compile on Delphi 2006 let alone Free Pascal, GNU Pascal or Turbo Pascal. Just as VB6 code won't compile in VB.net or QuickBasic, PowerBasic, DarkBasic, BlitzBasic, YABasic, RealBasic, LibertyBasic or XBasic, and the same in reverse.

There are some fantastic Delphi 4.5 programs... but maintaining them and keeping them running on systems newer than Windows 3.x or Win95 is a real pig. It doesn't get any easier as you move on in version.

You must be registered to see links

is the closest I've seen to a "standard" Basic programming language. It has good compatibility with QBasic, PowerBasic or RealBasic (the core "standard" Basics) and some support for VB6 syntax, and it is based on the GCC Suite of developer tools for Assembly and linkage of executables, giving good cross-platform support. With one possible exception...

You must be registered to see links

.

For the exact same reasons, the clearest "standard" Pascal is

You must be registered to see links

(originally developed by Apple?) is the clearest "standard" Pascal... and you could use

You must be registered to see links

or

You must be registered to see links

(if you avoid the LCL which is it's major difference, and makes it more "Delphi" and "Event Driven") possibly in conjunction with the same Bloodshed IDE used here, only built as

You must be registered to see links

. I believe some parts of the Object Pascal standard are also implemented in

You must be registered to see links

, but I can't verify that.

Also... I'm not sure which compilers would support cdecl, stdcall & fastcall DLL exports. Which would be critical here, I think.

realmpt dll do same like this

Interesting... evidence?

 

[Vormav]

Re: PT writeField Function (adding field easy way with source code)

realmpt dll do same like this

Even if the have it... all they have is closed source (useless).
You can post that dll so I can compare it to my version.

This is not what realmpt have and what not have forum... this is MMORPG development forums.

realmpt fan boys are funny

PS. I never looked into realmpt files, not even once... I simply don't care about them.




@bobsobol
I have good naming idea for music, sky, ... , etc.
I will use "file name" and that will by my standard for naming, sever version is nearly finished too.

I will post everything when I find some more time.

@SheenBR
Pascal
There will be some mess on stack...

The reason you want it ported to other lang is because you are not good with C?

C was used to create PT so I think it was best choice.

 

[ChUs]

Re: PT writeField Function (adding field easy way with source code)

	//Acasia Forest
	pcAcasiaForest->SetFileName( "forest\\fore-3.ase", "fore-3" );
	pcAcasiaForest->SetType( MAPTYPE_Forest );
	pcAcasiaForest->SetSky( 2, 3, 1 );
	pcAcasiaForest->SetBackgroundMusicID( 4 );
	pcAcasiaForest->SetLevelRequirement( MAPLEVEL( MAPID_AcasiaForest ) );

	pcAcasiaForest->SetCenter( -16419, -7054 );

	pcAcasiaForest->AddSpawn( -10585, -11810 );
	pcAcasiaForest->AddSpawn( -13659, -9753 );

	pcAcasiaForest->AddTeleport1( -16638, -6737, 267, 64, 32, pcMushroomCave, 119112, 26028, 510, MAPLEVEL( MAPID_MushroomCave ) );
	pcAcasiaForest->AddBorder( pcBambooForest, -8508, -10576 );

	pcAcasiaForest->AddSound( -13819, 226, -8950, 100, 15 );

	pcAcasiaForest->AddStaticModel( "forest\\3ani-01.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-02.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-03.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-04.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-05.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-06.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-07.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-08.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-09.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-10.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-11.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-12.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-13.ASE" );
	pcAcasiaForest->AddStaticModel( "forest\\3ani-14.ASE" );

---------- Post added at 02:52 PM ---------- Previous post was at 02:36 PM ----------

C was used to create PT so I think it was best choice.

PT is in C++

 

[bobsobol]

Re: PT writeField Function (adding field easy way with source code)

The reason you want it ported to other lang is because you are not good with C?

C was used to create PT so I think it was best choice.

Agreed. As you know, the international DLLs I have written for Butchered are *not* C... simply because I know:-

• Assembler can do anything in any way you like.
• freeBASIC does support all the same APIs and interfaces (cdecl, stdcall, fastcall) that C does, but has a lot of extra string and array handling routines built into it's standard RTL that I can call on. Where I'd need to write, or find a class or library that will do that in C / C++.

But ultimately, I plan to have them all implemented in C... so I need to find or write those library routines.

Spoiler

I think STL or ATL have most of what I need, and are much smaller than the freeBASIC RTL. But when I started, I didn't know what I would need, just that it would be much more than standard C / C++ has. (without type libraries or frameworks of any kind added to it)

These frameworks essentially become extensions to the C language, and each have their own coding style. If I pick one, before I know what my ultimate requirements are, I can make a bad choice and have to port anyway. freeBASIC syntax is structurally very similar to C, so I don't think it's any harder to port from FB to C++ than it would be to have to port the C from one framework to another.

If I used Delphi... it's RTL is massive even compared to FB. If I used Object Pascal, I think it could have been equally small and fast, but that isn't as strong on the string manipulation. If I wrote in PHP that would be very easy on the file reading and string manipulation, but standard PHP doesn't support exporting cdecl, stdcall & fastcall functions built as a DLL. : Because PHP isn't designed to be compiled, it's meant to be a script language.

I can understand people wanting to use Pascal. I'm very lucky that FB is so adaptable, most Basic compilers aren't, and most Pascal compilers aren't... but I think Free Pascal may be. Many of it's aims are very similar to those of the FBC. (multi-platform, fits all jobs, does anything C can etc.)

 

[SheenBR]

Re: PT writeField Function (adding field easy way with source code)

    //Acasia Forest
    pcAcasiaForest->SetFileName( "forest\\fore-3.ase", "fore-3" );
    pcAcasiaForest->SetType( MAPTYPE_Forest );
    pcAcasiaForest->SetSky( 2, 3, 1 );
    pcAcasiaForest->SetBackgroundMusicID( 4 );
    pcAcasiaForest->SetLevelRequirement( MAPLEVEL( MAPID_AcasiaForest ) );

    pcAcasiaForest->SetCenter( -16419, -7054 );

    pcAcasiaForest->AddSpawn( -10585, -11810 );
    pcAcasiaForest->AddSpawn( -13659, -9753 );

    pcAcasiaForest->AddTeleport1( -16638, -6737, 267, 64, 32, pcMushroomCave, 119112, 26028, 510, MAPLEVEL( MAPID_MushroomCave ) );
    pcAcasiaForest->AddBorder( pcBambooForest, -8508, -10576 );

    pcAcasiaForest->AddSound( -13819, 226, -8950, 100, 15 );

    pcAcasiaForest->AddStaticModel( "forest\\3ani-01.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-02.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-03.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-04.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-05.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-06.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-07.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-08.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-09.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-10.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-11.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-12.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-13.ASE" );
    pcAcasiaForest->AddStaticModel( "forest\\3ani-14.ASE" );

interesting...

 

[Vormav]

Re: PT writeField Function (adding field easy way with source code)

@ChUs
Thats what I call trolling... you released some part of code which is useless alone and you never gonna release full code.
I guess realmpt is something like rpt, dll you are talking about is probably for devs of that PT only.

You saying "realmpt dll do same like this" and getting thx for it... I don't care about this 10Q system and thanks like that are probably reason.
OK so what? realmpt ppl have it to DL somewhere?
We are open community and we share ideas on this board.

Its probably sharp stick in the eye for you because open community have it too...

I don't know why you take part of this discussion if your only reason to post (Posts: 3 till now) is "we have it and we do it better than you bi**h!!11".


@bobsobol
I like to debug C code on assembly level and thats something that need to be done when code share info with .exe.

 

[SheenBR]

Re: PT writeField Function (adding field easy way with source code)

he should be some sandurr's witch. Ignore him vormav.

 

[ChUs]

Re: PT writeField Function (adding field easy way with source code)

#define TELEPORTTYPE_DIRECT		0
#define TELEPORTTYPE_WARP		1
#define TELEPORTTYPE_WARPGATE	2

#define MAX_TELEPORTINMAP		12

class BaseMap
{
private:
	struct Teleport
	{
		int				  iLevelReq;
		int				  iType;
		char			  szBuff[0xD8];
	}; //Size = 0xE0
	
public:
	//Attributes
	void				* pvVoid;
	char				  szStageFilePath[64];
	char				  szMiniMapFilePath[64];
	char				  szMiniMapNameFilePath[64];
	EMapType			  iMapType;
	ESkyID				  iSkyIDDay;
	ESkyID				  iSkyIDDawn;
	ESkyID				  iSkyIDNight;
	EBackgroundMusicID	  iBackgroundMusicID;
	BOOL				  bNightSpawn;

	//0xD8
#if defined(_GAME) //Size: 1344
	char				  szBuff0[0xC8];
	int					  iNumTeleport;
	char				  szBuff1[0xD8];
	Teleport			  saTeleport[MAX_TELEPORTINMAP];
	char				  szBuff2[0x578];
	int					  iLevelReq;
	char				  szBuff3[0x1A0];
#elif defined(_SERVER)
	char				  szBuff[0x0D80];
#endif

	EMapID		  iMapID;						//0x141C | 0x0E5C
	int			  iUnused;

#if defined(_GAME)
	char szpad[0x58];
#elif defined(_SERVER)
	char szpad[0x44];
#endif

	//Operations
	void		  SetFileName( char * pszStageFileName, char * pszMiniMapFileName );
	void		  SetLevelRequirement( int iLevel );
	void		  SetType( EMapType iType );
	void		  SetSky( ESkyID iDay, ESkyID iDawn, ESkyID iNight );
	void		  SetBackgroundMusicID( EBackgroundMusicID iID );
	void		  AddTeleport1( int iX, int iY, int iZ, int iWidth, int iHeight, BaseMap * pcBaseMap, int iDestinationX, int iDestinationY, int iDestinationZ, int iLevelRequirement, int iTeleportType = TELEPORTTYPE_DIRECT );
	void		  AddTeleport2( int iX, int iY, int iZ, int iWidth, int iHeight, BaseMap * pcBaseMap, int iDestinationX1, int iDestinationY1, int iDestinationZ1, int iDestinationX2, int iDestinationY2, int iDestinationZ2, int iLevelRequirement, int iTeleportType = TELEPORTTYPE_DIRECT );

	void		  AddTeleport( int iX, int iY, int iZ, int iWidth, int iHeight );
	void		  AddDestination( BaseMap * pcBaseMap, int iX, int iY, int iZ );
	void		  SetCenter( int iX, int iY );
	void		  AddSpawn( int iX, int iY );
	void		  AddStaticModel( char * pszModelFilePath, BOOL bHidden = FALSE ); //bHidden Not Sure
	void		  AddSound( int iX, int iY, int iZ, int iRadius, int iSoundID );
	void		  AddBorder( BaseMap * pcBorderMap, int iX, int iY, int iZ = 0 );
}; //Size Game = 0x147C, Server = 0x0EA8

void BaseMap::SetFileName( char * pszStageFileName, char * pszMiniMapFileName )
{
	if( pszStageFileName != NULL )
		StringCbPrintfA( szStageFilePath, _countof( szStageFilePath ), "field\\%s", pszStageFileName );

	if( pszMiniMapFileName != NULL )
	{
		StringCbPrintfA( szMiniMapFilePath, _countof( szMiniMapFilePath ), "field\\map\\%s.tga", pszMiniMapFileName );
		StringCbPrintfA( szMiniMapNameFilePath, _countof( szMiniMapNameFilePath ), "field\\title\\%st.tga", pszMiniMapFileName );
	}
}

void BaseMap::SetLevelRequirement( int iLevel )
{
	iLevelReq = iLevel;
}

void BaseMap::SetType( EMapType iType )
{
	iMapType = iType;
}

void BaseMap::SetSky( ESkyID iDay, ESkyID iDawn, ESkyID iNight )
{
	iSkyIDDay = iDay;
	iSkyIDDawn = iDawn;
	iSkyIDNight = iNight;
}

void BaseMap::SetBackgroundMusicID( EBackgroundMusicID iID )
{
	iBackgroundMusicID = iID;
}

void BaseMap::AddTeleport1( int iX, int iY, int iZ, int iWidth, int iHeight, BaseMap * pcBaseMap, int iDestinationX, int iDestinationY, int iDestinationZ, int iLevelRequirement, int iTeleportType )
{
	AddTeleport( iX, iY, iZ, iWidth, iHeight );
	AddDestination( pcBaseMap, iDestinationX, iDestinationY, iDestinationZ );

	saTeleport[iNumTeleport].iLevelReq = iLevelRequirement;
	saTeleport[iNumTeleport].iType = iTeleportType;
}

void BaseMap::AddTeleport2( int iX, int iY, int iZ, int iWidth, int iHeight, BaseMap * pcBaseMap, int iDestinationX1, int iDestinationY1, int iDestinationZ1, int iDestinationX2, int iDestinationY2, int iDestinationZ2, int iLevelRequirement, int iTeleportType )
{
	AddTeleport( iX, iY, iZ, iWidth, iHeight );
	AddDestination( pcBaseMap, iDestinationX1, iDestinationY1, iDestinationZ1 );
	AddDestination( pcBaseMap, iDestinationX2, iDestinationY2, iDestinationZ2 );

	saTeleport[iNumTeleport].iLevelReq = iLevelRequirement;
	saTeleport[iNumTeleport].iType = iTeleportType;
}

NAKED void BaseMap::AddTeleport( int iX, int iY, int iZ, int iWidth, int iHeight )
{
	JUMP( pfnAddTeleport );
}

NAKED void BaseMap::AddDestination( BaseMap * pcBaseMap, int iX, int iY, int iZ )
{
	JUMP( pfnAddDestination );
}

NAKED void BaseMap::SetCenter( int iX, int iY )
{
	JUMP( pfnSetCenter );
}

NAKED void BaseMap::AddSpawn( int iX, int iY )
{
	JUMP( pfnAddSpawn );
}

NAKED void BaseMap::AddStaticModel( char * pszModelFilePath, BOOL bHidden )
{
	JUMP( pfnAddStaticModel );
}

NAKED void BaseMap::AddSound( int iX, int iY, int iZ, int iRadius, int iSoundID )
{
	JUMP( pfnAddSound );
}

NAKED void BaseMap::AddBorder( BaseMap * pcBorderMap, int iX, int iY, int iZ )
{
	JUMP( pfnAddBorder );
}

tt1:

 

[SheenBR]

Re: PT writeField Function (adding field easy way with source code)

well, even for me that understands poop of C++, this piece of code seems pointless.

and, who are you? oO

 

[bobsobol]

Re: PT writeField Function (adding field easy way with source code)

@ChUs
Thats what I call trolling... you released some part of code which is useless alone and you never gonna release full code.
I guess realmpt is something like rpt, dll you are talking about is probably for devs of that PT only.

RealmPT is what most people know as rPT these days. It is largely the same team as the *old* rPT. (Renaissance) They have their own (somewhat more private) dev community in their own forums.

Basically coders give partial code on the forum, and Sandurr and co. take what they like and put it in rPT. Their premise is more along the lines that people post incomplete solutions and rPT will pay them for the rest. It's a developers market place rather than a communist sharing ground. The existence of "developer" forums like that confuse people when they come to RZ.

We don't want you to show us your incomplete work and sell us the rest. We give complete solutions for free, and if you don't want to give yours, we really don't want to know about them. tt1:

@bobsobol
I like to debug C code on assembly level and thats something that need to be done when code share info with .exe.

It shouldn't be necessary, but I do the same with my FB code. (GDB and Olly make awesome combo don't they.) XD

Also, to Sheen and ChUs:-
When Vormav says C, he means C and C++, but not C#.

Spoiler

The two languages are compatible. You can add ++ extensions in source alone to a C compiler (it doesn't work as well as a native C++ compiler, but can be done) you can write pure C in a C++ compiler without using any C++ extensions. (that works fine) What's difficult, is writing ANSI, ISO and Microsoft compatible C / C++. Because they use the same terms with different syntax. : (and Borland do too, but it's not as uncommon to turn the ANSI or ISO switch on on a BCB project)