branchsbox/managed-gamedatacancel

23 Commits over 31 Days - 0.03cph!

3 Years Ago
In Tools mode add all LocalAddon games to ServerAddons to compile as game opens save package idents in vmap ( e.g facepunch.dm98, valve.cstrike ) from used map entities, download these pkgs on map load if missing locally
3 Years Ago
Sandbox.Tools gets addons compiled from Sandbox.Engine - Hammer uses these instead of recompiling them itself plus they're avaliable for other tools to reflect on too
3 Years Ago
Obsolete [Spawnflags] it's confusing for mappers and hacky to implement - you should use a property of an enum with [Flags] on it Removed Spawnflags from BaseTrigger, the only flags that did anything were Clients|Everything - everything should just work with tags instead. FuncPhysbox spawnflags turned into a flags enum property instead (old maps will still work just fine) Get rid of FGDType( "flags" ) usages, we just derive this automatically now from [System.Flags]
3 Years Ago
C# GameData.LoadConfig should be synchronous so Hammer blocks until everything is loaded - actual loading from each dll is still done in parallel though
3 Years Ago
Enum properties create and populate their backing native GDIVItemSet New: Enums marked with [Flags] now get treated as flags properly in Hammer now Restore Hammer.CustomHeaderAttribute but obsolete it so it doesn't break older addons
3 Years Ago
GameData (.fgd) is now managed, game entities are now loaded at runtime from their type information instead of from .fgd files. This also runs both ways and let's us access all GameData from C#. * Managed classes for GameData, can be loaded directly from LocalAddon or RemotePackage. * Map compiler doesn't load .fgds, make Hammer serialize g_pGameData to KV3 and load it in the map compiler * Clean up native GameData code (fgdlib) making it a shit load less confusing to work with, name globals, classes, vars.. properly, delete legacy code, document stuff etc. * Copy native GameData (loaded from core .fgd) back to C# GameData for usage in tools addon * [Hammer] attributes rewritten to not use StringBuilder, pass dictionary / list references and fill those up, obsolete the old tihngs * Remove FGDWriter for game entities, no longer need to serialize it every game start * Remove .fgds of anything that has a managed type, remove legacy syntax on remaining .fgd files (use KV3 so we can remove a lot of code) Give all entities nice [Display, Category, Icon] attributes Glue Hammer Entity tool UI to C#, can use entities for games straight from here, searchable, show what game it's from etc. needs a bit more work to not look shit though
3 Years Ago
read/write files properly you twat Set CGameDataClass parent properly when reading from KV3 load our serialized gamedata here in the map compiler too
3 Years Ago
Make map compiler load GameData from temp KV3 written by Hammer, instead of trying to collect and load fgds again, especially since we're not using fgds for managed stuff.
3 Years Ago
Entity tool searchable entities and toggle to display ent_class_names give a shit load of entities nice [Display] names Make paths and path nodes work with new hammer entity shit Entity selector should only show entities
3 Years Ago
Obsolete [Hammer.EntityTool] names & categories should be set with [Display, Category] and descriptions should be /// <summary> ... </summary>. Entity Tool will show these friendly names / icons over class names.
3 Years Ago
Add [Hammer.PhysicsSimulated] this hints to the map compiler that the entity is simulated in game and should pre-settle. Internally replace BasePhysicsSimulated @baseclass check with PhysicsSimulated tag and replaces the hacky solution I had implemented with .fgds previously. Make all these [Hammer.] attributes make helpers, metadata, etc. with dictionaries / lists instead of a stringbuilder to fgd format
3 Years Ago
Add MetaData for classes, turn it into native KV3 Add PropertyTypeOverride for MapVariable for some shit we really just can't derive from a C# Type [Hammer.CanBeClientsideOnly] adds its variable
3 Years Ago
Sort out the C++ side of fgdlib so we know wtf is going on, organize our C# interop nicer because of it. * Split fgd file parsing away so we have more ownership of GameData and it's way less confusing. * Classes, variables, globals are named properly e.g pGD -> g_pGameData (it got very confusing when pGD is a parameter name everywhere too) * Document what GameData is & how we use it in s&box. * Sort out code stink, unnecessary long compile times and remove some headers that haven't been used in the past couple of decades. Add "point" and "solid" tags to applicable managed gamedata classes, Hammer likes to use these over the type for some things Don't mix AssemblyLoadContexts, I've one this part all pretty wank need to revisit this bit later. Implement Inputs and Outputs, the parameter types make more sense now and entity parameters should work now too. Remove map entity related stuff we've already ported to our tools from FGDWriter
3 Years Ago
AccessControl check remote packages in Hammer before loading them GameData::AddClass sets the classes parent to itself properly Copy editor helpers and tags to native GameData, add standard base properties "parentname", "local.origin" etc. (is there a reason these aren't just on the Entity class as normal properties?) Implement property type overrides so I don't fuck up backwards compatibility, we can iterate on if these are needed later Adjust Hammer.MetaDataAttribute to accept Lists for metadata & helpers, implement even more Hammer attributes (there are a lot..)
3 Years Ago
Load all entities from our local base addon dll Make resource types on properties work properly, Texture Model etc. - handle Tags on map classes and start parsing [Input]
3 Years Ago
Map class variables type themselves from the C# Property Type now and their default value is set too. Clean this shit up using partial classes keep it nice and tight.
3 Years Ago
Add entities to Hammer GameData straight from games assembly data (skipping fgd) Use an AssemblyLoadContext for game binaries in Tools/Hammer so we can use real Reflection instead of Cecil We can load entities from remote packages too, put it all into a simple `Hammer.LoadEntitiesFromPackage( "facepunch.minigolf" )` Clean up GDVar code a bit to keep our changes manageable, we don't need S1 fgd parser or game units/items Turns out we were using the legacy stuff, switch it all over to KV3 Populate entity gamedata properties Make structured MapClass w/ mirroring to native GameData so we have access to map entity classes in managed easily Port Hammer Entity tool to C#, can pick s&works games from within the tool and use the game entities straight away Don't output entities with FGDWriter Load entities from all active LocalAddon when Hammer is started, split the API for local/remote package to make it saner Load entities straight from Sandbox.Game.dll too Hammer: don't load any .fgds from addons, we only load core/fgd/s&box.fgd now for remaining C++ entities Remove DotaMaxTrees Load managed GameData after engine fgd is read, copy native engine entities to our managed lists and then mirror our managed game classes back to native Copy variables to native Make our entity tool properly functional and less shit, add a button that pops up a dialog to use entities from remote games.
3 Years Ago
Remove DotaMaxTrees Load managed GameData after engine fgd is read, copy native engine entities to our managed lists and then mirror our managed game classes back to native
3 Years Ago
Load entities straight from Sandbox.Game.dll too Hammer: don't load any .fgds from addons, we only load core/fgd/s&box.fgd now for remaining C++ entities
3 Years Ago
Don't output entities with FGDWriter Load entities from all active LocalAddon when Hammer is started, split the API for local/remote package to make it saner
3 Years Ago
Clean up GDVar code a bit to keep our changes manageable, we don't need S1 fgd parser or game units/items Turns out we were using the legacy stuff, switch it all over to KV3 Populate entity gamedata properties Make structured MapClass w/ mirroring to native GameData so we have access to map entity classes in managed easily Port Hammer Entity tool to C#, can pick s&works games from within the tool and use the game entities straight away
3 Years Ago
Add entities to Hammer GameData straight from games assembly data (skipping fgd) Use an AssemblyLoadContext for game binaries in Tools/Hammer so we can use real Reflection instead of Cecil We can load entities from remote packages too, put it all into a simple `Hammer.LoadEntitiesFromPackage( "facepunch.minigolf" )`
3 Years Ago
Add entities to Hammer GameData straight from games assembly data (skipping fgd)