Also of note: None of the projects or solutions include the "writeGlobalField.c" file... however, it is included via the source code it's self. Confusingly (for me) part way down the file, so it's not instantly obvious.
Maybe putting writeGlobalField.c and writeGlobalField.h in folder EDIT_THIS_TO_ADD_MAP would be more obvious?
I had to do it some way in order to get: edit one file and get version for server and client, so ppl don't have to copy code from client to server and vice versa. Most of people should be interested in writeGlobalField.c and writeGlobalField.h (also writeClientField.dev and writeServerField.dev) only
for adding maps and compiling code. It might not be so obvious but I pointed it out in tutorial few times and till now I don't have any questions (which means that it is either obvious or no one uses this code...)
Would be cool but only script used by map (that I know) is "Water Wave", I know how to do water animation (name your material "water:" or "orgwater:" there are more like wind:, ice:, nopass:... etc. etc.) but I did not test how to add wave to it yet. PT is not good with 3DS transformations and mesh animations so it comes with those presets.
I guess that would be cool idea for version 3.0.0, for version 2.0.0 maybe I should add all sounds and music to code, I am not sure where sky have its table... can't find it so I was doing it blindfolded :/ (help find sky table? anyone? T_T)
Anyway adding it to code is equal to "you will be able to add your own music, sky and sound".
Adding particle effects to map is ofc not impossible but I will have to write something opposite to my writeClientField... and this would be readClientField.
I wondered if we could remove the actual beginning and ending of weather events to the DLL, so we could add other custom events, like electrical storms and sandstorms. (I know I have seen sandstorms in Refuge of the Ancients and Lost Castle in one of the older [post AOR pre-Pay2Play] clients)
Maybe putting writeGlobalField.c and writeGlobalField.h in folder EDIT_THIS_TO_ADD_MAP would be more obvious?
I had to do it some way in order to get: edit one file and get version for server and client, so ppl don't have to copy code from client to server and vice versa. Most of people should be interested in writeGlobalField.c and writeGlobalField.h (also writeClientField.dev and writeServerField.dev) only
for adding maps and compiling code. It might not be so obvious but I pointed it out in tutorial few times and till now I don't have any questions (which means that it is either obvious or no one uses this code...)
Would be cool but only script used by map (that I know) is "Water Wave", I know how to do water animation (name your material "water:" or "orgwater:" there are more like wind:, ice:, nopass:... etc. etc.) but I did not test how to add wave to it yet. PT is not good with 3DS transformations and mesh animations so it comes with those presets.
I guess that would be cool idea for version 3.0.0, for version 2.0.0 maybe I should add all sounds and music to code, I am not sure where sky have its table... can't find it so I was doing it blindfolded :/ (help find sky table? anyone? T_T)
Anyway adding it to code is equal to "you will be able to add your own music, sky and sound".
Adding particle effects to map is ofc not impossible but I will have to write something opposite to my writeClientField... and this would be readClientField.
As long as electric storm =/= prs DL skill, I think its cool idea
Just when said script, I was referring to
snow effects and meteors , through them to create more effects.
Thought that could be easy, do a code in C + + where
own dll, find the directory \ Effect \ Particle \ Script
search for the name, and executes the script.
Just when said script, I was referring to
snow effects and meteors , through them to create more effects.
Thought that could be easy, do a code in C + + where
own dll, find the directory \ Effect \ Particle \ Script
search for the name, and executes the script.
Existing precipitation (snow, meteors etc.) is controlled by the sky type. Yes.
There should have been a separate Ricarten skybox "type" which used to "rain". The effects of precipitation for "rain" and "snow" are actually a full screen overlay that just runs down over the game screen, opening credits are often overlaid on to a TV show, but "meteors" are something different, and unlike the original "effects\partical\script" scripts their partials are a) 3D objects, not a 2D overlay and b) connect with the ground in an explosion.
However, the "fields" I'm looking at and trying to understand are actually not covered by this, as they are not "game world" "fields", they are the intro and character selection maps / "fields".
They work in much the same way, but the intro sequence has "Meteors" in a map based on Ricarten, and the character selection definitely has 6 persistent particle generators applied by game.exe to positions which remain fixed to the base-point of the map mesh (field).
Having played with those particle generators, I know I could use that in the game it's self to make fish jump out of the water like spawning salmon or leaves fall from trees in "Forever Fall" and all sorts of other things.
Unfortunately, the character selection is the only place I know this happens. And I know it is unrelated to the 3DS Max work, (which I'm very bad at anyway) or the world-placement code implemented (or re-implemented) in writeGlobalFields.
@Vormav: I already have plans to extend my last attempt to replace the sound generation code in the game with DLL calls to a sound library... and seeing the success of this project, I will write it in C this time, rather than Assembler. If I simply break out of the points where sound is started and stopped to a DLL written in C, then I can make "alternate" libraries which can use one of several well known audio libraries. All of which give better performance and control.
In what way can I find these addresses in OllyDbg?
//----- Client offsets
int filedSkillsBlockLocationOffset = 1420;
int fieldNumberZeroLocationOffset = 5148;
int fieldOffset = 5244;
Ok, for some reason
my executable, of error,
but the server works perfectly.
Could release an executable for my study?
already did download the exe provided by Vormav,
But he is also the runtime error.
In what way can I find these addresses in OllyDbg?
//----- Client offsets
int filedSkillsBlockLocationOffset = 1420;
int fieldNumberZeroLocationOffset = 5148;
int fieldOffset = 5244;
Qualification on this... hadn't the opportunity to look at source in original answer.
int fieldOffset = 5244;
00432E27 |. |ADD EAX,147C
Same code, size of field record in game memory.
int filedSkillsBlockLocationOffset = 1420;
int fieldNumberZeroLocationOffset = 5148;
These are to ease moving through the record. 1420 bytes into a field record the SkillsBlock information is recorded. 5148 bytes into a field record the ZeroLocation is recorded.
Ok, for some reason
my executable, of error,
but the server works perfectly.
Could release an executable for my study?
already did download the exe provided by Vormav,
But he is also the runtime error.
If it doesn't work with Vormavs executables then it's built wrong and you have a bugged DLL. We need to know more about what you have changed, and how you built your DLL to help you. But I can assure you that switching executables from Vormavs won't help. (unless you built with OpenWatcom, and need to change the import name from writeClientField to _writeClientField.)
Also check dependencies.
To view the content, you need to sign in or register
is a good place to start. Most builds are dependent only on KERNEL32.dll and USER32.dll, but unfortunately any GNU Win32 build will be dependent on msvcrt.dll in order to get some help in for making the Win32 environment more C / POSIX compliant. This DLL is part of every Windows install from Windows 95 to Windows 7, so if you are missing it you have a major hole in your OS... but you may well not notice it if you primarily use commercial software from Microsoft / Adobe/ Corel / McAfee / Norton etc. because all of these developers have updated their dependencies to msvcrtxx.dll files (where "xx" is 70, 71, 80, 90 etc depending on the version of MS Visual C that built the file) for Visual C compilers newer than MSVC6.
My builds try to link such libraries into the DLL, which makes the DLL bigger, but reduces dependencies, dependency conflicts (aka "DllHell") and actual "in memory" usage of game.exe process as a whole. (since you only include the C Runtime routines you actually need, and not the entire set as an external DLL).
Is this the right way to do it? That depends on what you are working on, and personal opinion.
The general "rule of thumb" is that
if you are producing a large application (Office productivity suite / Internet Security suite) you should link to the external DLLs for runtime inclusion from each component of your project.
Reducing the overall size of your distribution and redundancy in multiple executables and DLLs containing the same routines included over and over again for each project in the entire solution.
if you are writing a single executable product, especially if it should be easily portable, you should link the .lib at compile time.
Reducing the number of dependencies and probability of "DllHell" and the working virtual memory model of the project as a whole. But *only* if the whole project is a simple, single DLL / EXE file per machine.
The argument against option B, even in simple programs, is that including custom compile time linked versions of standard library code may reduce the Virtual Memory allocation of your application, but increases the overall load on the OS if a user runs many such small applications at once.
The reason for this is that importing a DLL into any program (DLL or EXE) at runtime will map any existing copy of that DLL (loaded by another active program / background task) Virtually, without allocating any more of the global system memory.
Microsoft will argue this case, and I would like to agree with them without reservation. However, they degrade their argument by ensuring that a VC7 program can't use the same DLL as a VC7.1 program... so if you (as a user) run multiple small applications are built using even slightly different versions of the same C compiler, you will be filling the OS space with many variants of the entire C runtime library anyway. :
So basically, their principals are right, but they (one division of the company as a whole) have made the practicality of the proposition much less clear-cut. And from their writings, blogs and MSDN articles, I believe they are aware of this. The legacy they have unwittingly created is not easy to correct retrograde, and I sympathise with their situation.
The only thing I can think that they could do to ease the problem now would be to update the aged msvcrt.dll with all the fixes and improvements of each of the later versions... replace those later versions with "dummy" dlls that do little more than link back to the main msvcrt, giving a special "compatibility" tag to suggest what version of the library it should emulate in this particular application.
It's not an easy task at all, and only Microsoft themselves could possibly achieve it. And it's also no without it's own problems, since the double DLL situation would add a little global overhead too, which would be bad if you only ever used programs built with one version of a Microsoft compiler, but would ease the global system burden considerably if (as most people do) you use programs from a wide number of sources.
All of which "users don't care about", (even if they should) but "developers" (which you are now joining) "should care about more than they do". Why? Because it gives System Administrators (the area I am actually most commonly employed in) massive headaches.
The reason most developers "don't care enough" is because sadly "users" who don't know and don't care, have far more say in what software products are purchased both at home and in businesses, and take little notice of the advice they pay "system administrators" to give them... and often ask that advise "too late" in the process. (usually after they have already agreed to a bulk license purchase)
Asside: Real life example of this. I was "told" (not asked) that my organisation had purchased a cheap crappy web based CRM system which they wanted implemented in the organisations global intranet, and then asked what the implications would be.
"Well, the product you have just purchased requires an Apache web server when you have already decided to standardise all your intranet infrastructure on IIS. So the implications are that you either buy me a new server, make the intranet infrastructure incredibly slow and flaky by running two separate web servers on the same hardware and on different ports forcing all your users to make use some very strange URLs (or invest in sub-domain technology that can work sub-domains on different ports, not different servers) or you sacrifice all your existing intranet products organisation wide and we switch from IIS to Apache. I can see no other solution which will make this work."
At the time, as this was before ASP.net or mod.aspdotnet and all the many other technologies which are available now which may have made this more practical, I could see not other way of making it work.
"None of these options are acceptable. You will implement this new software on our existing IIS server without Appache despite the vendors statement that it is an absolute requirement and you will do so without any further financial support for the implementation."
And I did, (sort of, but I did have to install Apache which is financially free anyway) and the intranet became as flaky as I predicted. I forced all intranet traffic via a proxy server which decoded the virtual directories either to the port IIS was running on or the one Apache was running on. Since I soon discovered that they hardly ever used this new product I turned off the Apache server whenever I could see that it was not being actively used to avoid the numerous complaints that "the intranet has become very slow and often times out". XD Yea, that's because the server isn't big enough to run two web servers simultaneously and is spending all it's time rattling away on the swap file as it switched between IIS and Apache. :
Ok, for some reason
my executable, of error,
but the server works perfectly.
Could release an executable for my study?
already did download the exe provided by Vormav,
But he is also the runtime error.
Because bobsobol explanation might be a bit hard for google translator and you asked about some other offsets, you should edit only those:
writeClientField.h
Code:
//----- These addresses change with each version of Priston Tale
LPSTR fieldField = (LPSTR)0x007AF118;
LPSTR fieldMap = (LPSTR)0x007AF198;
LPSTR fieldTitle = (LPSTR)0x007AF158;
void *firstFieldPointer = (void *)0x007AF1D8;
PBYTE firstField = (PBYTE)0x007AF1D8;
PBYTE lastField = (PBYTE)0x008F81F4;
How to find addresses is included on first page and in tutorial.
The reason why it work on server is because we all use server that have same root (server4096)
Also if fore some reason bobsobol NMake is not working for you than try compiling it with Dev-C++.
Also provide us with more information so we can help more. Maybe even upload your game.exe (before and after a change)
Did thiaguin69 say (s)he was using NMake? I didn't see it.
But yes, I have not tried importing all the compiled DLLs into an actual server, or client executable... so I'm happy to hear if you have difficulties with any of those. But I do need to know which one you are trying.
Also, (if I have missed a mention of NMake) it is written for VC6. Different switches are incorrect for newer Microsoft C compilers and newer NMake versions. I've not looked deeply into how to ensure NMake uses the "best" switches for each compiler, and syntax that is compatible with every version of NMake. Only that it does produce a valid DLL for each of them.
Note NMake is essentially designed for use with the DDK and SDK distributions Microsoft C++ Compilers which are only close relations to the Visual C++ distributions, and differer slightly. (hence we call them "Microsoft C++ Compiler", not "Visual C++") It is based on the same in-house source code, and the command line compiler in VC takes the same switches / arguments / parameters as it's equivalent Microsoft C++ Compiler version.
So NMake does work with MSVC, but it's probably better to stick to the VC IDE Workspace / Solution, for those, and use NMake only if you are building from the
To view the content, you need to sign in or register
(now just SDK) and
To view the content, you need to sign in or register
(now WDK) alone, without MSVC.
I know it's confusing, but Microsoft really do make a very wide variety of high quality software development products, of which Visual Studio is only their "flagship" product, and "Express Editions" are not the only way to get free C / C++ compilers officially and legally directly from Microsoft.
Although the
To view the content, you need to sign in or register
Editions probably are the easiest method for beginners to start developing software with Microsoft tools. Unless you don't care for C++ and just want to write video games, in which case
To view the content, you need to sign in or register
is another fine Microsoft Software Development product which is freely available... but no use to this project.
To view the content, you need to sign in or register
. (Only subsystem because it runs on the NT semi-
To view the content, you need to sign in or register
)
USER32.dll = primary userland core API, equivalent to libc.so or glibc in many *nix OS. Without this you have core OS but no drives, displays (even for text) file systems or user input devices in Win32 environment and must rely entirely on NT "Native APIs" below Win32 sub-system.
P.S. re
To view the content, you need to sign in or register
, please don't use OllyICE on anything newer than XP with NO SERVICE PACK AT ALL. (SP1 is badly bugged, and was quickly replaced, and OllyICE is not developed against or stable under any later Service Pack) It is a reasonable alternative to SoftICE (now defunct and no longer developed) under NT 4 / 2000 or Win9x though. (I hear) If you really need a Ring 0 debugger though,
To view the content, you need to sign in or register
is your modern SoftICE. The official
To view the content, you need to sign in or register
Bobsobol Ok, thanks for the tip ...
This really difficult to use these dll.
Now connects perfectly, but
even add new field
it returns the error, even taking
files of writeGlobalField_new_field
available = /
This really difficult to use these dll.
Now connects perfectly, but
even add new field
it returns the error, even taking
files of writeGlobalField_new_field
available = /
Can you be more specific? I added tutorial and some examples how to write first field.
Open writeGlobalField.h in notepad or in Dev-C++, define your field name
Code:
#define new_field dun_9 + fieldOffset
save and close.
Open writeGlobalField.c in notepad or in Dev-C++, add your field,
save and close.
Open writeClientField\writeClientField.dev with Dev-C++, just in case do "space somewhere and backspace it", than save it and compile.
You will get dll in same folder.
I can understand its hard if is not in your native language so past what you added here, only "first time" is hard... when you get how its done you will understand it... I hope
I do not know if you can understand me ...
You released files. writeGlobalField_new_field
I got these files modified oh
writeClientField.h inderecos for my ...
and compiled it, added the files on the client / field
and yet the ship in aparece in game = \
I do not know if you can understand me ...
You released files. writeGlobalField_new_field
I got these files modified oh
writeClientField.h inderecos for my ...
and compiled it, added the files on the client / field
and yet the ship in aparece in game = \
Thank you very much!!!
:
