Hello , i have problems , maps are added but i can only spawn with gm comand and can't set flags and kill moobs ,
what is the problem :scared:
Printable View
Hello , i have problems , maps are added but i can only spawn with gm comand and can't set flags and kill moobs ,
what is the problem :scared:
You have maps, you have no fields. XD
map meshes (.smb files in \field) must be included in both client and server folders. (server needs terrain detail for gravity on NPCs, hostile or otherwise... or as you put it "moobs" :lol:) also you need to have equivalent mapname.ase.spm, mapname.ase.spp and mapname.ase.spc for each field in \gameserver\fields folder.
.spp = Spawn Point Positions (no SPP = no flags) :wink:
.spc = Spawn Point Characters (only necessary for non-hostile NPCs, like pot vendor)
.spm = Spawn Point Monster (defines what "moods" are spawned on this map)
I think the server.exe needs to be updated to look for new fields as well as the client... so I hope you didn't steal these maps and the client to go with them. :wink: That would make your job from here out rather difficult, I think.
Spoiler:
...also your offset to new map can be wrong, new map offset is sent by ECX because functions that are calling it are thiscall functions, offset of new map is sent to function that use that address to calculate where it should write new parameters so if your offset is wrong than PT can't read new map.
Its simple write map info every 147Ch(client) or 0EA8h(server) that PT will read later. You also need to remember that end of function have last free space (always moved to ECX because is sent as "this") for new map values so you have to increase that too.
Its a bit confusing now but I am writing C [yes C not C++ or C# :) (for some reason only C compiled with gcc produce clean working code >=P)] code for adding new map so it will be easy like:
etc... its on beta testing now, working but have a lot of bugz :)Code:[...]
loadMap (startFore-3, "forest\\fore-3.ase", "fore-3");
loadMapAni(startFore-3, "forest\\3ani-01.ASE", 0);
fieldCmdXZ(startFore-3, -16419, -7054);
[...]
Off-Topic:-
That would be because you are interacting with pre-compiled x86 binary. C# can call x86 but x86 cannot call C#.Quote:
Originally Posted by Vormav
C++ is highly compiler specific, and interactions between Visual C++, Gnu C++, Borland C++, Digital Mars C++, Watcom C++, Open C++ etc are always fraught, (not impossible, but messy) because of the different implementations of Object Orientation.
Intel C++ can be used with either GCC, MS CC, DMC or OWC to produce x86 which is largely compatible with other C++ written with those compiler suites.
MSVC6 is not compatible (at low level) with MSVC 7, is not compatible with MSVC 8, is not compatible with MSVC 9 is not compatible with MSVC 10. >.< Borland Trubo 4.5 C++ for Windows (cerca 1990) is still largely compatible with Borland C++ Builder XE (2011). (does this mean Borland haven't progressed or just that MS are a pain in the backside? Probably a little of both.)
C is just C. It's C when it's on Unix, it's C when it's on Windows, it's still C when it's run on CP/M or DOS. If it's x86 C then it's just shorthand for x86 machine code... that was a design intention when C was conceived. In fact, it was the primary design intention. The sole purpose for the creation of C was to act as an intermediate language that AT&T could develop Multix (later stripped down to Unix) for multiple hardware architectures from a single code base.
A similar design intention exists in C#. To abstract the binary from either the CPU or the OS, so that (like Java) one binary fits all... provided a suitable IL (intermediate language) framework exists on the host platform.