Joined: 13 Jan 2005, 00:46 Location: You are going to die anyway, hurry up and do it.
No all projects call for that.
Aye but as a personal opinion i think alot of mods could do with it. as their current system is either unsightly, looks poorly done or simply hard to find the information for each unit. (not displayed or displayed in a werid palce compared to the unit in question)
i suspect its as forb said that it requires time, effort and skill to create such a thing
Not really that time consuming. Forb just isn't strong in that stuff. Most projects here don't want >9000 health bars over their units.
when you say most "mods" what have you actually looked at?
Since most people have the urge to talk about bars over units instead of the game itself: I have a modified bar-widget and since i already wrote a lot of gadgets, know how to change it as well. So if there will be ammo, there will obviously be an indicator for it. Be it bar or something else. Research is currently only visible in the research-center, but will gain an own (permanent) widget. Infrastructure is there already anyway. Enemy unit health will be invisible and own units might receive a bar, might receive some other indicator.
@Ammo: Energy can not be used for ammo. You know the reason, since you all read the first post carefully. It will not be s44-like ammo. I like the concept, but find in unfitting for my project. Either standard, like in 1st post or maybe with ammo-trucks/planes driving around and automatically supplying the units.
@Models: I will crawl through the model bases later on. Don't know how they play out, since I need individual parts to assemble them on-the-fly. But I definitely need some sort of soldiers in battle-suits soon, maybe I find a kbot, that doesn't look to robotic in there.
Besides the things mentioned on page 1, the game has a custom Case-Sensitive-Gui now. I got the chance to try the module-system with multiple weapons the first time and it worked.
There is an unit-internal communication inplace, so all weapons automatically attack the same target, if in range etc. (See the one unit in the center) Weapons have low hitpoints and could be destroyed by strikes from above for example. That gives arty and aircraft new possibilities.
I liked the idea of lego, but won't use it. The style as such appears to be only useful for buildings to me. By being able to combine different chassis and weapons i can already create a lot of units anyway
See the attached ingame-screenshot.
I rewrote a lot of internal stuff to make it even easier to extend the game with more content, but thats just code, not colors. So don't bother.
File comment: Ingame-Screenshot ingame.png [465.44 KiB]
Downloaded 2 times
Yep. Transport and usefull configuration / gadgetry to make it really work.
looks interessting! i like that you seem to make new original lua instead of making pretty models and then going all "omgomg what scripts can i c&p" [...] if you "custom make" so much stuff, you might as well get rid of the metalmap and use your own system? Might give you more freedom maybe.
You wanna say, the models arent pretty?
Cities are very important and strong, so there has to be a limiter, preventing people from "spamming" them. Consequently, they need fixed points on the map, where they can be placed.
I had 3 Options in my mind: 1) Add Metadata zu maps. Yeah nice, but shittons of work and limiting mapchoice. Hell, no! 2) Use Metal: Metal is (on good maps) placed in a fair, even and thought-over way. The amount can be varied (Tho few maps do it in an interesting fashion. Fixed Metal/Spot=Lame). It is only used once after building the city to calculate its internal production, so there can be cities with different outputs and useless ones (Not on a metalspot) 3) Spawn random information on the map. This can make even bad maps more interesting and prevents 1 Optimal Strategy/Map-Scenarios. But on the other hand I was wondering, how "fair" and "useable" it can get. Both yet to define. By spamming a lot of camo-spots it would, by the law of large numbers, become equal/fair. But there shouldn't be many cities around, i.e. few spots. 3+1) Limit total number of cities, let players place them whereever they want. Just got the idea a minute ago, have yet to think about it.
If you have any idea on how else to distribute or how to optimize the system, drop a message
Joined: 22 Feb 2006, 01:02 Location: cheap kitchen
Not completly sure how your "cities" work in detail but it seems more like few big cities fairly far apart? Well, metalspots are usually one every few meters.
1) Add Metadata zu maps. Yeah nice, but shittons of work and limiting mapchoice. Hell, no!
I think if you use the metalspots it will limit your map choice more in the long run: You will have to find maps where you like the layout, graphics and the metallayout. Unless you make your own maps of course.
(Also note line 23 - 33, you can either include your metadata in the map or in the game.)
I now also use a similiar system for map features & even startpositions. So I basically only use the heightmap and plant trees & bushes as I wish. S44 places its flags on metalspots but they can also define positions in a config file. Imo such systems is much better then being limited by the metalmap or not being able to use a nice map because it has ie trees that are out of scale with your units. Mappers basically only make maps for BA, if you want to use them for your game you have to be creative
I had/have no real clue how maps work, so my assumption was I have to modify the maps or ask the mapper to include special data. Now, that I browsed the source I get the idea and could implement it. Since the resourceamount is only read once in 1 LOC, injecting a variety of different methods for resources are possbile. So it will end in a Modoption: Use Metalspots, Use Geospots?, Use Metadata, Randomdistribution 1, ..., Randomdistribution n. With fallbackroutines, if no usefull data exists.
As for trees and other features: You refer to a Spring.GetAllFeatures/Spring.DestroyFeature-Combination at startup?
"but it seems more like few big cities fairly far apart": Yes. They join several metalspots. i.e. if you have the typical metalspotcloud, instead of placing tons of mexes, you build one city, since it spans them all anyhow.
An update after returning from a long journey and some development afterwards:
New resources: Okay, it was more than 1 line to perfectly integrate it, but now I have an own resource-system, followed by a bunch of modoptions. Metal can still be used if desired and both "my" resources and/or metal can be scaled by a factor or adjusted to a fixed amount, if someone doesn't like my resmap or the metallayout of a map. If a resource-file doesn't exist, it falls back to metal-mode. A random-resource-spawner might be another idea, to make games a bit less predictable beforehand.
File comment: New resources gui1.png [176.91 KiB]
Downloaded 2 times
GUI: Besides the "x units selected" hiding behind the minimap, all former GUI-Components are removed. (Someone knowing, how to get rid of the text?)
File comment: Building Modules
gui2.png [ 73.06 KiB | Viewed 291 times ]
All buttons show tooltips with descriptions and costs
File comment: Unit-Buildmenu
gui4.png [ 329.21 KiB | Viewed 291 times ]
The unit-build-menu was renewed by codestructure and look. One can choose the components in any order, the last click sends the order. The blueish icons are the selected ones. Selected units are shown by icon in the bottom part. Didn't take a screen how it looks with more than 1 unit, but i can tell, that they are shown smaller. So there always is 1 "mainunit" in a selection (this is important for the other bits of the GUI)
Code: Besides adding code, some existing lines have changed to make it easier now or later. Research is disabled at the moment, since i will change it a bit more too. As you can see on the one screen, a multiple of a unit-weapon-combination can be ordered at one time with the typical Hotkeys (i.e. 5,20,100 Units). A repeat-function is also there, but I hope it's never used. I don't have stumpys anyway
Beauty: I still follow the concept of "the data is there". So the game-play and passing data around works fine now, it might just need a better representation.
Next: Write random-resource-spawner with different presets in ModOptions? Support for several resource-files per Map? Finalize Research-System Write Research-GUI Widget to make creating resource-files just pushing buttons instead of C&P Fiddle around in other GUI-Widgets Continue with the useless-buttons-widget for attack etc.
Evaluate, if moving weapons by lua is better than transports (they make the weapons wobble quite a bit on bumpy terrain)
Users browsing this forum: No registered users and 2 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum