Re: PT writeField Function (adding field easy way with source code)
Sandurr writes 99,99999% of the rPT game code himself. There is no dev team in rPT, there's only sandurr. they don't buy code stuff from ragezone people, lol..
And now he lets me put some useful code stuff here and you all get so rude it's weird
They don't buy RZ devs stuff, because we don't sell it. We give it away free.
I can assure you rPT does use stuff that is developed in forums like RZ and MIB. But, being rPT / uPT they do it their own way. And that's fine, we don't say "You must not adapt this, it's MINE!!!!" and that's a lot of why we are different.
I have defiantly seen people posting incomplete code and artwork on the rPT forums... I have assumed that they are hoping Sandurr will buy their work. Maybe I'm wrong and they just like to sit in there and brag. IDK. What they definitely don't do is actually share unconditionally, the way Vormav has.
Sandurr writes 99,99999% of the rPT game code himself. There is no dev team in rPT, there's only sandurr. they don't buy code stuff from ragezone people, lol..
And now he lets me put some useful code stuff here and you all get so rude it's weird
I can believe he is writing for himself only, when I write code for someone (like this code here) I add as many possible comments so others will be able to understand and develop new fields using it. This sandurr "part of code" is just pale... and because I don't see whole I can't tell if its better than thing I wrote (my goal is to make it 100% PT compatible).
You trying to say that when I created this code you decided to put "part" of code "that do similar thing" to be useful... Now you're either being sarcastic or extremely stupid.
My wild guess is that you where trying to sell that code and now you are playing stupid, as bobsobol said:
We give complete solutions for free, and if you don't want to give yours, we really don't want to know about them.
I am going to rewrite my 1st post, I added:
teleportLVL, fieldLVL and enums for Sounds, Music and FieldTypes ofc >=P
I changed teleportToField function to teleportTO (its shorter now ).
Because I wrote it very quick I am not happy with it.
I will make tutorial part bigger (covering all) and move it to tutorials sub forum.
Whats worry me is that LVLs of files and object like teleport "space" are client sided, also untested (need to document that too) skillsBlock is client sided too :/
I think when I finish server version I will edit it a bit and inject it to official ePT server too see if it work same.
PS. @SheenBR I don't think its time to rewrite it to any of you fav languages yet, I might get crazy and butcher code
Re: PT writeField Function (adding field easy way with source code)
lol. I think Sheen is interested to know if he really has to go down the road of learning that crappy old C / C++ thing that nobody uses any more.
*sniff* *sniff* Is that coffee :blink:
Pascal is older that C++. C# tries to follow C++ syntax, as do most modern versions of Pascal, Basic and Fortran. Why? Because every programmer needs to understand C syntax to understand API specs for just about any current OS.
There are very few that aren't written primarily in C(++). Yes, most Mac OS APIs are documented in Objective C, most Win32 APIs are documented in C++ and Linux ones are typically traditional C... the commonality of all of these is C. You don't get C++ or Objective C without C underneath. Sadly, the same does not remain true for C#.
Interestingly, many modern Basic, Fortran and Pascal compilers either start life, or move on to compiling to C as a preprocessor, and then compiling that to machine code to link with the OS.
News flash. What do you think the .Net framework which JIT compiles MSIL (the dotNet Intermediate Language) is written in? Oh look! It's C++. -.-
Now... I love machine code. I love the simplicity of the instructions and the strict Operator [Operand[[,Operand],Operand]]]] syntax, and the fact that if you can't do it in Assembler, then it is physically impossible for the machine to do it. There are no limits, nothing is "out of scope", nothing is beyond your reach. (with the possible exception of the Kernel and "privileged" instructions... so write your own OStt1 But if you need something higher, you need to learn C. You can learn C++, but if you learn it as C++ you learn C as you go. If you learn C, as I did, the ++ extensions can be a pain in the backside, but you do need to learn C.
We where asked if learning Java would help develop PT... you can use Java. Anything I have released that I wrote in AutoIt could just as easily have been written in Java, or Perl, or Python, or C#, or VB.net... but if you want to hit the EXEs... you need to know your C. It helps to know Assembler, but that doesn't get you very far unless you know how a C compiler produces it. If you only know C... the assembler will come.
@Vormav: I must admit, I switched to using Eclipse or Notepad ++ with MinGW GCC... so I've not had a chance to look through the code yet. (need to put Bloodshed back on the dev VM)
Question about Map sounds. I can see "Music", and wonder if we can add new .BGM files to go with new maps. But also, I always turn the music off, in all games... each field has a different background sound as well as music. (you can't really hear it with the music going)
Is that supported?
Also. The plans to guide it fully in the Tutorials section, and give a rough outline here. (basic APIs etc) sounds like a good one.
Tip: Reserve some posts at the top of your guide to break chapters down. Easiest way is to put so many emoticons (smilies) into the last post that the next one is forced to be new, and not get merged. You can strip the emos out after the posts are reserved. Write it up in WordPad or something first, so you have an idea of how many sections you'd like.
@Vormav: I must admit, I switched to using Eclipse or Notepad ++ with MinGW GCC... so I've not had a chance to look through the code yet. (need to put Bloodshed back on the dev VM)
Question about Map sounds. I can see "Music", and wonder if we can add new .BGM files to go with new maps. But also, I always turn the music off, in all games... each field has a different background sound as well as music. (you can't really hear it with the music going)
and offset should lead to:
wav\bgm\your_new_music.bgm
and same thing with sounds.
I can move it to source code but that will lead to adding another offset and make harder and harder for peoples that know a lot about 3D but nearly nothing about C.
BTW do you have wav\bgm\wind loop.bgm? I don't have it in my PT and its my bgm number 3 :/
Tip: Reserve some posts at the top of your guide to break chapters down. Easiest way is to put so many emoticons (smilies) into the last post that the next one is forced to be new, and not get merged. You can strip the emos out after the posts are reserved. Write it up in WordPad or something first, so you have an idea of how many sections you'd like.
//----- (new field) ------------------------------------------------------------
and similar separators.
But writing in wordpad or emacs is good idea. The reason it was so chaotic was because I had no time to release it before and I did not wanted to deley it any longer.
Remember that Dev-C++ creates C:/Dev-Cpp structure. (one reason I stopped using it)
So in MinWG:-
Code:
Administrator@mingw ~
$ cd writeField/
Administrator@mingw ~/writeField
$ ls
Makefile.win libwriteField.def writeField.dev writeField.layout
libwriteField.a writeField.c writeField.dll writeField.o
Administrator@mingw ~/writeField
$ make Makefile.win all
make: Nothing to be done for `Makefile.win'.
make: *** No rule to make target `all'. Stop.
Again, 2 enumerations in the same enum block can't have the same name... even if they relate to the same thing.
--- EDIT2 ---
I have successfully built under MSVC 6 - 10, and even using NMake (Microsoft C++ v6).
NMake and Microsoft C++ (the engine behind Visual C++) comes on the Windows SDK install CDs. (usually) Allowing you to build C++ without the IDE, in a more traditional manner. The configure.cmd file just creates a "make.cmd" with appropriate build target, so just like any GNU ./configure make.
You can get Projects, Solutions and NMake file with configure.cmd >
To view the content, you need to sign in or register
< and simply add them to the fieldWrite folder. Use only the folder which relates to your version of the compiler.
Ignore the many warnings that Vormav hasn't included function prototypes for each of his functions (yet). I tried making some in a header, but the warnings then became errors... there are some type mis-matches that need to be ironed out.
Not a typo
Stage_Play1.bgm is 7 and 8 (two same offsets to same file),
Stage_Play2.bgm does not exist, maybe it was created in beta tests for different music in rounds 4-6.
Again not typo, same as before there are two in table,
I don't get any errors when I compile it, I am not sure how enum works but I think It will put 2nd parameter when defined 2nd time.
I can't find anything about it in C standards, maybe you have some info?
--- EDIT2 ---
I have successfully built under MSVC 6 - 10, and even using NMake Microsoft C++ v6.
You can get Projects, Solutions and NMake file with configure.cmd
To view the content, you need to sign in or register
and simply add them to the fieldWrite folder. Use only the folder which relates to your version of the compiler.
Ignore the many warnings that Vormav hasn't included function prototypes for each of his functions (yet). I tried making some in a header, but the warnings then became errors... there are some type mis-matches that need to be ironed out.
is not valid code, because the compiler has no idea if a Brown Bear is 1 or 4.
The compiler can treat it like:-
Code:
#define Brown 1
#define Brown 4
Thus meaning that it is 4 after the re-definition and 1 before it... but shouldn't allow that without at least a compiler warning. Especially as it would make the first "Brown" of "Bear" pointless to include, since you can't redifine an enumeration set of the same name later in the code. (unless you go C++, and are working in a totally different namespace)
Such code is very ambiguous. Even if it's not outright illegal.
Well, if you knew Pascal, you would find that it would absolutely refuse to compile if you hadn't included a valid function prototype before trying to use the function. It's preprocessor wouldn't know how to interpret your main code... and neither would the Borland Turbo C++ 2.6 I learned C with at school. XD
I seem to remember being told that this was specifically enforced in Pascal, because of the mess C programmers who came from Basic or COBOL background tended to make.
Most Basic compilers get away with it by performing multiple passes, but you can usually reduce the compile time on a large project considerably by officially declaring all prototypes before they are used... rather like the common "Option Explicit" setting, stating that you willDIM any variable before attempting to use it. So the preprocessor needed "skim" through the code and allocate space for any variables used in it before actually compiling the code... it can know from the DIMs at the top.
When you give the correct prototypes it then errors out because what you are passing in the main code is typed differently. (of a different data type) "char * to int *" is one of them... this isn't really allowed, and it's kinda tricky to guess what the preprocessor may have made of that...
I know it's warnings say it is assuming the function takes void parameters and returns an int. Which is pretty much how an assembler would see every function anyway... up until the point it starts getting values off the stack. And anything returned becomes either a direct int or an int address which points to something else.
An Any Ptr in freeBASIC. XD
I doubt there is much to do to make it cast types correctly, and it's worth knowing that that type casting is happening when you read the code anyway.
When I looked at the code, everything after #include <windows.h> and before //----- (writeField) should (according to the way I was taught) be in writeField.h, which should be inserted via #include "writeField.h" just below #include <windows.h>. But this is by tradition, and for legibility, not as a requirement of any C / C++ compiler. (like indenting each time you open a new selection or iteration logic.
Putting function prototypes in there is also common practice, I believe. And the reason why partial code listings are pretty flipping useless. You can't just blunder around guessing what might be in the headers, how classes are defined, how their public interfaces are implemented etc. You need the full project.
PS. I've seen the tutorial (both of them, XD) and it look good. (I presume one will be deleted now the other is sorted out.)
Thus meaning that it is 4 after the re-definition and 1 before it... but shouldn't allow that without at least a compiler warning. Especially as it would make the first "Brown" of "Bear" pointless to include, since you can't redifine an enumeration set of the same name later in the code. (unless you go C++, and are working in a totally different namespace)
Such code is very ambiguous. Even if it's not outright illegal. Well, if you knew Pascal, you would find that it would absolutely refuse to compile if you hadn't included a valid function prototype before trying to use the function. It's preprocessor wouldn't know how to interpret your main code... and neither would the Borland Turbo C++ 2.6 I learned C with at school. XD
I can do this:
field((int)fore_3, "forest\\fore-3.ase", (int)"fore-3");
and that will fix warnings... but thats a bit annoying for person who is writing new function... more "strange things"... remember that I wrote it for non programmers.
or this:
signed int field(char *this, LPCSTR filePath, char *shortName);
but last time (when I started writing this) this gave me errors in PT itself... so I will check it later.
If I write prototype of function above my main code its same as if I would add whole code above... same result.
I can understand prototyping when you have function that use function that is belove and above and one and function that is belove use function that is above... but prototyping "could" be done by compiler.
I need to start thinking if there is any #pragma that will disable this when I do prototypes. I need code that is easy to understand and working at same time.
Don't get me wrong I use prototypes in C++ (I have not choice )
but using something illegal sometimes lead to interesting results in C.
When I looked at the code, everything after #include <windows.h> and before //----- (writeField) should (according to the way I was taught) be in writeField.h, which should be inserted via #include "writeField.h" just below #include <windows.h>. But this is by tradition, and for legibility, not as a requirement of any C / C++ compiler. (like indenting each time you open a new selection or iteration logic.
I understand it completely, its bugging me to... but other peoples might get lost with just one .h file
I trying to make it even more simpler but when code will get bigger I will have to do it anyway.
"Because something is allowed it does not mean that you should do it." Right?
Putting function prototypes in there is also common practice, I believe. And the reason why partial code listings are pretty flipping useless. You can't just blunder around guessing what might be in the headers, how classes are defined, how their public interfaces are implemented etc. You need the full project.
I think I deleted it few minutes after... maybe its visible for some users for longer time >=P
As for tutorial itself I will develop it more and more... 'till I cover everything
__________________________________________________________________________
Do you or anyone here know name of music that is played when babel spawns?
I would like to get deeper into "-1" bgmType. Its working like it should but I was thinking about some control over it.
-1 //Playing music when SoD 2 starts or Babel spawns
And where X Y of babel spawn is stored? (hes always spawn at same place)
__________________________________________________________________________
---EDIT---
Here are correct prototypes:
Code:
signed int field(char *this, LPCSTR filePath, char *shortName);
int animation(char *this, char *filePath, int bones);
signed int fieldCmd(char *this, int X, int Z);
signed int respawn(char *this, int X, int Z);
int teleport(char *this, int X, int Z, int Y, int length, int width, int teleportLVL, int teleportType);
int teleportTo(char *this, char *field, int X, int Z, int Y);
signed int fieldLoad(char *this, char *field, int X, int Z, int Y);
signed int subFieldLoad(char *this, int field, int X, int Z, int Y);
int sound(char *this, int X, int Y, int Z, int range, int soundType);
signed int environment(char *this, int fieldType, int daySky, int eveningSky, int nightSky, int bgmType, int mobSpawnTime, int fieldLVL, int skillsBlock);
int miniGame(char *this, int a1, int screenUpDown, int zoomInOut, int moveStart, int moveEnd);
ofc you need to change functions on bottom too.
Remember that I have this variable... you can change them into vthis or something else in C++ or put those functions into classes and use this as "this" parameter in __thiscall functions.
Anyway GL with it because I don't have time tomorrow to play with this >=P
If you are happy with it than this will make into next release.
--EDIT--2--
I fixed all warnings and I will move "everything after #include <windows.h> and before //----- (writeField)" to header...
"this" variable can be now thisField variable.
...any more suggestions for new version?
Okay... well I'm going to post this up real quick, as I've not been able to sleep and got stuff to do today. :
It contains the changes you mentioned in your last post (a .h file and prototypes) and updated project files that I've tested utterly to exhaustion on every freaking MS VC IDE from 6 - 10 and the MS NMake file, and a new Pelles C project (basically an IDE and headers for LLC) which falls over because there are too many warnings.
Aside from that last one, and the fact that my copy of MS VC 2005 Express is throwing one at my SDK libs again and says there is no such function in Windows as wsprintf()... ? ... >.< every single compiler, including Dev C++ is now winging about 7 different assignments without explicit type conversion... usually connected with V0 (being "signed int") and it's association with char *this.
I tried working it the other way, which of course breaks it's association with int field of subFieldLoad(). My guess is that that should be &V0 that is passed to int field, not V0, but that depends rather on how the C compiler interprets the conversion from char * to signed int, which isn't defined in the standard... hence the warning.
Anyway... we're getting there, and people have a lot of compilers they can choose from with very little difference (some size, and executable arrangement, not much else) between them.
I've stripped the binaries, and no matter what compiler or IDE you use you should get debug builds in /bin/Debug and release builds in /bin/Release. What you get in the way of .pdbs, .gdbs, .maps, .pchs and so on is rather down to the compiler, whether they make sense to exist in that environment and are supported by even the *free beer* versions. (I don't want to hand any poor sod a project file that will only build with the "Enterprise Developer" version of a compiler)
>>
To view the content, you need to sign in or register
<<
Anyway. It all looks pretty good for portability. Pelles is wining about conversion from unsigned char * to char *... which is pretty flipping pedantic if you ask me. I do note some CHAR * instead of char *, (don't know if that's deliberate) and I know Windows.h defines CHAR , and UCHAR, (I think) BYTE and UBYTE, for dis-ambiguity. So I wouldn't be surprised if Mr. Pellé got the header a little bit off from the Microsoft norm.
Oh... and your desire to keep duplicate names in the bmgType enumeration without it causing problems on non GNU compilers I fixed that like this:-
For your consideration. It may be that it should be a #ifndef _MSC_VER instead, if it's only MS that gets upset with it. But I still feel there's an element of potential confusion on the part of the dumb humans trying to read the code.
Because it is more logical to me I wrote the fieldType enumeration:-
That way you can see a logical, linear progression, not a bunch of random numbers that make you think "Why did he pick those? Did he just make them up?"
I sow in your BobMake project that you add variables to writeField function XD. It don't take parameters so I guess you did that by mistake.
As for type casting I fixed all warnings, its too big to post all changes, but don't worry I will make V3 tomorrow. I will not use #ifdef I decided to comment out that and add additional comments (just for record).
CHAR was intended 8-bit with windows ANSI character but I don't get your wsprintf() problem? Its actually wsprintfA() (ANSI).
Also don't worry about subFieldLoad(), it should work fine now.
Your fieldType numbers rename is a grate idea, I know what it is but I wrote this so other will know too (at lest I am trying with your help ), this time almost all changes went to project, thank you.
I think SKY types names will make to V3.
I need some help with it.
Do you... any of you (why other pplz are so shy? Maybe this project is not so good :/)... think that I should do:
I think there is a commonality between skys, Desert Sky, Cold Sky, Industrial Sky, Forest Sky etc. Day or night.
You are free to mix and match, but descriptive names like that (and comment the skybox file name associated) would be very helpful I think.
황무지낮 = Wilderness daytime
황무지저녁 = Wilderness in the evening
황무지밤 = Wilderness at night
숲낮 = Forest daytime
숲저녁 = Forest in the evening
숲밤 = Forest at night
비오는하늘 = Rainy sky
사막낮 = Desert daytime
사막저녁 = Desert in the evening
사막밤 = Desert at night
모라숲 = In the forest
모라숲저녁 = In the forest in the evening
모라숲밤 = In the forest at night
아이언낮 = Iron daytime
아이언저녁 = Iron in the evening
아이언밤 = Iron at night
소드천공낮 = Sword sky daytime
소드달밤 = Sword moonlight night
소드검정 = So black
아이언보스하늘 = Iron Boss sky
Opneing 하늘 = Opening sky
아이스낮 = Ice Daytime
아이스저녁 = Ice in the evening
아이스밤 = Ice at night
남이섬낮 = South Island daytime
남이섬저녁 = South Island in the evening
남이섬밤 = South Island at night
로스트낮 = Lost daytime
로스트저녁 = Lost in the evening
로스트템플 = Lost temple
As for type casting I fixed all warnings, its too big to post all changes, but don't worry I will make V3 tomorrow. I will not use #ifdef I decided to comment out that and add additional comments (just for record).
That sounds like great news... and so long as you only work on the existing C and H files the projects should continue to work for different IDEs / compilers.
C is case sensitive, so CHAR could be, or might not be, different from char... if you see what I mean. If it's defined in Windows.h, (and I believe it is) Pellé uses his own open source version, with no .lib dependencies. char is part of the C standard, but CHAR is Windows specific, so he may have implemented CHAR differently to how the MS SDK does. If you see what I mean.
The wsprintf() thing, that's just a common problem with the Express edition of Visual C++ 2005. (VC8) They left out most of the important SDK headers and includes (inc & lib folders content) "to reduce download size" but that makes it pretty useless... getting it pointed to a download of the full SDK (which you need to make it really useful) is quite tricky, and a question asked many times, with many different answers.
I thought I had it cracked... but that was before I installed VS 2010 Express... now it's confused again. XD
Can I "big up" MS to counter my pro "all things non-MS"?
I have to run BC 3, 4.5, 5, and 6 in separate VMs, as they are "almost" impossible to make them run side-by-side on the same OS without destroying each other in key ways.
Microsoft strong points are core OS and Development tools. (What brought Bill to IBMs attention was his success with Microsoft Basic A. UI design and Productivity Suites... usually not so hot. But if they make the odd mistake with their Visual Studio or OS releases (WinME *shudders*) I can forgive that.
Your fieldType numbers rename is a grate idea, I know what it is but I wrote this so other will know too (at lest I am trying with your help ), this time almost all changes went to project, thank you.
Yea... you could add the decimal value as a comment I guess, for people who don't "get" hex, but it's just one of those things that makes more sense if you look at it that way.
P.S. Any idea what happened to 0x700? Is that something else they wanted to try and decided against, do you think?
--- EDIT ---
For the information of others who may be wanting to use VC 2005 Express (and it does have one of the nicest IDE layouts of all the Visual Studio versions IMHO), I re-corrected my setup following
To view the content, you need to sign in or register
and everything is working fine again. writeField.dll does build correctly with the project file I list, provided you point VC 2005 Express to a separate SDK install directory as per that guide. (just re-check it if you add, or update to Visual Studio products )
I have "converted" it to Microsoft Visual Studio C++ 2010. It is 100% working now. The only thing that changed, besides the code ofc, is how it looks like in OD.
@Sheen: How it looks in Olly changes for every different C compiler, MSVC or otherwise. Each new release changes the optimisation methods and low level generation considerably.
@Vormav: I haven't dared set the switch to "compile for C" yet, because I have heard that MSVC is more C compliant in C++ compilation mode than it is in C mode... as if C becomes "strict MS C" rather than simply "no C++ extensions".
Of course, I'm going to get V3 and see how all the other project files work with it. ^_^
Oh yea... when translating any language, don't pass more than one sentence at a time... and if there is no "." (full stop / period) then sent 1 line at a time.
With Han style scripts...
Hangul / Hanja in Korea, Kanji or Kana in Japan, Jiantizi / Fantizi (Pinyin) in China. "Fantizi" is probably the reason for the "GlobalFantasy" section, since Faintizi (Traditional Chinese) is "forbidden" in the Peoples Republic, but still very popular in many Chinese areas; some with disputed governance
... there may be no punctuation or even correct reading order (Chinese is BiDi, and frequently top-down before left to right, or right to left) it's hard to make rules for an automatic translator to follow. A "person" would try one way, and if that didn't make sense try the other... and we can do that so fast we don't realise we did it. To the computer program... nothing we say makes any "sense" anyway.
If you can find the right "word separation" (easier with Japanese, who have picked up and taken to "punctuation" and spacing from Westerners, and Korean where spacing is common, if not traditional) then you will get better results.
If Arabic numbers are used in such scripts... remove them first. The translator will get native numbers 〇, 一, 二, 三, 四, 五 etc. in Chinese or Japanese, 영/공, 일, 이, 삼, 사, 오 etc. (usually) in Korean. But the switch (which people manage without difficulty) between one language for words and another for numbers is much more difficult for the machine.
Imagine, we all use Latin words, but don't usually write numbers in Latin. I, II, III, IV, V etc. Westerners all alike switched to the more accurate Arabic form.
which has a zero, and I note the Chinese and Japanese "zero" is almost the same as the Arabic too. The Koreans use the "word", "nothing" or "none", or the second form (which we see as the command for an "air drop") is quite literally "nil".
).
tt1
:
