MT 94-20131104 - Page 5

MT 94-20131104

Post just about everything that isn't directly related to Spring here!

Moderator: Moderators

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: MT 94-20131104

Post by smoth » 07 Jan 2014, 01:18

AntiAllez wrote:laggy and bugged
bugged very descriptive of you.
AntiAllez wrote:seriously, which mods working on it? BA TechA ... the rest is still on 91, 94 or awaiting 96
Any mod that was ported the rest stubbornly stayed in the old spring. Eh it doesn't matter, players like you only count something that has players all the time.

I dunno, I have a project, it has run in all version just fine. I guess your hardware is low end?
0 x

User avatar
AntiAllez
Posts: 105
Joined: 06 Mar 2012, 18:22

Re: MT 94-20131104

Post by AntiAllez » 07 Jan 2014, 18:54

smoth wrote: Eh it doesn't matter, players like you only count something that has players all the time.
a very common phrase of your species in this community :mrgreen:

seems its a must have to be macgyver to play on springgames
Image
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: MT 94-20131104

Post by smoth » 07 Jan 2014, 19:01

ok, I guess we are done.
0 x

luckywaldo7
Posts: 1397
Joined: 17 Sep 2008, 04:36

Re: MT 94-20131104

Post by luckywaldo7 » 08 Jan 2014, 02:17

jamerlan wrote:
Jools wrote:You should benchmark vs spring 95 or 96...
Sad but r-t-s-m-p is spring 94.1 based.
You might even say that Spring 96 is also Spring 94.1 based!
0 x

User avatar
Jools
XTA Developer
Posts: 2804
Joined: 23 Feb 2009, 16:29

Re: MT 94-20131104

Post by Jools » 08 Jan 2014, 06:35

luckywaldo7 wrote:
jamerlan wrote:
Jools wrote:You should benchmark vs spring 95 or 96...
Sad but r-t-s-m-p is spring 94.1 based.
You might even say that Spring 96 is also Spring 94.1 based!
Yes, this is what I meant. It's just a number, but since most people now play spring 95 and soon 96, what's the point of benchmarking against an old version?
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: MT 94-20131104

Post by smoth » 08 Jan 2014, 14:06

Because trolls? People like to whine and bitch about how shitty things are seldom giving actual details. I have come to the conclusion for whatever reason, there are people here runing either shit rigs or they generally like to cause discord

*edit* before some overly sensitive or trollish person starts. You have only to look at the antiallez convo above to see the obtuse responses he gave accompanied by trollish behavior to see what I mean
0 x

User avatar
AntiAllez
Posts: 105
Joined: 06 Mar 2012, 18:22

Re: MT 94-20131104

Post by AntiAllez » 08 Jan 2014, 22:48

I dont see a shred of approach in your last contributions of even begin to help anyone on here concerning the topic. But nice to have made ​​your acquaintance
smoth wrote:ok, I guess we are done.
Why you love to bend your own rules? that makes me sad


You dont like my behavior into respond your kiddish questions? To short news for you? Im pretty sure you noticed that list -that just showing that things what they/you believe to have solved. It is currently a horror with ATI/AMD. But well, what a surprise, the community consists of human and not from bark critters which can be lead to the slaughter bench. Maybe you need to fix that by bots

Code: Select all

Major:
 - kill memory leaks crippling large games (#4152)
 - kill micro-jitter in simulation framerate (#4171)
 - kill unclean exits causing various forms of corruption (#4053)

 - "nugget" is hereby officially promoted as the new umbrella term for widget or gadget

Misc:
 - default disable grass for ATI cards (crashes for some people)
 - made stacktrace-translation script recognize more crash/hang patterns
 - improve Shard AI for BA
 - fix some MSVC compile errors
 - TimeProfiler (alt+b) shows now max `lag` of each item
 - massively speedup caching with many .sdd archives
 - fixed some FreeBSD compile issues (thx AMDmi3)
 - dump (engine) shaders to infolog when they fail to compile
 - more extensive logging during shutdown
 - fix a number of potential issues if a thread crashes on engine shutdown
 - increase precision of several timer variables to preserve intermediate results
 - Lua: track more memory-allocater statistics for display in debug-mode
 - Lua: limit maximum amount of memory allocated globally and per handle
 - GameServer: always echo back client sync-responses every 60 frames (see #4140)
 - GameServer: removed code that blocks pause / speed change commands from players with high CPU-use in median speedctrl policy
 - GameServer: sleep less between updates so it does not risk falling behind client message consumption rate
 - LuaHandle: make time and steps spent on garbage collection configurable
   CollectGarbage callin is restricted to run for at most
     MaxLuaGarbageCollectionTime (user-configurable) millisecs
     MaxLuaGarbageCollectionSteps (user-configurable) iterations
 - GlobalConfig: add new config-option 'UseNetMessageSmoothingBuffer' (see #4053)
 - LogOutput: make enabled 'section' log-levels configurable by users
 - MoveDef: add key 'allowTerrainCollisions' for handling units with super-sized footprints (see #4217)
 - SolidObject: make {Unit,Feature}{Pre}Damaged events receive the 'attacker' ID when object is crushed
 - QuadField: add raytraced projectiles to three cells instead of one
 - GameInfo: add map hardness label/value to 'i' overlay

Sim:
 - Rifle weapons can hit features too now and apply impulse to the target

Lua:
 - add gadgetHandler:AllowWeaponInterceptTarget
 - LuaSyncedRead:
     make Get{Unit,Factory}Commands (optionally) return just the queue's size
     (ie. without copying the entire command queue into Lua VM memory, *VERY*
     important for performance when a nugget is not interested in the commands
     themselves)

     "if #Spring.GetCommandQueue(unitID, -1 | nil       ) == 0 then return end" --> BAD, CREATES COPY OF QUEUE
     "if  Spring.GetCommandQueue(unitID, -1 | nil, false) == 0 then return end" --> GOOD, DO THIS IF POSSIBLE

Bugfixes:
 - fix #4215 (stack-buildable units on non-flat terrain)
 - fix #4209 (antinukes firing at nukes targeted outside their area)
 - fix #4205 (air-transports unable to unload hovercraft on water)
 - fix #4204 (float3.* clang compilation failure)
 - fix #4203 (air-transport unable to load units floating on water)
 - fix #4202 (S3O textures loaded multiple times instead of being cached)
 - fix #4200 (secret)
 - fix #4198 (amphibious units without waterweapons chasing hovercraft whilst underwater)
 - fix #4197 (units moving right up to their target instead of attacking from range)
 - fix #4186 (log-system crash on exit)
 - fix #4173 ("Error: [Watchdog::ClearTimer] Invalid thread N")
 - fix #4171 (see 'Major' section)
 - fix #4163 (corrupted unit environment reflections)
 - fix #4161 (Spring.Restart failing when path contains spaces)
 - fix #4155 (reverse-built gunships maintain their vertical speed)
 - fix #4154 (calling LUS 'AttachUnit(piece, unitID)' turns following 'Move(piece, ...)' calls  into no-ops)
 - fix #4152 (see 'Major' section)
 - fix #4149 (rendering corruption in DynamicWater mode)
 - fix #4144 (partly submerged units not hittable by non-waterweapons)
 - fix #4145 (depthcharges fired by ships having trouble to reach their targets)
 - fix #4138 (same as #4171)
 - fix #4137 (units randomly switching team-color, old bug with new cause)
 - fix #4135 (ATI driver crash with *disabled* shadows)
 - fix #4133 (cloaked units hidden even when set to alwaysVisible)
 - fix #4131 (units moving to position of manualfire command if outside weapon range)
 - fix #4129 (air-constructors flailing around construction targets)
 - fix #4128 (units stuck in 'skidding' state: repeatedly bouncing on ground while unable to move)
 - fix #4091 (gadget:MousePress() and other unsynced gadget functions not called with LoadingMT=0)
 - fix #4053 (see 'Major' section)
 - fix #3749 ('initCloaked' UnitDef tag overriding user cloak commands for being-built units)

 - fixed wreckage heaps could be resurrected
 - LaserCannon: (once again) fix range overshooting
 - always clamp length of blended wind-vector to [map.minwind, map.maxwind]
 - the 'AllowDeferred*Rendering' config options are now safe to enable
0 x

luckywaldo7
Posts: 1397
Joined: 17 Sep 2008, 04:36

Re: MT 94-20131104

Post by luckywaldo7 » 09 Jan 2014, 03:37

AntiAllez wrote:Im pretty sure you noticed that list -that just showing that things what they/you believe to have solved. It is currently a horror with ATI/AMD.
Instead of bugs, you listed bug-fixes and then your "proof" of bugs was the insinuation that

1) Some bug-fixes did not work (of which you have no examples or proof)
2) Other bugs exist that were not yet fixed (likely, but again you have not a single example)

You didn't outright lie, but that is some serious truth-manipulation. People here are smart, and can see through it. Don't do it; it doesn't make MT look better, it just makes you less credible.
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: MT 94-20131104

Post by smoth » 09 Jan 2014, 03:55

I just stopped reading his posts, I don't really think he has any intention of giving legitimate feedback beyond "LOL SHITSUX" level of responses.
0 x

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6109
Joined: 29 Apr 2005, 01:14

Re: MT 94-20131104

Post by FLOZi » 09 Jan 2014, 17:43

I feel this 'discussion' has run its course.
0 x

Locked

Return to “Off Topic Discussion”