[QUOTE=UnkN;50031408]Why net.WriteType send type with net.WriteUInt(8)? 8 means that we can use number from 0 to 2^8-1, but types lower than 64. Every time when we use this function, we lost 2 byte because they aren't used. So examine yourself, if we use net.WriteTable with many values we send 2*2*value unused bytes. I know, what it funny, but use net.WriteUInt(6) is better.[/QUOTE]
We're coming to the stage that there's very little you can change in implementation without breaking [I]some[/I] addon. Even making use of PerformLayout parameters like Robotboy did in DCheckBoxLabel can't be done anymore (will that making use of Paint parameters pull request cause issues?).
It tends to be bad decisions of the past (eg. the requirement for addons to read the type int themselves) that are starting to cause problems now.
[QUOTE=UnkN;50031408]Why net.WriteType send type with net.WriteUInt(8)? 8 means that we can use number from 0 to 2^8-1, but types lower than 64. Every time when we use this function, we lost 2 byte because they aren't used. So examine yourself, if we use net.WriteTable with many values we send 2*2*value unused bytes. I know, what it funny, but use net.WriteUInt(6) is better.[/QUOTE]
you have bits and bytes confused.
[QUOTE=Joeyl10;50031596]you have bits and bytes confused.[/QUOTE]
Yeah sure, I confused because net.BytesWritten return 4 if I use net.WriteUInt. But you understand whats I mean.
Also when I worked on OpenGL I can easily unload textures from buffer, so when we can do that in gmod? For example for every player render makes 7 unique textures, I wanna that if player out of PVS, then their textures are unloaded from buffer.
[QUOTE=highvoltage;50030370]Cause people will still bitch and moan about not knowing about the mailing list, or not being able to test stuff themselves or that things should never ever change in the first place[/QUOTE]
As Noi said the current method is really inconvenient for those of us who don't spend a lot of time on FacePunch and having to read 20 pages in the hopes we find that an update may be coming out soon to have time to test our shit.
How would a mailing list hurt? Them not knowing about it if it's in the OP can't really be excused after it's been about a month or two. Then them not being able to test stuff themselves, I don't know what you mean by that; and with people bitching about things that shouldn't be changed in the first place, well we're always going to have those.
The game is based around mods for fucks sake, we need more convenient ways to know when all our stuff is going to break other than having to check a thread daily in the hopes nothing has been changed or having to redownload the dev branch every time we want to check. A mailing list is a damn sight better than what we have now.
Mailing lists, telegram, phone calls, actual telegrams, snail mail, smoke signals, the ultrasonic sound of Garry masturbating
Why don't we use the things we already have? Garrysmod.com and steam announcements. Those would do fine! It reaches the right people and you don't need to install anything to get the messages.
[QUOTE=Noi;50032480]And Telegram is just future of messaging/mailing.[/QUOTE]
You got to be mental to believe anyone is going to do that. Steam Discussions would work perfectly fine, you can Subscribe to a Forum and it can be set to allow only Moderators/Devs to post there, simple enough.
What about a small window or scrolling banner on the main sandbox menu with update news like most games have today?
I vote for a Steam group or discussions page. You could then easily promote that on Garry's Mod itself. A live feed in-game would be cool too.
[QUOTE=The Commander;50032677]What about a small window or scrolling banner on the main sandbox menu with update news like most games have today?[/QUOTE]
Think of people that only play without any development, they don't care and its probably confusing them plus its something that shouldn't be Sandbox specific. I really don't understand why it has to be super fancy, Steam Discussions would work perfectly fine you even get a notification in Steam if you subscribed, its exactly what everyone wants without any additional work.
The only reason I said it should only be on the sandbox menu was because someone may not want it on their custom gamemode.
[QUOTE=Noi;50032771]There's no mail box for steam announcements.[/QUOTE]
[url]http://steamcommunity.com/games/garrysmod/announcements/[/url]
Subscribe to RSS feed.
When will fonts be downloadable from Workshop DL? I'll finally be able to abandon trashy fastdl after that.
[QUOTE=The Commander;50032757]The only reason I said it shouldn't be on the sandbox menu was because someone may not want it on their custom gamemode.[/QUOTE]
Why not?
RSS feeds are how "In the News Node" works and clearly RSS is useful here too
[QUOTE=Britain;50032877]When will fonts be downloadable from Workshop DL? I'll finally be able to abandon trashy fastdl after that.[/QUOTE]
Everyone has been asking this for a long time.
[QUOTE=BillyOnWiiU;50032879]Why not?[/QUOTE]
They may have custom backgrounds that may clash with it etc.
[QUOTE=Noi;50032892]There is only releases (post-factum info, meaning no pre-release messages), you don't get notifications of updates to released posts.
And, RSS, in 2016, seriously? This technology pretty much died out, it was overhyped when it was first released, but then its popularity went down over time, which made Google shut Reader down.[/QUOTE]
[img]http://i.imgur.com/AVOwtEt.png[/img]
Also, you're asking for [I]mailing lists[/I] and then you complain about RSS being an ancient technology!?!?!?!?
For crying out loud, RSS + [url=https://www.feedmyinbox.com/]Some website[/url] [B]IS[/B] your mailing list!
[url=https://blog.superfeedr.com/rss-bot-telegram-lambda/]You even get your telegram option!![/url]
----
Benefits of using GMod steam announcements:
- Noi gets his mailing list
- Noi gets his telegram thing
- Everyone is notified on the news with the little pop up thing on the bottom right of your screen
- You can import that shit in your RSS news reader (if you have one, I do)
- If you don't want to, you don't need to subscribe to anything to get the news
- No need to install software to get the news
- Very little effort for the GMod devs. Everything is there already.
Just make sure to inform people (Somehow) about the RSS method, otherwise we are still gonna have a bunch of people complaining.
[QUOTE=Yashirmare;50033574]Just make sure to inform people (Somehow) about the RSS method, otherwise we are still gonna have a bunch of people complaining.[/QUOTE]
The RSS is just an option for those who want to watch the news more closely than they would with just the steam notifications.
I still feel like the best way of branching would simply be keeping compability when possible. Many users like being on the cutting edge. Even garry took advantage of that and joined some servers with a more recent version of garrysmod ( even though he got banned by some anticheat :v: )
[QUOTE=Leystryku;50034096]I still feel like the best way of branching would simply be keeping compability when possible. Many users like being on the cutting edge. Even garry took advantage of that and joined some servers with a more recent version of garrysmod ( even though he got banned by some anticheat :v: )[/QUOTE]
Sorry to disappoint but it wasn't the real Garry, just some guy with a Steam ID manipulator :(
I'd just like to see if we're all on the same page here. This is the current consensus, as I see it, plus some technicalities that I took the liberty to add:
1. New releases would be [b]announced ahead of time[/b], using the [url=http://steamcommunity.com/games/garrysmod/announcements/]Steam Announcements system[/url] which allegedly notifies all users via Steam notifications (personally I never saw it but I trust you guys). It also features an RSS feed for people to hook into however they like.
2. Starting from the moment of announcement, the [b]Release Candidate[/b] would be available via dev branch for at least a certain amount of time - I say a week, but this is up for debate. Let's call this time period the [b]buffer period.[/b]
3. During this time, all addon developers are expected to ensure compatibility with the Release Candidate. At the same time, any new bugs that were accidentally introduced to the game are expected to be caught, as more people are expected to enable the dev branch while in release candidate status.
4. Any new bugs found in the release candidate [b]are expected to be fixed[/b] by the developers, after which the release candidate would be updated and the buffer period would begin anew.
5. After the buffer period ends, assuming there haven't been any new bugs discovered, the release candidate would be pushed to the live branch as an official update.
Did I get any of this wrong? Any disagreements/refinements?
OK, update on the update... :v:
Here are the new changes to the game:
[code]
* Fixed checkboxes being fucked up for some people who improperly call PerformLayout
* Fixed SLAM sound being played on death
* Fixed Ceiling Turret playing Alert infinite sound after being removed
* Fixed ents.FindInSphere clientside working as ents.FindInBox
* Fixed the problem with DTextEntry (GitHub)
* Removed unused html files
* Fixed face poser not posing the last flex on some models (GitHub)
* Fixed npc_grenade_frag creating new effects when picked up by gravity gun without deleting the old ones
[/code]
These are not on Dev, they will be once Willox fixes the font or w/e issues with the update sometime this or next week.
You should also fix ents.FindInCone, its been forever broken and theres solution for it somewhere in facepunch, if needed i can link it.
[QUOTE=Bings;50034508]Sorry to disappoint but it wasn't the real Garry, just some guy with a Steam ID manipulator :([/QUOTE]
It was prior to the clientside steamid spoofing, aka few years ago.
[QUOTE=kulcris;50027218]what exactly does net_max_fragments do, google doesnt reveal many results[/QUOTE]
[QUOTE=kulcris;50036433][/QUOTE]
"net_maxfragments" = "1260" min. 256.000000 max. 1260.000000
- Max fragment bytes per packet
I assume you mean "dev branch" as in GMod 13 Beta being a separate game. No more branches on GMod itself, please. I will go absolutely insane if there's 3 branches of 1 game and I'm expected to keep up everything in sync with all of them and I don't think it's far-fetched to say I'm alone there.
The default branch for GMod 13 Beta separate game would be "release candidate", with the option to switch to "dev".
Kinda like how Windows does the insider ring
[QUOTE=Zeh Matt;50037166]"net_maxfragments" = "1260" min. 256.000000 max. 1260.000000
- Max fragment bytes per packet[/QUOTE]
..... doesnt explain a whole lot lol.but from what i can gather there would be no reason to change it?
[QUOTE=Robotboy655;50034600][code]
* Fixed ents.FindInSphere clientside working as ents.FindInBox
[/code][/QUOTE]
Thanks for this.
[QUOTE=Banana Lord.;50037170]I assume you mean "dev branch" as in GMod 13 Beta being a separate game. No more branches on GMod itself, please. I will go absolutely insane if there's 3 branches of 1 game and I'm expected to keep up everything in sync with all of them and I don't think it's far-fetched to say I'm alone there.
The default branch for GMod 13 Beta separate game would be "release candidate", with the option to switch to "dev".
Kinda like how Windows does the insider ring[/QUOTE]
Well actually, I meant that the dev branch would be temporarily repurposed for the release candidate, so pretty much like it works now except you'll have more notice time.
However, another (better?) option is the way DarthTealc understood it: a third branch called Release Candidate. But don't fret! This option has its advantages too: the release candidate branch would be identical to Live at all times unless there's actually an upcoming update.
That means that instead of running Live, you could set it to always run on RC and still play with everyone on Live (the identical version). As soon as a release candidate goes live you would be updated. If there are any game bugs you can report them and switch back to live until they get sorted out. If not you can ensure your mods work on the RC, and prepare to update them publicly on the release date of the next update.
So the 3-branch approach would have:
1. Live: the latest stable release
2. Release Candidate: same as Live but updated 1 week earlier
3. Dev: for testing and working with upcoming features before they are guaranteed stable
What are the downsides of this? I honestly can't see any. You only need to maintain your addon for Live. Release Candidate is there to help you do it, and dev is irrelevant if you don't need it. You don't need to keep anything in sync.
Sorry, you need to Log In to post a reply to this thread.
