Currently the developers are putting their own money into JC2-MP to keep the servers online.

Please take a few seconds of your time and disable your AdBlock plugin for our website.

Ad revenue is not going to developers, it is used purely for covering our hosting costs.

 

You are also free to donate, which removes all ads from our website!

Patch 0.3 was just released! Full changelog here: https://t.co/4A50m6IKen

2 years ago

Advertisement
September 21, 2019, 07:19:13 pm

Author Topic: Basic NPC AI  (Read 15716 times)

tally

  • Full Member
  • ***
  • Posts: 121
    • View Profile
Re: Basic NPC AI
« Reply #45 on: November 15, 2015, 10:20:00 am »
If a vehicle is occupied by a client actor, is it no longer invulnerable? Or is it players only? There's room for gamemodes if the former.

SinisterRectus

  • JC2-MP Betatester
  • Sr. Member
  • *****
  • Posts: 451
    • View Profile
Re: Basic NPC AI
« Reply #46 on: November 15, 2015, 03:07:23 pm »
Vehicles occupied by actors are still unsynced, thus invulnerable. They need to be occupied by a player to be synced, or they could be manually synced. The positions are predicted and updated on the server, so that's not an issue, but the healths require custom hit and collision detection.

Mossbros

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: Basic NPC AI
« Reply #47 on: November 15, 2015, 05:52:15 pm »
Does anyone know how long it will take for this to be released?

SinisterRectus

  • JC2-MP Betatester
  • Sr. Member
  • *****
  • Posts: 451
    • View Profile
Re: Basic NPC AI
« Reply #48 on: November 15, 2015, 06:34:57 pm »
I've released some pathfinding utilities for people to use, though I'm not sure how helpful that is. A lot of this is just a proof of concept, and not releasable in my opinion.

There are some servers with AI, though. Look for "Real Life Server - Survival" or "JC-MP Extension Test Server".

JasonMRC

  • Donator
  • Hero Member
  • *****
  • Posts: 601
    • View Profile
Re: Basic NPC AI
« Reply #49 on: November 16, 2015, 02:02:54 am »
Does anyone know how long it will take for this to be released?

AFAIK, AI is still in its very beginning stages. On the few servers that have it, it is limited, and/or resource intensive.

Hopefully one day it will become a native feature.

Mossbros

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: Basic NPC AI
« Reply #50 on: November 17, 2015, 08:20:51 pm »
I've released some pathfinding utilities for people to use, though I'm not sure how helpful that is. A lot of this is just a proof of concept, and not releasable in my opinion.

There are some servers with AI, though. Look for "Real Life Server - Survival" or "JC-MP Extension Test Server".

Can you give me the address' of some of these servers please?

SinisterRectus

  • JC2-MP Betatester
  • Sr. Member
  • *****
  • Posts: 451
    • View Profile
Re: Basic NPC AI
« Reply #51 on: November 17, 2015, 10:18:40 pm »
You can search for them and other servers here.

SinisterRectus

  • JC2-MP Betatester
  • Sr. Member
  • *****
  • Posts: 451
    • View Profile
Re: Basic NPC AI
« Reply #52 on: November 22, 2015, 07:13:56 pm »
If you direct your attention over to the releases subforum, you'll see that jaxm has been hard at work on his own AI project. Check it out here.

I may release some more of my NPC scripts in the future, but knowing that this release is out, I can now focus on some other exciting things. ;D

SinisterRectus

  • JC2-MP Betatester
  • Sr. Member
  • *****
  • Posts: 451
    • View Profile
Re: Basic NPC AI
« Reply #53 on: July 05, 2016, 07:36:09 pm »
Time to brush the dust off of this thread. Apologies for the long post.

If you've read my previous posts here, you'd know that my attempt to build a server-authoritative, on-foot AI system met with limited success, mostly due to the intense resource usage of pretty much everything involved. Jaxm had similar issues, although he at least managed to release a fairly complete package of his own, with ground vehicle traffic, too. I released my air and sea traffic as a companion, and called it quits.

Over the past eight months, I was mostly inactive in terms of JCMP scripting, and worked on some other things, including a Discord Lua library. The nice thing about that break was that it gave me an opportunity to learn some new things about Lua and programming in general. I just want to share some major developments regarding this project. Here is the first one.

----

Game World Data Serialization

If you want to run AI on the server, however smart or dumb it may be, you need to give the server some information about the game world. The more you provide to the server up-front, the less you have to rely on clients and network limitations. To this end, I spent countless hours working on a method for harnessing information from a client and converting it into a format that can be used efficiently by the server. You can find more information about that here. The summary is: for a 2 meter resolution graph of Panau, roughly 6 gigabytes of files were generated; one particular cell contained 4390 nodes and came in at 188 kilobytes. That's approximately 43 bytes per node.

In comes binary serialization. Previously, I had no idea what this meant. Now I do. If you are like past me, then I explain it here:

If you want to store the number 100 in plain text, which was essentially what I was doing, you need 3 bytes of space. One byte for each character. Add on top of that delimiters like newlines, tabs, or commas, and you get another byte per character; 3 to 5 bytes to represent what a computer will eventually covert to (in this case) 1 byte. It's far more efficient to not save this in plain text. Instead, you can encode it in a binary format and write that directly.

In Lua, instead of using
Code: [Select]
file:write("100")you would use
Code: [Select]
file:write(string.char(100))
Here, string.char(100) outputs the character 'd'; a 3 digit number represented by 1 character. That's useful for numbers 0 though 255. For larger numbers, you just need to use more bytes. I won't go into specifics here, but the concept is the same. For my purposes, I ended up using bytes (8-bits) and shorts (16-bits), both unsigned, which allows for numbers from 0 to 65535.

When you use binary serialization, you can't reliably use characters as delimiters. What previously used commas to separate values now interprets those commas as the number 44. To compensate, you need to either make the data structure consistent, or store some information about the structure, or both.

My data is represented with one file per map cell, where each cell contains nodes. At the top of each cell file, the header is:

- byte: cell x
- byte: cell y
- byte: log base 2 of the cell size
- byte: log base 2 of the node size
- short: node count

This six byte block is always expected to be at the top of each cell file, and it is basically information about what the program can expect from the file. The first 4 bytes are used to confirm that the file is of the proper format, while the last 2 bytes tell the program how many nodes to expect. The node data follows this.

Each node is represented as such:

- byte: x
- byte: z
- short: y
- byte: connections bitfield

No more than 255 x or z values are expected per cell, so by storing them relative to the cell (0 to 255) rather than the whole map of Panau (-16384 to 16383), I am amble to squeeze them into one byte instead of a two byte short.

The y values can extend from 0 to about 2100. For this, I needed to use a short, no exceptions. I did manage to save room by rounding any decimal values. Precision is compromised, but the value would never be off by more than 0.5 meters, which isn't terrible.

The last byte is a bitfield that represents the connections between each node. A bitfield allows you to represent an array of booleans in a compact binary format. For my data, my potential connections are:

- forward: 1
- backward: 2
- left: 4
- right: 8
- forward left: 16
- backward right: 32
- forward right: 64
- backward left: 128

So, for example, if one node has a connection to the left, right, and forward left, then it can be represented by the sum of all 3 values: 4 + 8 + 16 = 28. It might be easier to visualize in binary:

00000100
00001000
00010000
--------
00011100


Now, a limitation here is that the bitfield tells you that there is a connection. It does not tell you where the connection is located. Locating the neighboring x and z values is trivial, since that is based according to the node size and the physical direction. Finding the y value is not trivial. I could have stored the y value along with the node, but that would have been an extra 2 bytes per connection. Instead, I opted to search for the y value. The search is relatively inexpensive, since there is usually only one or two nodes that have to be checked, sometimes more.

If you're interested in the actual implementation, you can check out my repository here.

Thanks for reading, and look for more updates in the near future. :)

----

tl;dr: I managed to reduce my serialization from approximately 43 bytes per node to 5 bytes per node.
« Last Edit: July 10, 2016, 08:41:43 pm by SinisterRectus »

SinisterRectus

  • JC2-MP Betatester
  • Sr. Member
  • *****
  • Posts: 451
    • View Profile
Re: Basic NPC AI
« Reply #54 on: July 19, 2016, 02:37:10 am »
For the, at least, one person who I know is eagerly awaiting further development on this project, I've uploaded an A* pathfinding server to GitHub, though it is not yet finished. When it is closer to being done, I will explain more about what it does and how it works.

Until then, here is the repository link:

https://github.com/SinisterRectus/PathIt

I never claimed to be good with project names.