Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
2.6.2 (2.7 beta 2)
11-22-2014, 03:05 PM,
RE: [Future] 2.7
@xdEpicZombie, a new project could be a fork of Tesseract or Red Eclipse. I plan to get ACR 2.7 at least to a point where it is better than 2.6.

@DeltaStrikeOp, if the HUD weapon models are edited, perhaps it will work under AC's HUD gun FOV. This makes it easier to use AC weapon models in ACR and ACR weapon models in AC.
The ADS mechanism has also changed (you can have shoot/reload animations running at the same time as ADS, which is a tag), also allowing easy usage of ACR models in AC (the zoom tag will be ignored in AC.

If anyone writes a list of what needs to be fixed in 2.7, it would be very helpful. Hopefully, it will be done before December 22, when I'll probably have time to work on ACR.

Best regards,
Your antithesis compares favorably with any high magnitude of pwnage. (-you > |p|, you < -|p|)
My antithesis compares favorably with _that of_ any high magnitude of pwnage. (|-me| > |-p|, |me| > |p|)
11-24-2014, 01:19 AM,
RE: [Future] 2.7
@Victor, I believe a poll should be made before ACR proceeds to have its default FOV reverted back to AC settings. One could argue that AC will see this move as an attempt to further "steal" from their game. Not many of us really jumped onboard the ACR train with the intention to have a game that felt exactly like AC. Perhaps only retain AC's FOV in the Classic gamemode

Windows 8 fanboy =D
"Not dead, can't quit"
11-24-2014, 07:13 AM,
RE: [Future] 2.7
im interested in the new anim tags... can i see an md3.cfg file?

[Image: cooltext1203588761_zps9cfa0053.gif]
11-25-2014, 02:14 AM,
RE: [Future] 2.7
New anim tags ?

11-25-2014, 08:43 AM,
RE: [Future] 2.7
You can browse through for the md3.cfg files
11-25-2014, 09:22 PM,
RE: [Future] 2.7

ACR HUD models will have to be readjusted to make the FOV work properly. This means that models would have to be made to suit one FOV.

Since ACR models can be used for AC, we are also helping to provide models for them, so it works both ways.

However, ACR's smaller HUD model FOV makes the iron sights look better.

Perhaps we should have a poll and get the modellers to vote.

Best regards,
Your antithesis compares favorably with any high magnitude of pwnage. (-you > |p|, you < -|p|)
My antithesis compares favorably with _that of_ any high magnitude of pwnage. (|-me| > |-p|, |me| > |p|)
11-26-2014, 04:00 PM,
RE: [Future] 2.7
I understand we want a sort of uniformity between AC and ACR. The question is why.

There haven't been any requests from players from either game to import models to their game. You mentioned that we need to also fix some HUD models and the impact based on the iron sights. Isn't ACR more geared towards some sort of "realism"? As far as I know, ACR's FOV looks more realistic than the "giraffe" view in AC and CS-style games.

This isn't a threat, but I'll probably retire from ACR if the FOV is kept AC style. I'll finish the killstreaks though. Going back to AC isn't really what I had in mind while the game matured.

Windows 8 fanboy =D
"Not dead, can't quit"
11-27-2014, 10:28 AM,
RE: [Future] 2.7
Standing besides DSO here,I don't understand this either.

[Image: 3SVsNlV.png]
11-27-2014, 02:13 PM,
RE: [Future] 2.7
the idea is that every cube has sub-cubes, there are two preferable ways to implement destruction

1. Animation (works)
animating destruction is far more easy than implementing a full scale physics system.
not to mention physics suck in here :c
examples will suffice
if a grenade explodes on the ground the following will happen.
a "model" if you will
of flying rock/debris will begin at the point of explosion. (where the grenade went off)
Next a black scorch mark texture will be placed on surrounding map models /or walls.
the texture will remain until the game is over
2. Physics ( i'm always on the road of physics )
a set(s) of cubes inside other cubes "sub-cubes" if you don't mind
examples will suffice.
when a grenade goes off nearby cubes will release a set of sub-cubes.
these sub-cubes will react the way they should in a normal physical environment. its best to simulate these in a similar way that bullets are simulated. (Ricochet)
The pieces will move in a outward direction, expanding, until the force of all these pieces become 0.
The Pieces will move at a regulated speed and can effect other cubes.
If I throw a grenade and it explodes next to a wall, the animation method will load the "explosion" model. This model will simulate rocks/debris flying in an outward direction.
(unfouranatley that means no realistic richochet and a few physics issues ( passing through walls :OOOOOOO )
then a scorch mark will be set in the area that the grenade exploded with a set radius of scorch mark's range



debris.location = grenade.location;

if(i=0;cube[x].location == (grenade.location.x+=5 || grenade.location.x-=5) //if cube is near explosion lol
cube[x].explodes(); //not realistic but you get the point



Very easy (well easier than physics)
probably more attractive because we could throw up some high quality smoke animation and call it fair cause its beautiful.
keeps a nice frame rate
With all goods come bads.
physical glitches such as debris passing through walls, smokes passing through walls etc.

very realistic
nice effects can be added
a wear and tear experience (you can see things you've previously done damage to
very cumbersome to implement...not hard but takes time
perhaps some minor performance issues (although they might not be noticeable

hopefully you all get the idea.
my personal opinion says physics are better and that if the engine can find its way to support it we wont have performance issues (performance issues would be hard to find if your use to 200fps and your running 120)
but animation can never be crossed out because of its simplicity.
That's up to you guys, perhaps a poll would do. Ill post a poll, although i doubt many responses will be received. What ever way you all pick ill try my best to get it down.

just a update on me
I'm in a c++ class as of now and learning a bit more than i use to about it but mainly math ,
picked up a neat little tutorial on objective c which is a little fun ;0 I'm planning on developing the mobile ACR if any of you guys are interested... neat little project
modeling is going down, access to a computer is harder for me. My PC currently STILL in upgrading ;'(
my game is going moderately well, right now I'm in the pre-coding stage, sdk here and there, the usual.
im trying to learn the most i can in geometry, I'm hoping to get a nice graphical fidelity lesson in there c:
Dubstep is at a all time high for me and the usual audio development is coming on.
weaponry sounds are high on my list c; as well as natural sounds (*water,wind,birds,)
uploading some forest sounds today when i finish getting them to loop right :c
And I play ACR at school with my buds now! all is well C:

and VERY IMportant thing right here

ACR 2.5.9 will run fine but 2.6.0 and the Beta will not run unless I resinstal OpenAL.dll ???!?!?!?!?!
Me and my friends love acr alot but cannot get the full experience when we cannot install openal.dll ( the actual install file needs admin rights to install, so i was hoping in the 2.7 that openal.dll would be prepackaged in the Assault Cube Reloaded/bin_win32 folder by default. Im making a little program right now that will extract the openal.dll if run by the user. C: hopefully that'll solve that. and HEAL GUN MODEL IDEA is siiiiicccckkk i have an idea for the heal gun thats going to be pretty sweet so stay tune!

God must love stupid people. He made so many.

[Image: 8VEZK0Q.gif]
11-29-2014, 11:49 AM, (This post was last modified: 11-29-2014, 11:56 AM by Victor.)
RE: [Future] 2.7
@DeltaStrikeOp and @@xdEpicZombie, the next release will have the default HUD model FOV set back to 55, and an option will be added for HUD models to use a custom FOV. It makes more sense if this FOV looks more realistic.
This has been added to the first page of this thread.

For reference purposes, the FOV was 55 in 2.6 and is 75 in 2.6.1.

@Fru5trum, adding "sub-cubes" is not that easy to implement. Also, your "code" doesn't make sense.

However, adding something to automatically rename `openal32_RemoveThisPartToUseOpenAL-Soft.dll` to `openal32.dll` might be a good idea.

Best regards,
Your antithesis compares favorably with any high magnitude of pwnage. (-you > |p|, you < -|p|)
My antithesis compares favorably with _that of_ any high magnitude of pwnage. (|-me| > |-p|, |me| > |p|)

Forum Jump:

Users browsing this thread: 1 Guest(s)