[Dev] Hellmouth Revival

Good thinking.. Similar syntax ftw.. I hate changing once you're used to something

We are now using IronPython for our Npc Scripts.

Registers a function into iron python.

Quote:

Originally Posted by _tao4229_ Code: scope.SetVariable("text", new Func<string, GameClient, int>(delegate (string text, GameClient client) { client.send(new npc_dlg_packet(text, ... )); return 0; })); Registers a function into iron python.

So that way it would just be like text("Rawr", Client) for my script? Ill give that a try real quick.\

EDIT:
Did it, yes. Thanks. Way faster then my previous way.

Quote:

Originally Posted by -Fáng- Awesome =] I'm working on NPCs in my source too. I was going to do a full database system so that I don't have to restart the server or anything! =]

Man I think Ive seen ur source all over the forum.
Stop talk about it all the time, is like 99% of ur posts includes the word "my source" :facepalm:

So just a heads up as to why development is going slowly.


I just re-started university and things have been kinda crazy (still working at the same time.. and housemates just moved back etc... so lots of ppl to catch up witch lol)

So yah... source IS being worked on but all of us are very busy right now. I'll be sure to keep things updated here but don't expect rapid progress.

I'm just sorta getting back into the swing of things as I work through scheduling and stuff. Some minor packet logging done today so I can start adding some new features. Ideally I need a few hours so I can properly look into quadtree (read some examples but CERTAINLY not comfortable coding one from scratch yet) and that has to come before full spawn/despawn system. I did code it with loops earlier and it worked... just don't plan on using that long term so left most of the spawn systems alone.

Ooh... and add walk to list of movement/general shit that's coded. I had completely forgot to add the calculations for directions earlier.

Also added weather seeing as it's super simple

Also added structures for monsters and will throw together basic database to save/load them. I'll deal with spawns and then mob ai some time soon... next week maybe.


In the process of buying a new PC (will be used for the closed beta) which should be rather kickass.


Server stats.

i7 Quad core 2.8 ghz
8 gig ddr3 ram
1gb geforce 250 vid (I don't do gaming so this is plenty)
60 gig ssd ;)
tb hdd


Should work very nicely for a temporary server machine. Keeping in mind my net here is nothing special it should work out for some simple testing and server development

Ooh... and 28 inch 1080p monitor *drool*


So yah.. closed beta can be expected within a month (We'll have signups, don't worry it won't be hard to get it. Just need people who aren't expecting a GAME to play yet.. but rather test out features as we add them)

Along with beta will come proper website and forum vs our crappy one (domain will stay the same, just gonna get proper hosting)

Also, during the Beta stage we will need people to add Npcs with proper meshes and appropriate locations. We will probably do most of them but some help would be appreciated.

Same with npc scripts. There will be scripting guides and tools posted on our forum to help members contribute

I can't for the life of me spawn myself a Shop type Npc. It always requests a script :(

Whats the point of the UID?

uid = just that... a unique id number to identify entities from eachother.


flag = type of npc.

<edit>

So... I may end up re-building the server from the base up as we add things in (our custom source works just fine.. I'm just coming up with so man improvements thanks to quad tree... inheritance.. interfaces and all that good stuff.

Basically what I'm doing is re-writing quad tree for a conquer application right now using an external program... the organization is already FAR superior than what I had before so I may end up combining the two...

So the concept is people use the existing source to code game features and packets.. then I make them all organized and shiny before putting them into the FINAL source. We may even use the original as a base as this will have little to no effect on final server efficiency beyond the ability to add new things simply (I have no desire to muck around through old source to add quad tree into everything..)


So basically... PROGRESS is happening. I spent most of the day bashing my head against the wall with quad tree and think I finally get how it works fully (I knew theory and everything but was not ready to write it from scratch). Re-writing all my geometry calculations from scratch as well as all my object codes.

I'm thinking my inheritance for now will work as...

Objects which then split into 2 groups, entities and static objects which then split into their base levels.

All objects will have circle geometry associated with them (fast, efficient collision detection) which will be added and removed from quad trees for the different maps. Then we will have our static/entity objects which will consist of...

Static:

-Npcs
-Ground Items

Entity:

-Players
-Monsters
-Companions (guards, bots, duelists, etc)

I may refine this in the future but it will allow for less things to be re-used (eg: All objects need map/x/y/uid values but not all need things like a spouse string... nobility level... etc) Having them all inherit from a more base class though SHOULD allow me to combine them all when needed (checking for collision is my main concern here w/o wading through massive amounts of code)



Trying to remember... what's spawn distance approximately? (using point distance here) was it 18 or something? cause thinking just set all objects to have radius of 9 meaning they will collide any time within a distance of 18 from eachother.

It's not a radius, considering its not a circle.

dist = max(abs(x2 - x),abs(y2-y))

Maximum distance is anywhere from 16-32, even TQ gives you retarded distanced entities half the time.

Quote:

Originally Posted by _tao4229_ It's not a radius, considering its not a circle. dist = max(abs(x2 - x),abs(y2-y)) Maximum distance is anywhere from 16-32, even TQ gives you retarded distanced entities half the time.

Ooh... for some reason I had in my mind that TQ used more circular versions of range to spawn things. Now that I think of it, no clue why I would possibly think that :S


I'll re-write my quad testing later. Right now writing a simple program to run through my dmaps and pull the map id and max x/y so I can setup the quads for the different map (thinking I'll just use a mapobjects dictionary to store map id and the associated quad).

Hard to test much w/ these w/o a graphic representation but it's letting me add/remove objects and it's subdividing under certain circumstances so seems to be working xD

<edit>

Dumb question here... Is not the spawning based on an ACTUAL rectangle then? (wider than it is tall). I remember the spawn ranges confusing a bunch of people including korv but if I set up a rectangle using like height 16 width 24 will that not cover things properly? And yes... not sure wtf was causing me to think circles. I think it was the ease of calculating circular intersections that made me go that route.


<edit x2>

Got bored today and had some spare time so I added some super basic stuff.


Ground items working. Wrote base systems for inheritance for objects. Basicly I have a dictionary holding mapid and a map struct. map stuct holds a list of all map objects and other factors (eg: weather, dimensions, and anything else I want (skill use permissions, pk permissions, etc)

Also threw in weather. I think I already posted that I have item info packet working but w/e. All in 1 screen

[Only registered and activated users can see links. Click Here To Register...]

Not huge progress... mostly was screwing around with base stuff cause bit hungover and have some time before work. Good relaxing mini coding that won't get me too stressed or anything lol

Progress Sept 19:


-Inheritance
All game objects should now be using the new inheritance system which sets up easy functions for ALL objects.

-Spawning
Spawn code should be FULLY working now. This includes monsters, ground items, npcs and players

-Instances
For now anyways, instead of using dynamic maps for events, I'm using an instance value. Each game object has an instance value which is checked vs the local objects being spawned. Players on different instances will see completely separate sets of clients, monsters, npcs and ground items.

-Local Objects
Should be FULLY working. In my spawn code I do the following...

Check map Clients.

If they are NOT in local clients dict, check if within viewing distance. Spawn them to me and spawn myself to them, updating both clients local client dictionary.

If they are in local client dict, do not spawn to either (no need)

If they are NOT in range but ARE in local client dict. Despawn myself to them, despawn them from me. Remove from both dicts

If not in range, do nothing.


Similar setup for npcs, monsters and ground items except that there is obviously no need to update them with my new info. This should allow for VERY simple usage of local packets

eg for jumping I won't need to check all the clients in range and to see if I'm already spawned to them or not (spawn client vs send jump packet). I'll be able to simply send jump packet. Just call the spawn all code and then if they are in my localclients dict, send them the jump packet from my prev xy/new xy.




Also I'm now loading ItemData into the server from a Items.txt file. QUESTION! I'm currently using a struct to hold this information but loading nearly 10,000 items into the server for use does take up quite a bit of memory (right now loading all dmaps, items and a few other things server is running like 160mb ram... very little change when I log chars so it's not like I have some big memory leak... just seems like alot of ram to use for mostly useless information.


Would it make sense to only load that information for gear items (seeing as the only time I need to get stat information is for gear). That would mean at LEAST a few THOUSAND less items needing to be loaded.

Eg: make a new file that only stores armor, weps, headgear... things that effect my stats.... Leave all generic items and stuff statless.


Also! Thinking of methods to handle status effect updates. What would you guys suggest as an efficient method to go about it? Just in my VERY minor experience when logging offsets for the spawn entity packet it would seem the new clients have a SHIT TON of status effects in comparison to old versions

Seems, that you getting so far with this project.
Good to see pro.
I wish u the best luck with Hellmouth :)