Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - ai_enabled

#976
Hi guys,

A few players asked me why we decided to use 2D character art with only 2 views (front and back + mirroring).

Before answering that question I'd like to share our requirements for the character system:

  • All player characters should have distinct appearance, so players can easily distinguish between them in the game.
  • The characters should have configurable faces constructed from multiple parts (face "shape", upper and lower face parts, hair, skin, color, etc.).
  • The character faces should always be as visible as possible. For example, if the game was top-down we would never be able to see the characters faces, and in isometric view, players would only see really small faces without much details and without much customization).
  • All the clothing and equipment should be visible on the character (and it shouldn't be simple recoloring or texture swaps).
  • It should be relatively easy to add new content into the game - including faces, clothing, equipment, etc. Let me reiterate - it must be so easy that even modders who are not artists should be able to throw something together in Paint.
  • It should be relatively easy to animate characters.
  • The resulting assets file sizes should be reasonably compact.

We've considered three approaches to characters art during the pre-production:

1. All characters made completely in 3D:
This will require modeling of the characters, clothing, equipment and even hair. In some cases, it will be possible to reuse the models and just redraw textures, however drawing textures in unwrapped view is hard.
The projection will be 3D isometric or similar and players will not see much of the details in face styles and equipment.
Animating 3D models is also really hard and requires special (quite complex for novice modders) applications.
It's hard to match the style of other (2D) art in the game - buildings, terrain, etc.
And it's plainly difficult to integrate 3D rendering with 2D rendering from the programming point of view.
Good thing - it allows more views/directions and smoother transitions between them.
Conclusion: doesn't satisfy several important requirements

2. Prerendered 3D characters exported as 2D spritesheets (like old-school RPGs and some newer indie games)
Obviously, it has all the drawbacks of the previous solution PLUS it doesn't satisfy size requirements as it will require hell lot of images (many frames multiplied on many views multiplied on many different clothes and equipment).

3. Use 2D character art with front and back views only (+ mirroring)
This is the chosen solution, completely satisfying all our requirements!
The only drawback is that the amount of views/directions is very limited, but it's an acceptable compromise - we've tried hard to keep it looking stylized and fun.
With this solution, it's very easy to add new content into the game. You just need to draw a bunch of sprites to add a completely unique face style, clothing or equipment item into the game. You can even use Paint, but we recommend using Photoshop and our special Photoshop template and export scripts (which we will make available later). The game itself is able to automatically reload ANY changed image file and so you can draw-save-try-redraw-save as long as you want and check how it looks in the game.

So, is that it?
No! Our animation engine actually allows for much smoother animations and sprite mesh deformations, so you can expect much better animations in the future when we can set aside couple of months specifically for this task. We will come back to that in a year or so and hopefully make our character system even better.

Regards!
#977
Game discussion / Re: Linux
March 08, 2018, 11:57:57 AM
Tchey, yes, we're using a huge amount of new techs/libraries which are not ported and not emulated yet. The only way is to wait for our official Linux version.
#978
Modding info / Re: WIP Salvaging
March 06, 2018, 05:13:26 AM
Better 1 year delay than never :-)
We've implemented this feature in v2.1.0 http://forums.atomictorch.com/index.php?topic=1012.msg6297#new
#979
Bug reports / Re: Error in multiplayer horribly
February 11, 2018, 10:24:36 PM
It's not possible to create a random item generation mod similar to Diablo 2.
Regarding localization of DLC - it was discussed there http://steamcommunity.com/app/324260/discussions/0/133258593406618170/#c133258593407269390
#980
Bug reports / Re: Error in multiplayer horribly
February 09, 2018, 01:08:40 PM
Hello!

Thanks for reporting!
We've got a few reports of this issue and were able to reproduce it in some cases.
Surprisingly, the game doesn't work very well with some VPN connections. If the players who experienced this issue are using VPN, please ask them to disconnect from VPN and try to connect directly to the game server.

Another source of the issue could be your localization mod. Please try to remove it from ModsConfig.xml for your server and restart it. If that helps, you can upload your mod and post the link - we will check it and tell you how to resolve this issue for your mod.

We're planning to release the patch for VoidExpanse later this month, but I'm very unsure if we will be able to resolve this issue as it's really hard to reproduce.

Regards!
#981
I think the error is quite different from what we had with the asteroids.
This error message appears if you're asking Scripting API to perform some action on a ship and the provided ship ID is 0. You can try to isolate some parts of your scripts to find the line which leads to this error message.
If you're unable to locate it, I will be able to look into the source of this issue when our vacation is over (we're going to a Lunar New Year holidays for the next ~1.5 weeks).

Regards!
#982
Game discussion / Re: CryoFall - new screenshots & news
February 07, 2018, 12:49:54 AM
I'm happy too as we didn't find any serious bugs and overall the game is rock stable.
Bottom line is - the game is kickass, prepare to throw us your money within 30 days or maybe even less! ;D
Though, we are planning to release the game completely for free during this initial period!
#983
IMCache is done on purpose in such way to build the "ship stats cache".

The cache re-calculation is expensive should not happen too often (ideally it should happen only once for every NPC ship - on spawn or savegame reload).

Basically, it's the "stats" parameters of the ship which are populated with by the scripts (with AddValue and MulValue methods) and then combined with other caches (such as weapons/equipment cache) and finalized. You should never use it in any other cases. I'm not even sure if you can override/extend it and use in other scripts (I mean it could break the code from CalculateShip.js).

Alas, VE was made in a big rush years ago (with 99% of these scripts written by a member of the team who left even before the release) and now it's all legacy code and incomplete documentation...
#984
>> It's a tiny lag spike just when the AI's pathfind activates

Does it happen for every new drone AI or just a single time? Sounds like a script loading/compilation lag, in that case you can't do much.
#985
atan2 is the way we're usually using to get the angle between two vectors.
Actually, atan2 call is a little bit slower than sqrt on modern CPUs.
Anyway, it's not something to worry about until you really perceive the issue with the performance.

Regards!
#986
Hi nine,

There are two functions to calculate the dot product between two 2D vectors A and B:

// first approach uses vector lengths and so requires expensive sqrt calculation
var dot = a.Length * b.Length * Math.Cos(angle); // it also uses angle between A and B vectors

// second approach is much simpler
var dot = a.X * b.X + a.Y * b.Y;


So you can simply use the second approach to calculate the dot product.
If you need to get the angle between them, you can use this function:

var angle = Math.Acos(dot / (a.Length * b.Length));


Regards!

UPD. Oops, I was wrong :-), corrected the post.
So you actually need vector lengths (and so sqrt) to calculate the angle between vectors with the dot product (IF the dot product alone is not enough for your case).
I think this is a premature optimization. Even thousands of sqrt calculations per second are not that slow on modern CPUs. Don't optimize until you actually can feel that it's too slow.
#987
Bug reports / Re: Too many Heap sections crash!
December 27, 2017, 09:26:11 AM
Great to hear!
I'm afraid you will be unable to release it yet as it might require some API improvements which are available only in the server preview build I've sent to you. Better to check with the vanilla server build from Steam Client.

Regards!
#988
Bug reports / Re: Too many Heap sections crash!
December 26, 2017, 07:05:13 AM
Hi,
This is just the client crash (server detected the client is not running anymore and also stopped).
I'm quite sure this is just a memory leak at the NVorbis plugin we're using for music decoding/streaming. Will check for the next VE patch. With the last patch we didn't check the game stability after many hours in idle and nobody reported this issue before (most players run it just for a few hours max).
Thanks for reporting!

Regards!
#989
You're right, the prices are modified (and their statuses too). The price for cargo is calculated by SetResourceBasePrice method at Station.js. This is implemented this way to adjust prices randomly with 10% deviation. Yeah, that's really overcomplicated. Each station generates items/cargo for sale and calls this method for each of them to calculate the price, then this price is stored on server, but players receive another price which is calculated by CalculateBuyPriceOfCargo and CalculateSellPriceOfCargo (or same methods for items).
The only solution will be to implement new API methods for getting the final price of item/cargo by providing player's ship ID and station ID.
#990
I verified the C# code and can definitely say that it calling Station.js file, methods CalculateBuyPriceOfCargo and CalculateSellPriceOfCargo, to calculate the prices. Have you tried to add the console logging to these two methods?
The game calculates the prices for a player during docking, when the items are added/removed from the shop items list (such as during stock items regeneration) and when a player tries to buy/sell to calculate the current price.

"args.cargo_price" is the price of cargo/resource from the XML file.
It seems there is no API for getting the price by cargo/resource XML ID so you're stuck with this for now, alas.