Iceball Project

[GreaseMonkey]

I guess you could even try to teach pyspades iceball's protocol to take that idea to the extreme. That would probably put extra load on the server though.

I would hack it in client side (people might want multiplayer without the massive "eval" too for security reasons) as that should mean more rapid developement, and then properly do it as you said, just having pysnip drop of the lua code and then go back to bussiness as usual. This will also make it easier to iceball to support multiple versions of AoS, as whatever need to be done client side will probably be enough for all versions of the protocol, and pysnip can take care of the slight balance differences.

In any event, getting people to use a new version of pysnip is still easier than getting them to use new server software altogether.

I'm not shoving enet in for the primary purpose of connecting to AoS servers. That's just not going to happen.

The other option (make pysnip support iceball connections) has been something sitting in my head gathering dust, but is the most likely solution for this. I suspect we'll need to refactor stuff a bit more though, and hopefully not have too much dependence on the main game's files / behaviour. I'd like it if we could eventually move the gameplay-related stuff to pkg/iceball/default., but before we can do that, we need to deal to the network.lua and ent/tool_*.lua refactors.

Here some bugs , and other things.
1. When a grenade is blocked(a block putted on it) it destroys just the one block o_O

If I recall correctly, putting a block on a grenade would make it not hurt anyone in AoS.

2. The player can pass trough one block. The one shooting hole in bunker walls .

This is probably autoclimb-related.

3. Sometimes when digging a tunnel , the players just get warped up for 1,2 blocks and gets blocked.

Yes, that's an issue we know about, and if I recall correctly you can fix it by turning autoclimb off.

4. The players can go sometimes trough walls o_O

I'm not sure if that's something that can be fixed by turning autoclimb off or not, but it's also a known issue.

(There is no 5., apparently.)

6. Players can go like half in into blocks , very very irritating.

...what? Please elaborate.

7. Sometimes some blocks are invisible

Spoiler:

Yeah, I need to replace the trapezium rendering with something more reliable and less "leaky". This is not a top priority right now.
Alternatively, this could be due to the less-than-optimal raycaster, which really needs to be fixed at some stage, but likewise Is Not A Top Priority Right Now.

Here some thing that are not bugs but are annoying.
1. The 4 grenades , Just as known in AoS .75 They have a to big griefing power.

This game isn't full of complete retards yet; plus, you start with 2, and get 4 by going into the tent. Heck, increasing the nade count theoretically makes them more useful for not griefing, as a griefer can just go back to their tent anyway.
Remember 0.54 and the complete dumbasses sitting in the tent spamming SMG at their team's stuff while being fed bullets through their ass? I think that was a worse problem. (It was fixed by 1. adding a cooldown time between refills, and later on 2. not refilling the clip ammo while sitting in the tent.)

2. The grenades can easily be spammed and re-filled via tent , making big holes at spawn that are hell annoying.

Yeah, we might need to stick a delay in. Anyhow, if someone's going to grief, they'll grief in any way they can.

3. The grenades should have larger throw range , now its like 1/3 of the AOS grenade

Grenades do need tweaking.

4. The player models!!! Should be like in AOS please remove that ugly , blocky , 2d , shit , simpson , incest

For the last fucking time, if you don't like the player model, make a better one. And no, we cannot accept the models that came with AoS, that would be a copyright violation.

5. Remove the drunken-cam it so irritating to dig with it , and to aim down cause as more you aim down your sensitivity goes f*** 100x up so digging down is a hell pain in the arse. Or at least make it Disabled as deafult

I'm not removing the drunken cam from the code. If you don't want drunken camera, host your own server and disable it in pkg/base/common.lua.

6. Why is there drunken cam when Aos proved that its of no good for a game.

It wasn't proven to be "no good for a game", that's just your opinion.

[Vucgy]

@GreaseMonkey
repply to -Here some bugs , and other things.
r1. I knew the grenade doesnt damages when its in a block , but it still destroys 3x3x3 , but in Iceball it destroys just 1 block

r6. The weird bug what hapens all the time , that must really be priority no.1

Spoiler:

repply to -Here some thing that are not bugs but are annoying.
r1. Whatever but 4 grenades are pretty much I would say , in any view

r4. I dont say use the exactly same models . Use simply a blocky solder like MC or AOS just a bit different thats it . ITs like CSS got soldier models and COD got to Soldier models too they both have hands legs torsos and heads but are different thats the point.
Just as Minecrafts players look close to AOSs solders but they are different , so iceball should look the same way make a Aos like soldier but like a GSG9 or Spetcnaz with maybe few block more at torso or legs. thats it . Aos didnt Buyed all the BLocky soldier player models on the world. Is it so hard to overpass the copyright ?

r5,6. It at lest should be swiched off by deafult , anyway...

[GreaseMonkey]

@GreaseMonkey
repply to -Here some bugs , and other things.
r1. I knew the grenade doesnt damages when its in a block , but it still destroys 3x3x3 , but in Iceball it destroys just 1 block

Something that needs to be understood is that the main aim of Iceball is not to be A Perfect Replica Of 0.35, but rather to be a continuation of AoS development, as well as a platform to chuck fun mods onto.

r6. The weird bug what hapens all the time , that must really be priority no.1

"The game crashes after it's played too many sounds", which is an actual bug in 0.0-4 and 0.0-5 (version.lua needs to be corrected here), would be a much higher priority than "the game looks a bit weird and sometimes shit leaks". Be happy that you have cubes now.
The main priorities right now involve refactoring the network code, and refactoring tools into individual entities.

r4. I dont say use the exactly same models . Use simply a blocky solder like MC or AOS just a bit different thats it .

We have blocky soldiers already. If you're not happy with the blocky soldiers we have, make your own.

Aos didnt Buyed all the BLocky soldier player models on the world. Is it so hard to overpass the copyright ?

Well we're not going to be doing a kv62pmf job on the original AoS models, as that is illegal.

r5,6. It at lest should be swiched off by deafult , anyway...

It gives a nice charm to the game in my view.

[tunaspirit]

I've noticed that bullets tend to come out of your eyes instead of the barrel of the rifle. Probably because the camera viewpoint is in the head of the model itself (because you can see your feet). If you would make them come out of the rifle, the bullets would end up not hitting where the crosshair is aiming at close range like in Sub Rosa (this could be ruled out with proper ironsight models). Or to fix this, the crosshair can be dynamic.

[HoboHob]

Highest priorities should be:
1. Improve performance
2. Implement a proper lua API.

[Moghard]

3. Make it actually work on old pcs

[ThisFrickinSite]

r6. The weird bug what hapens all the time , that must really be priority no.1

"The game crashes after it's played too many sounds", which is an actual bug in 0.0-4 and 0.0-5 (version.lua needs to be corrected here), would be a much higher priority than "the game looks a bit weird and sometimes shit leaks". Be happy that you have cubes now.
The main priorities right now involve refactoring the network code, and refactoring tools into individual entities.

That bug is usually leads to walking through blocks, so it isn't completely visual.

[rakiru]

Highest priorities should be:
1. Improve performance
2. Implement a proper lua API.

What do you mean by "proper Lua API"? The Lua interpreter supports everything.

3. Make it actually work on old pcs

As far as I know, this does work on old PCs (it may need to be compiled separately for anything over a decade old though), in which case, improving performance is all that's needed.

[Jdrew]

I have a question, how long have you guys been programing and what are your tips for future indie game devs?

[Sonarpulse]

I have a question, how long have you guys been programing and what are your tips for future indie game devs?

Well I've only done a tiny bit for Iceball so this probably isn't addressed to me. But here's my two cents. These especially apply if you are at all interested computer science in general. I guess if you don't care for theory and just want to get on the fast track to work on at Activision or something, this won't help. But I recommend keeping your options open and pursing both art and computer science and not just narrowing in on their intersections in video games. I've technically been programming only a little more than year, but I sort of hit the ground running.

1. Download Linux and install it. A VM doesn't count. You need to install it on your hard drive or you won't be "invested enough". Then you need to force yourself to boot to it and not Windows/Macintosh. It's true you almost everything you want without the terminal these days, but the truth is the terminal is better. Once you are used to Linux, try to use the terminal more.
2. Don't just use python or Ruby, Java or C#, C++ or C. Try a bunch of different languages. I recommend Haskell, Ocaml, or Scheme. If you are interested in performance-intensive games you will have to learn a non-garbage collected language like C/C++. Those aren't the only two. I just came across http://claylabs.com/clay/ the other day which looks very interesting.
3. learn git (command line). (Or mercurial.)
4. Do something open source. Either start you own project open source or contribute to someone else's. The latter will be especially educational. Checkout 0ad or the other games in my sig. And remember, if you are working on something you do not intend to monetize in any way, there is no reason not to open source it.
5. Humble Indie Bundle and Mod/Indie DB are good places to keep up to date with.

[HoboHob]

Highest priorities should be:
1. Improve performance
2. Implement a proper lua API.

What do you mean by "proper Lua API"? The Lua interpreter supports everything.

I meant to say a modding API. I r tu lazee to luk at teh codezz

[GreaseMonkey]

If you want players to continue to have eyes, hurry up and make a replacement model before the next Windows release.
Iceball devs: don't say a word.

I've noticed that bullets tend to come out of your eyes instead of the barrel of the rifle. Probably because the camera viewpoint is in the head of the model itself (because you can see your feet). If you would make them come out of the rifle, the bullets would end up not hitting where the crosshair is aiming at close range like in Sub Rosa (this could be ruled out with proper ironsight models). Or to fix this, the crosshair can be dynamic.

I ultimately want the crosshair to be perfectly on the target, so shooting from the head is the easiest way to deal to it. But I might look into dynamic crosshair.

Highest priorities should be:
1. Improve performance

3. Make it actually work on old pcs

These are the same point.
Not the highest priority, sorry. I believe the highest priorities are on the Lua side of things, mostly getting the code cleaned up so it's easier to add stuff. Having said that, I seem to be exceptionally good at procrastinating the high priority stuff. With that said, I don't want to make the code any slower than it currently is right now.

2. Implement a proper lua API.

The C<->Lua API is reasonably "low-level", and if you need any "high-level" stuff, you do that on the Lua end. Trust me, it's much nicer than this horrible piece of shit. (Sidenote, not all hardware is a steaming hunk of shit to code for. I personally find this thing wonderful. This older standard on the other hand is a complete prick.)

But as you've elaborated with respect to this actually referring to the modding API, I would say that is a reasonably high priority, but it's a rather annoying one too as it involves refactoring. Feel free to help document, though!

I r tu lazee to luk at teh codezz

Stop being so lazy. Also, this MIGHT be useful.

I have a question, how long have you guys been programing and what are your tips for future indie game devs?

Since I was 9, and I'm turning 22 in a few months.

1. Download Linux and install it. A VM doesn't count. You need to install it on your hard drive or you won't be "invested enough". Then you need to force yourself to boot to it and not Windows/Macintosh. It's true you almost everything you want without the terminal these days, but the truth is the terminal is better. Once you are used to Linux, try to use the terminal more.

^ This.

• Don't just use python or Ruby, Java or C#, C++ or C. Try a bunch of different languages. I recommend Haskell, Ocaml, or Scheme.

Haskell, Ocaml, and Scheme are "functional" programming languages. There's also something slightly related called Prolog, which is "goal-oriented" or something. Personally I don't use the former three (though I know some Haskell and some Scheme), and I occasionally use the latter to solve certain problems.
Having said that, I do recommend that you play around with Ruby and look for interesting ways to do stuff. (Python and Lua also count, but they're not quite as feature-packed.)
Those there are "high-level" programming languages. I recommend you learn C as a low-level language, as it's fairly close to the metal, as well as still managing to be reasonably "portable". I personally don't like C++. C# isn't low-level and in my view you shouldn't even bother learning it. DO NOT BOTHER WITH VISUAL BASIC.
And then of course, I suggest you also, every now and then, dive a bit lower and look into assembly languages, e.g. 32-bit x86 assembly would be appropriate for most people here. This should give you some insight into how your CPU works. If you want to play around with some of the older computer hardware, Z80 and 6502 assembly are worth looking into, as you can actually count stuff in CPU cycles and you don't have to worry about pipelining or caching or anything (depending on the base hardware; the ZX Spectrum has a 16KB range which will pause the CPU for a few cycles if you do anything with it, the Atari 800 also has a bit of cycle stealing going on, and the Commodore 64 is well known for doing it wrt video timing).

• Do something open source. Either start you own project open source or contribute to someone else's.

Such as iceball! :D But yeah, any project that looks good. I got into C programming when I was tinkering with Rocks 'n' Diamonds.

[rakiru]

I r tu lazee to luk at teh codezz

Stop being so lazy.

This. ^

I have a question, how long have you guys been programing and what are your tips for future indie game devs?

Since I was about 13 (I messed around modifying existing programs occasionally before that (like making explosions bigger and stuff), but I don't really count that since I had little idea what I was doing. I'm almost 21 now.
I agree with the suggestion to contribute to something opensource. Even if you don't contribute straight away, you can learn a lot just by closely following an existing project, seeing their methods and decisions and how they made those decisions.
Also, if you look back at something you wrote a couple of months ago and don't at least go "eh, wtf" you're either perfect, or doing something wrong, since that's a good indicator that you've improved since then.

[Sonarpulse]

There's also something slightly related called Prolog, which is "goal-oriented" or something.

Ah I have been meaning to try Prologue. @JDrew, it's basically straight predicate logic, "For all" "there exists" "such that". Stuff like that.

Haskell, Ocaml, and Scheme are "functional" programming languages. There's also something slightly related called Prolog, which is "goal-oriented" or something.

I am a huge fan of functional languages. Haskell is pretty crazy to start with, but scheme is arguably the simplest language. Even if you don't end up using them later (boo hoo if that's the case), they will open doors that would just be too remote if you were doing C or assembly. These things teacher you how to be clever as fuck.

Also for the record Ocaml is "multi-paradigm" (more than scheme is by a lot). It and Scala are sort of the do-it-all languages. And BTW if you ever feel the urge to use java, learn Scala instead. Then try some java and you will laugh and cry at java's weaknesses.

DO NOT BOTHER WITH VISUAL BASIC.

^REAL TALK

And then of course, I suggest you also, every now and then, dive a bit lower and look into assembly languages.

I learned C and asm together, which I think was good. C is actually useful, but asm might actually work better in terms of teaching you low level concepts.

MY FINAL CONCLUSION:
I should have said this before, but I think the best thing you can do is pick a really high level language and C+asm and learn them both at the same time. One is not better than the other. At first what you learn with high language will not seem related at all to what you learn with C/asm, but there will be a moment one something clicks and all of the sudden you will understand the high and the low and everything in between.

[XxJJX]

At first what you learn with high language will not seem related at all to what you learn with C/asm, but there will be a moment one something clicks and all of the sudden you will understand the high and the low and everything in between.

How profound.