No Leaf Clover - 2016.06.13 - custom OS build - no updates

[10se1ucgo]

Well since you can't present motivations why you are chasing licences, I assumed the worst.

Okay, my motivation is that what you're doing is morally wrong and will in fact lead to the downfall of your mod that has a player base of 1.

[bloodfox]

if you're pissed off with his stuff and say it will lead to its downfall then fucking go away you stupid cunt. Judging by the views his topic has, the whole "player base of 1" thing, I have no fucking clue how the hell you came up with that "fact"

[Chameleon]

Ok... I am not "pro" programmer, in fact, I wouldn't write half of openspades with what I know now, even given infinite time (ok, maybe there is a chance I could, but...).

I was chewing this for some time, I spit it out now. Yes, I pretend I know what community more or less needs. I am sorry about that, I just felt the need to take matters into my own hands.
So ok... I am afraid, if I release the source right now, people won't cheat as in "wallhacks" or "aimbots", but they will cheat as in "disable drunk cam", or "disable the crouch spam penalty", that kind of practically undetectable thing. Same with me commiting to Git, some changes might go trough, more than half will not, ever. I am aiming to make OS run faster - yes, those changes more or less would get applied. I am aiming to make OS less of a hack tool - I got low chances of succeeding in getting my commits approved. And even then, you can backtrack the changes, erase them and profit.

I am thinking about possibilities of releasing most of the source but not letting modded clients to connect. If I abandon the project without serious work in >6 months, yes, chances are I will release full source for you to play around with. Anyway, even now the changes made are not drastical. Yes, they change gameplay, but it's only 2-3 months to re-do them, they are not very drastic code-wise, more of a logical task than programming.

To have a list of examples...
Low chance:
Crouch spam accuracy+recoil penalty,
Jumping accuracy+recoil penalty,
Moving accuracy+recoil penalty,
No zoom for SMG/Shotgun,
More screen shake when hip-firing,
100% disabled SmokeSpriteEntity which is just lag,
decreasing sound distance when shooting/exploding (increasing in silence),
player, intel model limits,
drunk cam, freeaim,
generally anything that could make playing harder, more skillful...

Chance:
Most of hud stuff,
cg_brassTime,
maybe different player models fo each team,
cosmetic changes in general.

And I am very serious about cheating. It ruins my experience, it ruins everyone's experience, game gets far less chances of surviving the winter.
Example:
Assault Cube suffers from this too, their blacklist is insanely long. Opensource.
Also it has an unwanted child, Assault Cube Reloaded (mind "opensource"), which is taboo in AssaultCube's forums, AC/R is practically Cawadooty copy, airstrikes, bullshit perks etc.
If we go deeper into the rabbit hole, cawadooty is more of a 2k-sci-fi shooter than reality, minus skills, plus weapons. I might say, fine, let this game exist, but it's fanclub is too obsessed with quackscoping, k*pi*2-shooting and claiming it's realistic.
I can't say such respectable names as "Quake" or "UnrealTournament" in one line with "Modern Shitware 6".

[LeCom]

Also, a little fun never killed nobody. Cheer up.

Wtf this is so different from all I saw when trying the standart SW renderer. The weird lines really exist in yvt's version?

The whole point of GitHub is that you can fork OpenSpades and get your own source repository and then you are your own master and can do whatever you want. From what I saw, it's even possible to exchange updates between your version and yvt's, even if they become very different. And you can always request to merge both versions.

If all your game is about is shooting and killing other people, you will get hackers and quickscoping nolife kiddies all the time. The secret is to move away the focus from shooting. Like what I did with mortars in VXW, where you could kill an enemy without even seeing him (!), only with imprecise informations about enemies being near certain points. Another solution would be making the hit checks server-side with the physical constants influencing the movement of bullets changing with each server, however, that is a bit harder to make, especially when you know that players can have a high ping.

[Warp]

Lil performance info:

Ran SW renderer on GTX970 + i54690k @ 4.2ghz - roughly 41-44 fps.
Ran OpenGL renderer- 300-380fps

As we said in game, Chamelon, the SW renderer needs some optimising ;)

[Chameleon]

As we said in game, Chamelon, the SW renderer needs some optimising ;)

Not right now, but yes, if I dare to think of protocols.
If you run Software, your graphics card is pretty much useless, all load is on CPU...
I once said to LeCom "why don't you use OpenGl, just without all the latest eyecandy, like version 1.2, all cards should run it", I still kinda think OpenGl can be used, but since some people have integrated Intel HD's, which have the very high performance of top 10fps when looking anywhere except sky, we also need software.

The weird lines really exist in yvt's version?

Can't tell if this is a joke or not, I did say to cheer up :D. Not sure which ones you are talking about. Lines exist in yvt version too and it seems that blocks are made out of them. Some appear at certain up&down angles, and appear more with less FOV.

Or maybe it is possible to transfer all the HUD to OpenGl and leave CPU only to render the map? Would help a bit.
Also... OpenGl can do sprites, also there are long sprites (like distance from A to B would be filled with same sprite, used in OpenGL version tracers), so we could try to emulate Software on OpenGl. Not sure if this would work out, since GPU's are optimized to do triangles. What do people think?

Graphics talk aside now,
I could do what the angry dude asked me and release most of the source, or commit changes to official git. But I would do that after I release new protocol. Though Netcode, stuff like that, would remain closed. Yes, I know the licence, it's still violation, but hey, I am not leaving you guys very much behind.

Idea of mortars, HMG's is a yes. But I honestly didn't like mortars in VXW. Mortars are supposed to be precise. In VXW, they are used like grenade launchers (M79/HK69/M203/GP25) - they come in at a shallow angle, their trajectory is flat. Suited for hitting etc. inside of buildings through windows. Mortars are way different, their projectile speed is low, they have high-arching trajectory, suited for cleaning trenches.

Server side hit detection... Is not very plausible. We have only hundreds of players. Rarely you can choose a server with low ping, so as a result, right now there are players with varying pings in the servers. I have to look at server code before I say anything more about A/C.

[LeCom]

@ESP: server side visibility detection. Yes, it IS a thing.

@crappy mortar: This was mainly cause by me not knowing shit about how mortars were like irl.

@weird lines: you had told me lines are weird in the SW renderer, and your screenshot is distorted af

@renderer: there's a thing called GPUGPU, tl;dr it stands for using your GPU for executing C code the same way as your CPU. The biggest problem here is exchanging data with the GPU (heightmap works fine, uncompressed 3D map seems easy, but didn't work for me somehow). GLSL 1.2 was introduced in 2005, so it basically works on shitty rigs, as long as they're not too old. I didn't really benchmark it, but I have a fast CPU-RAM combination and slow integrated GPU and it's easily 5x faster than using the CPU.

[Chameleon]

@ESP: server side visibility detection. Yes, it IS a thing.

Hmm familiar thing, I believe it's in Quake3 (or at least one of it's mods). When you lag a bit when coming round the corner, enemies appear out of thin air, causing a bit of confusion. But yeah, that's a nice thingie to stop esp's. Also server admins use built-in esp when in spectate mode so they can see who's doing what.

@crappy mortar: This was mainly cause by me not knowing shit about how mortars were like irl.

It's excusable, VXW was at early stages. But I did like that mortars were constantly falling around, you had to take shelter, dig a trench or they'd still get you eventually. I think about adding some ability to make marks on maps, like when using binoculars, you can spot for your entrenched mortar crew.

@weird lines: you had told me lines are weird in the SW renderer, and your screenshot is distorted af

800x600, plus .jpeg. If you see behind the noise generated by jpeg, yes, lines are weird in OS SWr - compared to this, Voxlap is cleanest place on earth even up close. I would actually prefer VXW or Voxlap, they look a bit better.

@renderer: there's a thing called GPUGPU, tl;dr it stands for using your GPU for executing C code the same way as your CPU. The biggest problem here is exchanging data with the GPU (heightmap works fine, uncompressed 3D map seems easy, but didn't work for me somehow). GLSL 1.2 was introduced in 2005, so it basically works on shitty rigs, as long as they're not too old. I didn't really benchmark it, but I have a fast CPU-RAM combination and slow integrated GPU and it's easily 5x faster than using the CPU.

I found it to be *GPGPU. Quite cool thing, could solve performance issues... I understand that GPU is faster than CPU when there is a lot of data to be processed at once, like determining if a block is visible on screen or not and then returning it to CPU to render it. Also it might determine block shadows, the algorithm is simple, I've got it in my brain, it's performance that's keeping me from trying to implement it.

GOD, I should be studying maths...

[LeCom]

For visibility checks, there would probably be a tolerance value, so you would still receive packets about inivisible people if they're straight around the corner or very close to being seen.
I tried OS SW renderer, and you were right, it's jagged af. I still think it's some precision problem or some error in the height calculation, because there's nothing else I could think of.
And one page actually mentioned it as GPUGPU lol. Forget about GPU and CPU exchanging things, it's more like you upload a few bytes to the GPU each frame, but all data needed during the frame has to be stored in the GPU.

Also, PLEASE PLEASE PLEASE fix the netcode. There's a kraken server now and it's buggy AS FUCK with OS. Especially the ammo handling code.

[Chameleon]

Ammo handling is server side.
All the ammo changes are done on the server. When you shoot, your client counts bullets left in magazine itself. But when you reload, server sends client a package about client's real ammo count. That is why in AoS 0.x after reloading, you'd see some rounds disappear when doing tactical reload. I thought it was intentional, but it seems that sometimes, time passed slower on my client than on server. And server shot the extra 1, 2 or 3 bullets without me knowing.

So that might be not bad netcode in OS, but rather bad netcode as a whole. And actually bullet disappear is quite rare now compared to AoS 0.x client.

But I will check Kraken server anyway, for research purposes :) . One time I had infinite ammo on SMG, but server might just have thought I was empty and didn't bother to correct it or send it to others.

EDIT: I am getting kicked out, I got a message "Invalid Player ID 31: Doesn't exist". Thinking of a way to fix this...
I know. I made grenades different for teams (just models are similar right now). I uncommented a single line. So, my first working release doesn't crash, I am looking for a way to fix it.

*the crashing releases I mean :P

[LeCom]

Nono, what I'm talking about is client behaviour. When receiving the same input from the player and server, OpenSpades does something different than AoS classic - that's my problem. The disappearing bullets are probably caused by lag.

[Chameleon]

Are you talking about bullets disappearing from Shotgun? Shotgun's like a cannon, you reload it to full and then you get a single shot to fire, which, when hit, creates an explosion.

If we are talking about different things, please clarify. For me, "Kraken" behaved the same for AoS and OS.

[LeCom]

Are you talking about bullets disappearing from Shotgun?

That's an example. You overlooked the fact that it gets loaded fully at first, in AoS that doesn't happen. It's probably a client-side reload. I also get weird ammo numbers sometimes (not sure if that only happens in OS though). There are several other scripts that don't work properly because of the way OS handles packets.

[Chameleon]

There are several other scripts that don't work properly because of the way OS handles packets.

Let's make a rule: the more specific you are about an issue, the faster I can find a solution :) You are specific enough about Kraken.
I will check Kraken (if it's still up) with 0.75. Or maybe it's time I started looking into server code, what's it supposed to send and what/how OS handles it. I know that OS is not 100% compatible with servers, I looked into netcode a bit, it's...

Lecom's correct on this end-- Reloading with the shotgun in Voxlap can sperg out the numbers sometimes.

So if I understand correctly, issues with ammo count are not limited to OS?

[Chameleon]

Well I also have to note that Kraken mode currently running is a bit broken in other aspects as well. For example, in map (ship, close to one flat island surrounded by smaller, higher, pillar-like islands; treasure hidden under the X; lvl2 treasure hidden in the pillar-like island) we couldn't do level 2 kraken, because even after spading the 2nd treasure for solid 5 mins, nothing happened.

But yes, ammo is worth investigation. I did notice AoS shotgun never shows anything else than 0 or 1, while OS loads up to full and then reduces that to 1. Which means that OS client reloads the gun itself, and then receives correct ammo values from server. AoS client doesn't count the ammo itself - it 100% relies on server to count the ammo.

Should I correct netcode before we start doing SW? I'm having difficulties launching pysnip - "MemoryLoadLibrary failed loading win32api.pyd"